SAT>IP Server: Problem mit verschlüsselten PIDs bei PID-Filternutzung

[Basic.Master]

Im DMS (getestet mit der aktuellen Beta 3.3.1.9, betrifft aber auch die 3.3.1.0) habe ich beim eingebauten SAT>IP-Server Probleme mit bestimmten, verschlüsselten PIDs, wenn ich den PID-Filter benutze. Wenn ich dagegen einfach komplett alle PIDs anfordere, kommen sie unverändert mit.

Es sind keine Plugins aktiv.

 

Hier ein paar Beispiele; es werden immer die PIDs für Video und Audio angefordert, sowie zum generellen Empfangstest auch die PAT:

 

http://<server>:554/?fe=<frontend>&freq=10993&msys=dvbs&sr=22000&pol=h&fec=56&pids=0,767,771

Pro7Sat1 UHD: Video (aber nur Adaptation Field Filler) und PAT kommen zurück

 

http://<server>:554/?fe=<frontend>&freq=10993&msys=dvbs&sr=22000&pol=h&fec=56&pids=0,767,771

TELE5 HD (Tp97): Video (aber nur Adaptation Field Filler) und PAT kommen zurück

 

http://<server>:554/?fe=<frontend>&freq=11464&msys=dvbs&sr=22000&pol=h&fec=23&pids=0,511,515

ProSieben HD: Video (offenbar komplette PID) und PAT kommen zurück

 

http://<server>:554/?fe=<frontend>&freq=10832&msys=dvbs&sr=22000&pol=h&fec=23&pids=0,255,259

RTL HD: Video (aber nur Adaptation Field Filler) und PAT kommen zurück

 

Bei TELE5 HD hatte ich aber auch schon mal den Fall gehabt, dass nicht nur die Adaptation Field Filler mitkommen, sondern die komplette PID.

 

Hier scheint noch irgendwie eine weitere Verarbeitung mitdabei zu sein; ich hätte jetzt eigentlich gedacht, dass die jeweils angeforderten PIDs stumpf 1:1 zurückgeliefert werden.

[Griga]

Mit rtsp statt http bekommst du, was du haben willst. Mehr dazu später...

 

[Griga]

vor 17 Stunden schrieb Basic.Master:

Hier scheint noch irgendwie eine weitere Verarbeitung mitdabei zu sein;

 

Die Vermutung ist richtig. Der Sat>IP Server geht davon aus, dass alles, was eine statische URL verwendet, kein vollwertiger Sat>IP Client, sondern ein "Thin Client" ist, der wie z.B. der VLC eigentlich nichts von Sat>IP weiß, sondern vorfabrizierte URLs aus einer vom Media Server erzeugten M3U-Liste verwendet, um bestimmte Sender wiederzugeben.

 

Um es Thin Clients einfach zu machen, schleust der Server in diesem Fall die Daten durch eine Recorder-Instanz mit der Fähigkeit, PAT und PMT an den tatsächlich gelieferten Content anzupassen, oder anders gesagt, alles rauszuwerfen, was nicht geliefert wird. Außerdem filtert die Recorder-Instanz TS Pakete weg, die im Header als verschlüsselt markiert sind, weil der Client damit nichts anfangen kann. Den Output schreibt die Recorder-Instanz natürlich nicht auf Festplatte, sondern liefert sie über einen Callback zwecks Weitergabe an den Client an den Server zurück.

 

Der Sat>IP Server geht nun davon aus, dass es sich bei HTTP als Protokoll immer um einen Thin Client handelt. Er rechnet nicht damit, dass jemand wie du einherkommt und alles durcheinanderbringt  Als Entwickler unterschätzt man regelmäßig die Kreativität von Anwendern, die nur zu gerne etwas machen, was nicht vorgesehen ist.

 

Nun weiß ich aber Bescheid und werde im nächsten Release die Kriterien für den Einsatz der Recorder-Instanz verschärfen. Sie wird nur noch zum Einsatz kommen, wenn die URL direkt oder indirekt eine Service ID spezifiziert. Andernfalls macht es ja keinen Sinn und ist auch gar nicht möglich, einschränkend an PAT und PMT herumzubasteln.

 

