Griga Posted February 11 Posted February 11 Um zu erforschen, was bei Anwendern passiert, die mit dem DVBViewer TV via Sat>IP empfangen wollen, aber deren PC ein öffentliches Netzwerk-Profil verwendet, habe ich die Situation nachgestellt, d.h. auf einem PC unter Windows 10 den Netzwerktyp auf "Öffentlich" umgestellt. Mitwirkender war ein Digital Devices OctopusNet Sat>IP Server im Nebenzimmer, der mir eine M3U-Liste mit ein paar RTSP-Adressen von Sendern geliefert hat. Diese habe ich auf das DVBViewer-Icon gezogen. Da der DVBViewer-Installer nur Firewall-Einträge für das private und Domänen-Profil erzeugt, aber nicht für das öffentliche, war das erwartete Ergebnis: Es fand keine Wiedergabe statt. Und das blieb auch so, nachdem ich den Haken bei "Öffentliche Netzwerke" entfernt und "Zugriff zulassen" angeklickt hatte. Auch nachfolgend waren dem DVBViewer weder Bild noch Ton zu entlocken. Eine Kontrolle ergab, dass Windows zwei Firewall-Einträge für TCP und UDP unter "Eingehende Regeln" angelegt hatte, die den Empfang mit öffentlichem Profil explizit blockierten. Nur mit einem Haken bei "Öffentliche Netzwerke" und "Zugriff zulassen" gab der DVBViewer etwas von sich. Nun zum Vergleich das gleiche mit dem VLC. Obwohl es für ihn ebenfalls nur Firewall-Regeln für das private Profil gab, ging die Sache ganz anders aus: Noch bevor ich etwas erlaubt oder verboten hatte, begann schon die Wiedergabe. Und ging unbeeindruckt weiter, nachdem ich den Haken bei "Öffentliche Netzwerke" entfernt und "Zugriff zulassen" angeklickt hatte. Auch nach einem VLC-Neustart funktionierte die Wiedergabe, obwohl Windows ebenfalls zwei Firewall-Einträge für TCP und UDP unter "Eingehende Regeln" angelegt hatte, die den Empfang mit öffentlichem Profil blockieren sollten. Sie wurden einfach ignoriert. Ich habe daraufhin alle Einstellungen in den Eigenschaften der Firewall-Regeln für den DVBViewer und VLC verglichen und bei den eingehenden Reglen für das private Profil Details angeglichen, die unterschiedlich waren, aber das Ergebnis blieb unverändert. Der VLC spielt den Stream, der DVBViewer nicht. Versteht das jemand? Ich nicht. Quote
YARD2 Posted February 11 Posted February 11 Gab es inzwischen evtl eine eigenständige Portfreigabe ? Quote
Griga Posted February 11 Author Posted February 11 vor 9 Stunden schrieb YARD2: Gab es inzwischen evtl eine eigenständige Portfreigabe ? Verstehe ich nicht. Wo, von wem, wie? vor 11 Stunden schrieb Griga: Auch nach einem VLC-Neustart funktionierte die Wiedergabe, obwohl Windows ebenfalls zwei Firewall-Einträge für TCP und UDP unter "Eingehende Regeln" angelegt hatte, die den Empfang mit öffentlichem Profil blockieren sollten. Sie wurden einfach ignoriert. Noch schlimmer: Selbst wenn ich alle eingehenden Regeln für den VLC auf "Blockieren" setze, sowohl für das private als auch für das öffentliche Profil, spielt der fröhlich die OctopusNet-RTSP-Streams ab. Den intereressiert die Windows-Firewall überhaupt nicht. Windows fragt auch nicht mehr nach, ob er darf. Was soll man davon halten? Quote
Griga Posted February 12 Author Posted February 12 vor 21 Stunden schrieb YARD2: Gab es inzwischen evtl eine eigenständige Portfreigabe ? Vermutlich meinst du Firewall -> Einstellungen -> Neue Regel -> Port. Das kannte ich noch nicht. Nein, sowas sehe ich hier nicht. Für RTSP/Sat>IP müsste man auf dem Client-PC auch einen ganzen Portbereich freigeben. Die zwei UDP-Ports für empfangene TV- und RTCP-Daten werden normalerweise vom Client für jede Session neu ausgewürfelt und dem Server via TCP mitgeteilt. Hintergrund meiner Untersuchung: Im DVBViewer & Co soll es beim Hinzufügen virtueller RTSP/Sat>IP-Geräte für Remote Server (also auf einem anderen Gerät) zukünftig einen Hinweis der folgenden Art geben, wenn es nur Netzwerkverbindungen mit öffentlichem Profil gibt da dies ein Problem ist, vor dem Einsteiger häufig stehen, die nicht wissen, was der von Windows beim Einrichten einer Netzwerkverbindung abgefragte Netzwerktyp bedeutet. Der VLC scheint sich bei mir um die Einschränkungen aber irgendwie drumherum zu winden. Wenn ich wüsste, wie er das macht, könnte man sich den Hassel womöglich sparen. Quote
JMS Posted February 12 Posted February 12 Vielleicht verstehe ich Dein Experiment nicht so ganz, dann sorry. Aber am Beispiel VLC: eigentlich machen doch eingehende Regeln gar keinen Sinn, oder? Ich kenne die Protokolle jetzt nicht wirklich, daher wäre meine Vermutung nur folgende: der VLC (... DVBViewer ... Client) ruft eine externe Verbindung ab, i.e. telefoniert nach draußen. Das sollte ihm keiner verbieten (normalerweise). Bei einem TCP Kanal ist klar: der ist dann offen und die Daten kommen. Bei UDP scheint das kniffeliger zu sein, muss es aber nicht. Tatsächlich kennt UDP auch einen Rückkanal. I.e. wenn der UDP Server auf die Anfrage und den dynamisch erzeugten Port des Aufrufers antwortet, dann "sollte" eine Firewall das erkennen und einfach durchreichen wie beim TCP. Kann es sein, dass der VLC genau das macht und der DVBViewer dem Server einen Port anbietet, an dieser senden soll? Das würde zumindest all das Beobachtete erklären. Ist aber wie gesagt mehr geraten. Schon sehr lange her, dass ich mich mit solchen Fragen (esp. UDP Backchannel durch eine Firewall) auseinander setzen musste. Jochen Quote
Griga Posted February 12 Author Posted February 12 vor 2 Stunden schrieb JMS: eigentlich machen doch eingehende Regeln gar keinen Sinn, oder? Eingehende Regeln beziehen sich auf unverlangt von außen eintreffende Daten, die ein Sicherheitsproblem darstellen könnten. Das betrifft insbesondere Server auf deinem PC, die auf Anfragen reagieren, nicht jedoch Clients wie z.B. Browser, die eine (auf TCP basierende) HTTP-Verbindung zu einem Server außerhalb aufbauen, eine Anfrage (Request) senden und im Rahmen der selben Verbindung eine Antwort erhalten. Das müsste man mit einer ausgehenden Regel unterbinden, wenn nötig. Bei Sat>IP ist es so, dass der Client eine ausgehende TCP-Verbindung zum Server aufbaut und diesem mitteilt, was er an welche Adresse und welche Ports haben möchte. Das sendet der Server dann anders als bei HTTP nicht innerhalb der Verbindung, sondern in Form zusätzlicher separater UDP-Streams (mehr zu UDP bei Wikipedia). Da Firewalls üblicherweise nicht den Zusammenhang mit der vorherigen Anforderung via TCP erfassen, betrachten sie die Streams als unverlangt ankommende Daten. Deshalb braucht es Regeln, die das erlauben. Hier haben wir nun den Fall, dass der VLC einen solchen TV-Stream erhält, obwohl ich eine Regel formuliert habe, die das explizit verbietet. Der DVBViewer dagegen nicht. Warum? Quote
JMS Posted February 13 Posted February 13 Alles schon klar. Aber gibt es evtl. im Sat>IP Protokoll eine Verbindungsvariante, bei der direkt die Verbindung über UDP hergestellt wird und der Server von dieser dann wie ich beschrieben habe den Backchannel (sprich den für diese Verbindung vom Client dynamischen Port erstellten Port) verwendet? Jochen Quote
JMS Posted February 13 Posted February 13 Nur so als Idee: ich finde das Verhalten vom VLC hat (positiv) komisch. Vielleicht einfach mal mit dem WireShark schauen, wie der sich so mit dem Server verständigt? Quote
Griga Posted February 13 Author Posted February 13 vor 57 Minuten schrieb JMS: Aber gibt es evtl. im Sat>IP Protokoll eine Verbindungsvariante, bei der direkt die Verbindung über UDP hergestellt wird Über UDP kannst du keine Verbindung herstellen. Das ist ein verbindungsloses Protokoll. Siehe Wikipedia. Denkbar wäre, dass der Server den TV Stream über die vom Client initiierte TCP Verbindung liefert. Ich glaube, RTSP lässt die Variante zu. Aber das ist hier nicht der Fall. Ich habe es auch mit dem DMS als Sat>IP Server probiert. Das gleiche Ergebnis. Da kann ich im Debugger bzw. svcdebug.log sehen, was passiert. Die Anfrage kommt per TCP, der Stream geht via UDP an den Client raus. Kodi kann den Stream auch nicht abspielen, wenn die Firewall blockt. Nur der VLC. Quote
JMS Posted February 13 Posted February 13 vor einer Stunde schrieb Griga: Über UDP kannst du keine Verbindung herstellen. Das ist ein verbindungsloses Protokoll. Siehe Wikipedia. Das ist genau das, was ich versuche Dir zu verkaufen 😉 Ja, natürlich ist UDP paketorientiert und verbindungslos, kein Frage. ABER: wenn ich ein UDP Paket von einem Client durch eine Firewall an einen Server sende, dann kann dieser (dunkel ist diese Erinnerung) auf das Paket durchaus ANTWORTEN (UDP ist verbindungslos aber nicht unidirektional, soweit ich das verstehe). Dazu wird dann auf dem Port geantwortet, den der Client auf seiner Seite dynamisch angelegt hat (das muss er eh für jede Art der TCP/UDP Verbindung machen). Ich meine eine Firewall KANN diese Antwort als solche erkennen und dann das Paket an den Client durchlassen. Das wäre dann KEIN eingehendes Paket im allgemeinen Sinne, sondern eine Antwort auf einem offenen "Kanal". Es kann aber auch einfach sein wie Du vermutest, dass der VLC einfach einen TCP (Verbindungsorientiert) Hack nutzt, da müsste man dann wirklich den WireShark bemühen. Jochen Quote
Griga Posted February 13 Author Posted February 13 vor 8 Minuten schrieb JMS: ABER: wenn ich ein UDP Paket von einem Client durch eine Firewall an einen Server sende, dann kann dieser (dunkel ist diese Erinnerung) auf das Paket durchaus ANTWORTEN Bei Sat>IP senden Clients keine UDP-Pakete an den Server. Das gibt das Protokoll nicht her. Nur umgekehrt. vor 14 Minuten schrieb JMS: Es kann aber auch einfach sein wie Du vermutest, dass der VLC einfach einen TCP (Verbindungsorientiert) Hack nutzt, Das habe ich bereits ausgeschlossen, siehe oben. Quote
Griga Posted February 16 Author Posted February 16 Jetzt wird es interessant: Der VLC sieht auch kein Land bzw. erhält keinen UDP Stream mehr von OctopusNET als Sat>IP-Server, wenn ich mit einer ausgehenden Firewall-Regel UDP blockiere. Es sieht so aus, als ob der VLC den Empfang des Streams der Windows Firewall als ausgehenden Traffic verkauft, obwohl er natürlich Daten erhält. Deshalb haben eingehende Regeln, die das verbieten, keinen Einfluss. Da die Windows Firewall ausgehende Verbindungen / Streams standardmäßig erlaubt, gibt es hier keine Probleme. Fragt sich nur, wie der VLC das hinkriegt. Könnte der DVBViewer die Methode kopieren, gäbe es bei Sat>IP keinen Ärger mehr mit fälschlich als öffentlich konfigurierten Netzwerkverbindungen. Beim DVBViewer ist es umgekehrt: Es muss eine eingehende Regel geben, die den Empfang des UDP Streams erlaubt. Sonst tut sich nichts, weil die Windows Firewall den Stream als unverlangt eintreffende Daten ansieht. Eine ausgehende Regel, die dem DVBViewer UDP verbietet, hat anders als beim VLC in der Hinsicht keinen Einfluss. Allerdings verhindert ein solches Verbot die Erkennung von Remote Sat>IP-Servern im DVBViewer. Und bei UPnP sieht es dann auch schlecht aus. Quote
Bob.Dig Posted February 16 Posted February 16 (edited) Bin gerade über den Thread gestolpert und kein Fachmann und kann auch nicht sagen, ob das jetzt ein treffendes Beispiel ist. Ich sehe in der Windows-Firewall bei einem Link in der Gestalt: http://172.16.35.10:6878/something/getstream?id=something&hlc=1&transcode_audio=0&transcode_mp3=0&transcode_ac3=0&preferred_audio_language=eng&pid=438314110 dass der DVBViewer zwei eingehende UDP Verbindung empfängt, während bei VLC alles über TCP ausgehend läuft und im Übrigen die Wiedergabe sofort startet. Edited February 16 by Bob.Dig Quote
Bob.Dig Posted February 16 Posted February 16 (edited) Wenn ich noch mal drüber gucke, dann ist die UDP-Verbindung zum DMS, der aber gar nicht das Ziel der obigen Adresse war. Warum der hier auftaucht, weiß ich nicht. Würde das Ganze noch mal nachstellen wollen, mit deaktiviertem DMS, aber der nimmt gerade auf. Vielleicht ist mein Beispiel doch völlig ungeeignet und nutzt generell kein UDP. Ich vermute jetzt letzteres und melde mich nur, falls doch noch mal was mit UDP auftaucht. Oder das liegt an den Streaming-Devices, die ich im Viewer angelegt hatte und die auf den DMS zeigen? Dann wird wohl darüber die Verbindung aufgebaut... Edit: Wenn ich den DMS als Mittelsmann ausschalte, dann gibt es auch keine UDP-Verbindung und auch der Viewer lädt entsprechend schnell. Also war mein Beispiel vermutlich von Anfang an ungeeignet. Edited February 16 by Bob.Dig Quote
Griga Posted February 16 Author Posted February 16 vor 9 Stunden schrieb Griga: Es sieht so aus, als ob der VLC den Empfang des Streams der Windows Firewall als ausgehenden Traffic verkauft, obwohl er natürlich Daten erhält. Deshalb haben eingehende Regeln, die das verbieten, keinen Einfluss. Da die Windows Firewall ausgehende Verbindungen / Streams standardmäßig erlaubt, gibt es hier keine Probleme. Fragt sich nur, wie der VLC das hinkriegt. Könnte der DVBViewer die Methode kopieren, gäbe es bei Sat>IP keinen Ärger mehr mit fälschlich als öffentlich konfigurierten Netzwerkverbindungen. Ich hab's rausgefunden Hat auch lange genug gedauert. Wenn man weiß, wie es geht, ist es ganz einfach: Der DVBViewer als Sat>IP-Client muss nur dem Sat>IP-Server vorab an dessen IP-Adresse und dessen UDP-Port ein paar beliebige Daten schicken. Der DVBViewer erfährt den UDP-Port des Servers, weil dieser in seiner Antwort auf ein SETUP-Kommando darüber informiert - mehr dazu hier. Das blieb bislang im DVBViewer ungenutzt. Auf diese Weise wertet die Windows-Firewall das als ausgehende Verbindung, weil der DVBViewer den Server via UDP beliefert, bevor er auf gleichem Weg (über den selben Socket) Daten erhält. Aus Sicht der Firewall sind das dann keine unverlangt eintreffenden Daten mehr. Sie interessiert dabei nicht im geringsten, dass die vom DVBViewer gesendeten Daten nur aus Nullen bestehen und der Server sie ohnehin nicht verwertet, weil er an seinem UDP-Port nicht auf eintreffende Daten lauscht, sondern nur welche sendet. Alles egal - hauptsache die anfängliche Richtung ist ausgehend. vor 4 Stunden schrieb Bob.Dig: Oder das liegt an den Streaming-Devices, die ich im Viewer angelegt hatte und die auf den DMS zeigen? So ist es. Du hast im DVBViewer wahrscheinlich ein virtuelles RTSP/Sat>IP-Gerät mit dem Tunertyp TS Stream. vor 4 Stunden schrieb Bob.Dig: Also war mein Beispiel vermutlich von Anfang an ungeeignet. Korrekt. Quote
Bob.Dig Posted February 16 Posted February 16 vor 42 Minuten schrieb Griga: Der DVBViewer als Sat>IP-Client muss nur dem Sat>IP-Server vorab an dessen IP-Adresse und dessen UDP-Port ein paar beliebige Daten schicken. Glaube, das nennt man Hole Punching. vor 43 Minuten schrieb Griga: Ich hab's rausgefunden Gratulation. Quote
JMS Posted February 17 Posted February 17 (edited) Zitat Bei Sat>IP senden Clients keine UDP-Pakete an den Server. Das gibt das Protokoll nicht her. Nur umgekehrt. 😉 So wie Du es beschreibst war es in etwa das, was ich meinte (ich kannte den Begriff nicht, daher mein plumpes "Rückkanal") - im Detail hätte ich das sicher nicht so schnell gefunden, gut gemacht 👍 Trotzdem sei mir ein Hinweis noch gestattet: es könnte sein, dass die Firewall das bei einer "Verbindung" (jaja, UDP ist verbindungslos, ich meine das Hole Punching) im Idle Modus (wo nichts hin und her geht) die Erlaubnis zum Rückruf vergisst und dicht macht. Sollte also (keine Ahnung, ob das Protokoll das hergibt, vielleicht haben die ja eine Art Keep Alive im UDP integriert) mal jemand Pausieren und erst nach einer Weile zurückkommen, könnte das ärgerlich sein. Da muss man dann halt im Idle dem Server ab und an was schicken, wenn es sein muss. Bei einem Projekt mit einer kommerziellen Firewall meine ich wäre das Intervall 5 oder 15 Minuten gewesen, also eher klein - fürs Klo reicht es dann eventuell noch aber nicht fürs Abendessen 🤣 Jochen Edited February 18 by JMS Quote
Griga Posted February 17 Author Posted February 17 vor 2 Stunden schrieb JMS: Sollte also (keine Ahnung, ob das Protokoll das hergibt, vielleicht haben die ja eine Art Keep Alive im UDP integriert) mal jemand Pausieren und erst nach einer Weile zurückkommen, könnte das ärgerlich sein. Da muss man dann halt im Idle dem Server ab und an was schicken, wenn es sein muss. "Keep Alive" ist im Sat>IP-Standard spezifiziert: Zitat In order to keep sessions with a server alive, clients need to issue regular RTSP messages within the timeout period (announced by the server in the original reply to the SETUP message). In SAT>IP RTSP OPTIONS messages shall be used as the default keep alive messages. Die Messages kommen via TCP. Quote
Griga Posted February 19 Author Posted February 19 Am 16.2.2025 um 21:34 schrieb Griga: Auf diese Weise wertet die Windows-Firewall das als ausgehende Verbindung, weil der DVBViewer den Server via UDP beliefert, bevor er auf gleichem Weg (über den selben Socket) Daten erhält. Aus Sicht der Firewall sind das dann keine unverlangt eintreffenden Daten mehr. Das macht den Empfang von Sat>IP Streams im DVBViewer wesentlich unproblematischer, weil im Normalfall die Windows-Firewall nicht mehr im Wege steht - insbesondere nicht, wenn die Netzwerkverbindung das öffentliche Profil benutzt. Trotzdem werden in Zukunft Regeln für eingehende Verbindungen nötig sein. Der DVBViewer kann dem Server ja nur via UDP Daten schicken, weil er dessen UDP-Ports kennt. Und die erfährt er vorab durch das übergeordnete RTSP-Protokoll, das die Information via TCP-Verbindung im SETUP-Header liefert (sofern der Server sie dort freundlicherweise bereitstellt). Es gibt aber auch reine UDP/RTP-Streams, die nicht in ein anderes Protokoll eingebettet sind. Der TransEdit Analyzer bietet z.B. einen einfachen Server, der solche Streams liefern kann. Ein anderer Fall sind Multicast-Streams wie MagentaTV der Telekom. Da weiß der Client nur, an welchem eigenen Port er auf eintreffende UDP Daten lauschen soll, aber kennt keine Server-Ports, an die er liefern könnte, um die Firewall von einer ausgehenden Verbindung zu überzeugen. Problematisch ist weiterhin, dass man im DVBViewer das Protokoll für die Lieferung von TV-Daten von UDP auf TCP umstellen kann, wenn (und nur wenn) sie vom DVBViewer Media Server kommen. Der benutzt dann eine zweite TCP-Verbindung, die den UDP Stream ersetzt. Diese Verbindung wird vom Server durch eine Request an den Client initiiert, basierend auf Informationen, die er durch die vom Client initiierte erste TCP-Verbindung erhält (insbeondere IP-Adresse und Port des Clients). Dadurch ist das wieder aus Client-Sicht eine eingehende Verbindung. Kurz gesagt droht hier weiterhin Firewall-Ärger. Den alternativen Transport der TV-Daten via TCP brauchen manche Anwender, bei denen UDP aufgrund Netzwerk-Verhältnissen zu störanfällig ist und zu Aussetzern führt. Allerdings handelt es sich hier um eine proprietäre Implementation im DVBViewer und Media Server, die nirgendwo spezifiziert und zu nichts anderem kompatibel ist. Mit Sat>IP Servern/Clients außerhalb der DVBViewer-Familie lässt sie sich nicht verwenden. Sie lässt sich auch nicht auf einfache Weise so modifizieren, dass sie zu einer vom Client ausgehenden Verbindung wird. Implementiert wurde sie früher wohl so, damit sie der normalen Sat>IP-Vorgehensweise (TCP für die Anforderung von Daten durch den Client, UDP für die Lieferung durch den Server) möglichst ähnlich und damit programmtechnisch leicht integrierbar ist. Es gibt jedoch auch eine Art des Transports von TV-Daten via TCP, die die RTSP-Spezifikationen vorsehen, ausdrücklich für Fälle, in denen Firewalls sonst blocken. Hierbei wird die vom Client aufgebaute TCP-Verbindung doppelt genutzt, sowohl für Messages vom Client an den Server als auch für Daten-Lieferungen vom Server an den Client. Die beiden Vorgänge müssen also ineinandergeschachtelt ("interleaved") stattfinden - mehr dazu hier. Wie der Artikel bereits andeutet, ist die Implementation programmtechnisch deutlich komplizierter als die bislang vom DVBViewer und Media Server verwendete proprietäre Methode, aber dafür Firewall-freundlich, um das mal so auszudrücken. Und sie ist mit anderer RTSP- Software kompatibel, die diese Methode ebenfalls unterstützt. Dazu gehören insbesondere der Linux Sat>IP-Server minisatip und der VLC. Es spricht also einiges dafür, die standardkonforme Methode des Sat>IP-Transports von TV-Daten via TCP zu implementieren. Im DVBViewer Media Server ist mir das bereits gelungen (gestestet mit dem VLC), aber die Client-Implementation im DVBViewer macht mir noch Kopfzerbrechen. So zieht ein gelöstes Problem das nächste nach sich... 1 Quote
Bob.Dig Posted February 20 Posted February 20 (edited) Am 19.2.2025 um 09:14 schrieb Griga: Trotzdem werden in Zukunft Regeln für eingehende Verbindungen nötig sein. Der DVBViewer kann dem Server ja nur via UDP Daten schicken, weil er dessen UDP-Ports kennt. Mich würde interessieren, ob man damit auch die Einschaltzeit zwischen Viewer und DMS reduzieren könnte. Also das erste Starten eines Senders (bei mir DVB-C) dauert gefühlt zu lange. Da ich aber seit Ewigkeiten meinen TV-Stick nicht mehr im selben Rechner wie den Viewer verwende, mag es auch komplett am Stick usw. liegen und die IP-Verbindung spielt eher keine Rolle. Apropos "dauert gefühlt zu lange", das Forum scheint mir teilweise recht träge zu reagieren. Edited February 20 by Bob.Dig Quote
Griga Posted February 20 Author Posted February 20 vor 26 Minuten schrieb Bob.Dig: Mich würde interessieren, ob man damit auch die Einschaltzeit zwischen Viewer und DMS reduzieren könnte. Nein. Quote
Griga Posted March 2 Author Posted March 2 Am 19.2.2025 um 09:14 schrieb Griga: Es gibt jedoch auch eine Art des Transports von TV-Daten via TCP, die die RTSP-Spezifikationen vorsehen, ausdrücklich für Fälle, in denen Firewalls sonst blocken. Hierbei wird die vom Client aufgebaute TCP-Verbindung doppelt genutzt, sowohl für Messages vom Client an den Server als auch für Daten-Lieferungen vom Server an den Client. Die beiden Vorgänge müssen also ineinandergeschachtelt ("interleaved") stattfinden - mehr dazu hier. Nachgefragt wurde diese Art des Sat>IP-Datentransports hier schon mehrfach, z.B. https://www.dvbviewer.tv/forum/topic/61221-satip-server-über-tcp-verbinden/ https://www.dvbviewer.tv/forum/topic/63103-support-for-httptcp-protocol-satip/ Früher habe ich mich nach Kräften gegen die Implementation gesträubt. Inzwischen weiß ich auch, warum... Nun ist es jedoch in trockenen Tüchern, allerdings erst nach einigen Geburtswehen. Die serverseitige Implementation im DVBViewer Media Server war vergleichsweise harmlos und hat nur einen Tag gebraucht. Getestet habe ich sie mit dem VLC nach der Umstellung unter Werkzeuge -> Einstellungen -> Eingang/Codecs -> Live555 Stream-Transport von HTTP auf RTP über RTSP (TCP). Live555 ist die zuständige vom VLC verwendete Programmbibliothek. Um Unzulänglichkeiten der Live555-Implementation, die dabei zu Tage traten, konnte ich nach gewissenhaftem Studium des Debug-Outputs drumherumarbeiten. Als widerspenstig erwies sich dagegen aus verschiedenen programmtechnischen Gründen die clientseitige Implementation im DVBViewer. Zwar funktionierten alsbald Versuche mit dem just aufgerüsteten RTSP Server des DVBViewer Media Servers als Gegenstück, aber das war quasi Inzucht Bei Versuchen mit dem etwas eigenwilligen Linux-Sat>IP Server Tvheadend als Quelle flog mir der neue Code im DVBViewer regelrecht um die Ohren. Pufferüberläufe, Zugriffsverletzungen, Deadlocks... die Ursachen zu ermitteln und auszumerzen zog sich hin. Als es schließlich nach vielen vergeblichen Versuchen lief, wollte ich es zur Sicherheit noch mit dem Linux Sat>IP Server minisatip testen. Von diesem Leichtgewicht-Kommandozeilen-Server ohne GUI, der gerne in Embedded-Systemen genutzt wird, konnte ich jedoch keine x86-Binary im Web auftreiben. Zwar gibt es ein theoretisch leicht installierbares Snap-Paket - damit hatte ich schon Erfahrung - aber in diesem Fall scheiterten alle Installationsversuche mit einer Fehlermeldung, weil offenbar die in dem Paket vorgesehene Einrichtung von minisatip als Hintergrund-Service nicht funktionierte, warum auch immer. Also blieb nur, den Quellcode herunterzuladen und unter Linux Mint selbst zu kompilieren. Sowas hatte ich noch nie gemacht. Eine hier veröffentlichte Schritt-für-Schritt-Anleitung half schließlich weiter, funktionierte aber an manchen Stellen nicht wie angegeben, weil dies oder das in meinem System fehlte oder die Angaben veraltet waren. Diese Erfahrung habe ich schon öfters mit Linux gemacht: Will man irgendwas außerhalb des Mainstreams bzw. an den gängigen Paket-Repositories vorbei machen, braucht man eine gute Kondition als Hürdenläufer... Als minisatip schließlich lief, blieb noch das Problem, den Server via Kommandozelle für die von einem Unicable-LNB versorgten Digital Devices Tuner im Linux-PC zu frisieren. Und auch für den auf einem Windows PC laufenden DVBViewer Media Server als Datenquelle (also für die Sat>IP-Verarbeitungskette DVB-Gerät -> DVBViewer Media Server -> minisatip -> DVBViewer), weil ich sowohl meine serverseitige als auch clientseitige Implementation des TCP Interleaved-Datentransports mit dem Linux-Exoten testen wollte. Das war ein weiterer Hindernis-Parcour. Nichtsdestotrotz ist die Sache jetzt soweit gediehen, dass sie voraussichtlich im nächsten DVBViewer- und Media Server-Release zur Verfügung stehen wird... uff! 3 Quote
Griga Posted July 3 Author Posted July 3 Am 19.2.2025 um 09:14 schrieb Griga: Den alternativen Transport der TV-Daten via TCP brauchen manche Anwender, bei denen UDP aufgrund Netzwerk-Verhältnissen zu störanfällig ist und zu Aussetzern führt. Der Server übergibt die Datenpakete dabei halt auf verschiedene Weise. Christian (Hackbart) hat sich auch Gedanken darum gemacht: Zitat Ich habe vorhin die KI gefragt, ob ich ein Bild zur Erklärung von TCP und UDP kriegen kann im Muppetstil. 2 Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.