[Griga]

BTW: Wenn du eine bestimmte Auswahl von PIDs "unverfälscht" als HTTP streamen willst, empfiehlt sich der im TransEdit Analyzer seit Version 4.2.0 integrierte Server:

 

Am 11.4.2017 um 16:59 schrieb Griga:

Added: Analyzer: A simple server function. It works like the recorder, which means, it sends the streams that are selected in the PID list on the right to the client (or all streams if none is selected). The Start/Stop Stream button starts and stops streaming. The Copy URL button copies the URL that must be used by the client to the Windows clipboard. The protocol (UDP / RTP / TCP / HTTP) can be configured on the Settings → Analyzer page, as well as the IP address and port. Please note the following important points:

• In case of UDP / RTP the client IP and port must be entered. An IP within the multicast address range lets TransEdit work as multicast server.

• In case of TCP / HTTP the server port and IP must be entered. TransEdit only supports a single TCP / HTTP client per Analyzer window, so it is not possible for two or more clients to connect to the same stream.

 

[Basic.Master]

Am 7.12.2025 um 07:12 schrieb Griga:

Der Sat>IP Server geht nun davon aus, dass es sich bei HTTP als Protokoll immer um einen Thin Client handelt. Er rechnet nicht damit, dass jemand wie du einherkommt und alles durcheinanderbringt  Als Entwickler unterschätzt man regelmäßig die Kreativität von Anwendern, die nur zu gerne etwas machen, was nicht vorgesehen ist.

 

Nun weiß ich aber Bescheid und werde im nächsten Release die Kriterien für den Einsatz der Recorder-Instanz verschärfen. Sie wird nur noch zum Einsatz kommen, wenn die URL direkt oder indirekt eine Service ID spezifiziert. Andernfalls macht es ja keinen Sinn und ist auch gar nicht möglich, einschränkend an PAT und PMT herumzubasteln.

Es ist halt sehr praktisch, Antenne und Tuner woanders stehen zu haben, und sie dann per IP so benutzen zu können, als ob sie direkt da wären. Daher hätte ich jetzt auch keine andere Erwartung gehabt, als dass hier immer ausschließlich 1:1 durchgereicht wird, weil das ja am einfachsten umzusetzen wäre🙂.

Wenn man dieselbe Hardware einerseits für EPG-basierte Aufnahmen via DMS nutzen kann und andererseits mit Transpondern frei herumspielen kann, umso besser.

Es freut mich auf jeden Fall, dass das entsprechend angepasst wird!

 

vor 16 Stunden schrieb Griga:

BTW: Wenn du eine bestimmte Auswahl von PIDs "unverfälscht" als HTTP streamen willst, empfiehlt sich der im TransEdit Analyzer seit Version 4.2.0 integrierte Server:

Den TransEdit-Server kenne ich und auch die RTSP-Schnittstelle von SAT>IP....aber es ist halt am einfachsten, sich z.B. einen Befehl bereitzulegen, der per HTTP irgendein Signal holt und irgendwas damit macht. Im TransEdit müsste ich erstmal herumklicken und bei RTSP wäre ich ebenfalls eingeschränkter in der Toolwahl (ich weiß jetzt auch gar nicht, ob ich z.B. einfach eine Daten-PID herstreamen könnte, z.B. mit einer DAB-Zuführung drauf oder so, oder ob das nur für AV-Content geeignet wäre). Insofern ist HTTP da für Spielereien am flexibelsten.😎

[Griga]

Am 6.12.2025 um 13:40 schrieb Basic.Master:

http://<server>:554/?fe=<frontend>&freq=10993&msys=dvbs&sr=22000&pol=h&fec=56&pids=0,767,771

Pro7Sat1 UHD: Video

 

Muss übrigens &msys=dvbs2&mtype=8psk sein. Mit der obigen Angabe funktioniert es nur, wenn das vom Media Server verwendete Gerät Modulationssystem  und Modulation automatisch erkennt.