Jump to content

Entertain to go - Welcher Codec?


Kenaschon

Recommended Posts

Hallo zusammen,

 

nachdem wir keine Satschüssel mehr haben, sind wir auf Entertain von T-Online umgestiegen.

 

Jetzt habe ich auch Entertain to go mit dabei.

 

Läuft auch soweit im DVBViewer, aber ich habe immer mehr oder weniger viele "Störungen" im Bild. Welcher Codec ist wohl am Besten?

 

Grüße und Danke

Manfred

 

 

Link to comment

Mal unabhängig vom Decoder: Du kannst im DVBViewer per Entertain to go alle Sender anschauen? Also nicht nur die ÖR sondern auch die privaten (RTL, PRO7 usw)? Auch in HD? Ich dachte immer, die seien verschlüsselt.

 

zum Codec: welchen setzt Du denn momentan ein? Ich würde es mal mit den üblichen Verdächtigen (LAV) probieren. Wenn es Dir nicht zu viel Aufwand ist, auch mal PowerDVD.

 

Vielleicht liegt es ja auch nicht am Codec sonder irgendwo im Netzwerk. Hier wären mehr Infos hilfreich: DSL-Anschluss Bandbreite, WLAN?, Ethernet 100 MBit oder 1 GBit?

Link to comment
  • 2 weeks later...

Hallo,

RTL ist dabei. Es gibt ja fertige Senderlisten für den DVBViewer.

 

Das komische ist, wenn ich zb. 3sat über den VLC media player schaue ist alles flüssig und es gibt keine Probleme. Selbst wenn ich Das Erste in HD über den VLC media player schaue ist alles ok.

 

Sogar gleichzeitig, also das Erste in HD im VLC media player (alles flüssig) und im DVBViewer RTL (mit Klötzchen).

 

Wenn ich 3sat im DVBViewer schaue, habe ich nur Störungen und Klötchen. Codec sind z.B. diese installiert: ffdshow, LAN Video Decoder, ATI MPEG Video Decoder, MPC - Video decoder, und noch ein paar andere.

 

Egal was ich einstelle, es wird nicht besser sondern nur bei einigen gibt es nur ein grünes Bild.

 

Netzwerk ist ein "1 GBit" Netz.

 

Grüße

Manfred

Link to comment

Dann hat das nichts mit Decodern zu tun. Der vom DVBViewer empfangene Transportstream ist bereits gestört. Wenn es mit VLC klappt, kann man andererseits davon ausgehen, dass die Daten noch in Ordnung sind, wenn sie deinen PC erreichen. Die Frage ist also: Wo und wodurch gehen sie kaputt?

 

Von Interesse wäre, wie das mit der Analyzer- und Preview-Funktion in TransEdit aussieht. Kennst du das Programm bereits? Falls nicht, siehe Mitgliederbereich und Anleitung. Gibt es da auch Störungen?

Link to comment

Habe mir das Programm jetzt mal angeschaut.

 

????

 

Ist mir im Moment zu hoch. Wie bekomme ich die IPTV Sender dort eingestellt?

 

Grüße

Manfred

 

 

Nachtrag:

 

Ich habe jetzt mal die IP-Adresse von RTL eingegeben. 239.35.20.10 Port 10000

 

Im rechten Fenster von Transedit.

 

Dann auf Analyze geklickt.

 

Dort im Feld H.264 Video in der Spalte Missing läuft die Zahl auch hoch. Die Datenrate beträgt dort 2.30 Mbps.

 

Hilft das ein wenig?

 

Grüße

Manfred

Edited by Kenaschon
Link to comment
Dort im Feld H.264 Video in der Spalte Missing läuft die Zahl auch hoch. Die Datenrate beträgt dort 2.30 Mbps.Hilft das ein wenig?

 

Ja. Es schließt aus, dass die Fehler durch eine Wechselwirkung mit Video/Audio-Wiedergabe entstehen. Außerdem ist TransEdit so handlich, dass ich im Gegensatz zu einem Monstrum wie dem DVBViewer leicht Testversionen (eventuell mit Debug-Code) hochladen kann. Ich muss jetzt erst mal überlegen, ob es damit eine Möglichkeit gibt, das Problem weiter einzukreisen.

 

Wie häufig treten die Missing Packets auf? Ständig oder in bestimmten zeitlichen Abständen?

Link to comment
Macht es Sinn alles zu deinstallieren und wieder zu installieren?

 

Erst mal nicht. Es könnte sein, dass es irgendeine Besonderheit bei den RTP-Headern gibt, mit der der DVBViewer und TransEdit nicht klar kommen - der Transportstrom muss ja vor der Weiterverarbeitung von dieser Netzwerk-Protokollschicht befreit werden.

 

Das beste ist womöglich, TransEdit den ganzen Kram mitsamt RTP-Header aufzeichnen zu lassen. Dann kann man da mal reingucken. Aber das muss ich erst coden - ich melde mich hier wieder, wenn es so weit ist.

 

Gibt es sonst jemand, der Entertain to go mit dem DVBViewer empfängt und das Problem auch hat oder nicht hat?

Link to comment

So, im Anhang befindet sich eine TransEdit-Testversion mit zusätzlichem Debug-Code. Es handelt sich um eine eingeschränkte Version - der Analyzer und Exportfunktionen sind deaktiviert - aber Scannen geht, und auch die Preview-Funktion, wenn bereits eine DVBViewer-Installation vorhanden ist.

 

Vorgehensweise:

 

- TransEdit_Test.exe im DVBViewer-Installationsordner speichern (im selben Ordner wie DVBViewer.exe).

 

- Nach dem Start eine IPTV-Transponderliste erzeugen, falls noch nicht vorhanden. Entweder durch manuelle Eingabe von Adressen in eine neue leere Liste (siehe File -> New List -> DVB IPTV), wie wohl bereits von dir durchgeführt, oder eine M3U-Datei mit den Entertain-Adressen in TransEdit importieren, indem man sie einfach mit der Maus ins TransEdit-Programmfenster zieht. Mit einer Internet-Suche wird man schnell fündig.

 

- Auf der rechten Seite des TransEdit-Hauptfensters eine (funktionierende) Adresse auswählen und auf "Scan Selected" klicken. Daraufhin erscheint das Scanner-Fenster und zeigt die Suchlauf-Ergebnisse an. Nach Auswahl eines Eintrags und einem Klick auf Preview sollte TransEdit den Sender wiedergeben - wahrscheinlich mit den bekannten Störungen.

 

- Info -> Configuration Folder aufrufen (öffnet ein Explorer-Fenster) und TransEdit beenden. In dem Konfigurationsordner sollte sich eine Datei namen TransEdit_Test.txt mit dem Log befinden. Diese Datei hier bitte anhängen - eventuell gezippt, falls sie zu groß geworden ist. Und dann schauen wir mal, ob daraus irgendwas hervorgeht.

Edited by Griga
Anhang entfernt
Link to comment

Hallo,

 

so habe alles nach Anleitung gemacht. Hier die TransEdit_Test.txt Datei.

 

Wenn du eine längere Laufzeit benötigst, bitte melden.

 

Bin mir jetzt nicht sicher ob das wichtig ist, aber die Störungen im Bild treten in den Bereichen am stärksten auf die sich verändern. Also z.B. ein "Testbild" hat kaum Störungen, dafür ist ein Spielfilm kaum zu erkennen.

 

Grüße

Manfred

 

 

 

 

 

TransEdit_Test.txt

Link to comment

Die gute Nachricht ist: Es bleibt spannend :)

 

An den RTP Headern liegt es nicht. Zwar haben sie eine variable Größe, was etwas ungewöhnlich ist, aber das behandelt TransEdit laut Log richtig.

 

Ich habe dort nur einen HInweis auf fehlende Daten gefunden. Kurz nach dem Start des Streams fehlt ein Paket mit ca. 1300 Bytes, danach nicht mehr. Allerdings habe ich das Loggen auf 100 Einträge beschränkt, damit die Datei nicht unversehens mehrere MB groß wird. Womöglich gab es danach weitere fehlende Pakete, die nicht mehr erfasst wurden.

 

Deshalb eine weitere Testversion im Anhang, die gezielt nach fehlenden Paketen Ausschau hält (nicht TS-Pakete wie der TransEdit Analyzer, sondern UDP-Pakete auf Netzwerk-Ebene). Sie erkennt Lücken, indem sie einen Zähler in den RTP-Headern im Auge behält.

 

Also mit der neuen Testversione 4.0.7.2 die gleiche Prozedur wie zuvor. Überprüfe auch, ob die Wiedergabefehler immer noch auftreten, wenn du im Scannerfenster die Preview aufrufst. Ich habe nämlich ein paar Kleinigkeiten auf Verdacht geändert. Vielleicht hilft das schon.

Edited by Griga
Anhang entfernt
Link to comment

Hmm, das bestätigt meine Vermutung. Schon auf Netzwerk-Ebene gehen ständig Daten verloren. TransEdit kriegt überhaupt nicht alle Daten zu sehen, oder mit anderen Worten, sie gehen nicht in TransEdit verloren. Fragt sich warum. Wenn die Wiedergabe im VLC komplett störungsfrei ist, muss es auch irgendwie anders gehen.

 

Hast du in dem PC zufällig zwei LAN / WLAN Adapter in Betrieb?

 

Was du noch probieren kannst: TransEdit beenden und die Datei TransEdit.ini mit einem Texteditor öffnen. In der Sektion [Hardware] gibt es einen Abschnitt für das virtuelle IPTV-Gerät. Da sollten Einträge stehen wie

 

Name.x=IPTV Network Device
TunerType.x=4
IPTVNid.x=0
IPTVBuffers.x=7

 

Das x hinter dem Punkt steht hier für die laufende Gerätenummer und ist eine Ziffer ab 0... das hängt von deiner Konfiguration ab. Füge in dem Abschnitt einen Eintrag hinzu, der so aussehen sollte:

 

IPTVRecvBuf.x=0

 

mit der gleichen Nummer für x wie bei den anderen Einträgen. Er bewirkt, dass die Empfangspuffergröße auf Betriebssystem-Standard gesetzt wird. TransEdit verwendet ansonsten den Wert 4096, der 4096 kB = 4 MB entspricht. Damit die Maniupulation wirkt, brauchst du die neue Testversion unten - in der vorherigen hatte ich einen Fehler übersehen, der das Lesen des Wertes aus der TransEdit.ini verhindert (die Gerätenummer wurde nicht erfasst).

Edited by Griga
Anhang entfernt
Link to comment

Jepp, im Rechner sind zwei Netzwerkkarten.

 

Eine "Onboard" Karte und eine Steckkarte (ist aber deaktiviert). Kann aber auch raus.

 

 

Neue Einstellung und Version getestet.

 

Datei im Anhang.

 

Grüße

Manfred

 

 

 

 

TransEdit_Test.txt

Link to comment
ist aber deaktiviert

 

Wenn sie auf BIOS- oder Treiberebene deaktiviert ist, sollte sie keinen Einfluss haben.

 

Neue Einstellung und Version getestet.

 

Bringt nichts. Werfe die Zeile IPTVRecvBuf.x=0 bei geschlossenem TransEdit wieder raus (einfach löschen).

 

So langsam gehen mir die Ideen aus... ich habe aber den IPTV-Teil probeweise auf eine andere Code-Bibliothek für Internet-Zugriff umgestellt. Vielleicht kann die es besser. Die neue Testversion schreibt kein Log mehr, da klar ist, woran es liegt. Nur leider nicht, was man dagegen tun kann. Einfach mal probieren:

Edited by Griga
Anhang entfernt
Link to comment

Hallo,

 

wirklich besser ist das auch nicht.

 

Bin ich denn der einzige mit dem Problem, oder schaut keiner über den DVBViewer IP-TV?

 

Hilft dir eine "was auch immer" Datei vom VLC-Player weiter?

 

Grüße

Manfred

Link to comment
Bin ich denn der einzige mit dem Problem, oder schaut keiner über den DVBViewer IP-TV?

 

Habe ich mich auch schon gefragt. Rückmeldungen ähnlicher Art sind mir nicht bekannt. Ich kann es nur testen, indem ich den VLC lokal eine TS-Datei als UDP / RTP streamen lasse. Das funktioniert problemlos. Ebenso bei einem Betatester, der IPTV in einem professionellem Umfeld verwendet.

 

Du kannst es ja mal zum Vergleich mit einem lokalen Stream probieren. Dazu im VLC Medien -> Stream anwählen -> mit Hinzufügen eine TS-Datei auswählen, also z.B. irgendeine DVBViewer-Aufnahme -> auf Stream klicken -> Next -> RTP / MPEG Transportstream auswählen -> Hinzufügen -> als IP-Adresse z.B. 239.0.0.1 eintragen - > Next -> Transkodierung aktivieren aus -> Next -> Alle Elementarstreams streamen ein -> Stream. Dann in TransEdit in deiner IPTV-Transponderliste einen Eintrag mit 239.0.0.1 als Adresse und 5004 als Port ergänzen. Und das sollte dann störungsfrei funktionieren.

 

UDP als Protokoll ist im Prinzip immer verlustträchtig, da es im Gegensatz zu TCP keinen Rückkanal zum Server gibt, über den fehlende Pakete erneut angefordert werden. Dass die Aussetzer bei dir so extrem auftreten, lässt jedoch vermuten, dass besondere Umstände außerhalb von TransEdit eine Rolle spielen. Auf jeden Fall kommt der Stream schon reichlich kaputt in TransEdit an. Ich kann mir nicht vorstellen, was der VLC anders macht, um das zu vermeiden.

 

Man könnte in TransEdit noch an der CPU-Priorität drehen, mit der der Teil ausgeführt wird, der den Stream empfängt - dazu in der TransEdit.ini den Eintrag Priority.x auf 2 setzen (funktioniert nur mit der letzten Testversion), oder ich könnte TransEdit noch einen zusätzlichen eigenen Puffer verwenden lassen, habe aber Zweifel, ob das was nützt. ;)

Link to comment

Wird die reihenfolge der datagramme eingehalten? ich nehme an, dass das überprüft wird, aber zur sicherheit frage ich es einfach ;)

Link to comment

Hmm, gute Frage - den Aspekt habe ich bislang nicht bedacht. Wenn man sich die Logs anschaut, sieht es so aus, als ob der Continuity Counter (Modulo 65536) in den RTP Headern teilweise rückwärts läuft. Das Log gibt die Differenz zum Sollwert an, wenn es eine Abweichung gibt.

 

Ich hatte das gesehen, aber angenommen, dass es an einem Fehler im Debug-Code bei Überträgen liegt. Das muss ich noch mal überprüfen...

Link to comment

Datagramme können sich unterwegs überholen, da sie verschiedene wege nehmen können. Bei RTP sollte allerdings am ende die richtige reihenfolge wiederhergestellt sein.

 

Das RTP-Protokoll stellt eine Ende-zu-Ende-Verbindung mit Echtzeitübertragung her und unterstützt Unicast-Verbindungen aber auch IP-Multicast. Es erkennt und korrigiert fehlende, doppelte oder in falscher Reihenfolge empfangene Datenpakete

Link to comment

Was mich halt eben so wundert ist, das ich sogar die HD Programme ohne jegliche Störungen im VLC-Player anschauen kann und im DVBViewer schon die normalen Programm schwierig sind.

 

Grüße

Manfred

Link to comment

Datagramme können sich unterwegs überholen, da sie verschiedene wege nehmen können. Bei RTP sollte allerdings am ende die richtige reihenfolge wiederhergestellt sein.

 

Ich denke, das ist die Erklärung für die hier geschilderten Probleme. Zunächst einmal hat man in der Hinsicht keine Unterstützung von Windows bzw. Winsock zu erwarten:

 

http://tangentsoft.net/wskfaq/intermediate.html

 

UDP is an “unreliable” protocol: the stack does not make any effort to handle lost, duplicated, or out-of-order packets. UDP packets are checked for corruption, but a corrupt UDP packet is simply dropped silently.

 

Es gibt Hinweise, dass es im VLC früher das gleiche Problem gab, aber dass dann ein Programmteil ergänzt wurde, der UDP/RTP-Pakete in die richtige Reihenfolge bringt. Siehe z.B. hier:

 

https://forum.videolan.org/viewtopic.php?f=2&t=27287

 

Die dort angeführte Einstellung "RTP reordering timeout" finde ich allerdings in der aktuellen VLC-Version nicht. Ich nehme an, damit ist die Zeit gemeint, die der VLC maximal bei Lücken im Datenstrom wartet, ob fehlende Pakete nachträglich eintreffen.

 

Wie auch immer - eine kurzfristige Abhilfe ist im DVBViewer wahrscheinlich nicht möglich, da dazu erst ein entsprechender Algorithmus gefunden / erfunden, integriert und getestet werden muss. Also kein Fix, der sich von heute auf morgen durchführen lässt. Ich werde über die Sache nachdenken, kann aber nicht sagen, wann eine Lösung vorliegt.

Link to comment

Das würde allerdings einiges erklären, obwohl doch bisher einiges an IPTV funktionierte, oder nicht? Beim lokalen streamen innerhalb eines LANs tritt das problem natürlich nicht auf. Allerdings ist es ziemlich shocking, wenn es so ist. Denn dann steht was drauf, was nicht drin ist. Alles wo RTSP im DVBViewer drauf steht, wäre dann einfaches UDP und das strippen der rtp-header reiner ballastabwurf.

Link to comment

Ein Protokoll wie RTSP zu verwenden löst ja nicht das Problem, dass sich Pakete im Netz überholen oder verloren gehen können. In UDP gibt es weder Flow Control noch Packet Sequencing. Wenn man das haben möchte, muss man TCP verwenden.

 

Bei UDP bleibt es dem Empfänger überlassen, die Pakete in die richtige Reihenfolge zu bringen, üblicherweise durch Buffering. Bei Packetloss hilft das natürlich nicht. Daher wird bei modernen Streamingarchitekturen im IPTV Umfeld eine Retransmission Technik verwendet, d.h. wenn ein Client feststellt, dass Pakete fehlen, kann er diese beim Server erneut anfordern (natürlich nur ein gewisses Maß).

 

Wie auch immer: der DVBViewer muss zumindest das Reordering implementieren, um die UDP Pakete in die richtige Reihenfolge zu bringen. Das erneute Anfordern verlorener Pakete dürfte schwierig zu implementieren sein, da die entsprechenden Schnittstellen der IPTV Anbieter nicht dokumentiert sind.

Link to comment

Es geht um RTP. Hier mal aus der Sat>IP protocol specification:

 

 

The SAT>IP protocol makes use of:
- UPnP for Addressing, Discovery and Description,
- RTSP or HTTP for Control,
- RTP or HTTP for Media Transport.

Für RTP gilt:

 

 

Sequence Number Die Sequenznummer wird für jedes weitere RTP-Datenpaket erhöht. Die Startnummer wird zufällig ausgewählt und ist nicht vorherbestimmbar. Der Empfänger kann mit Hilfe der Sequenznummer die Paketreihenfolge wiederherstellen und den Verlust von Paketen erkennen.

Dieser teil scheint im DVBViewer nicht (richtig) implementiert zu sein.

Link to comment
Beim lokalen streamen innerhalb eines LANs tritt das problem natürlich nicht auf.

 

Aber schon WLAN ist dafür offenbar anfällig. Ich erhalte bei SAT>IP bzw. Streamen von TV über WLAN in größeren Zeitabständen Diskontinuitäten, wenn das RTSP-Gerät für UDP / RTP konfiguriert ist. Server ist der Recording Service, der Client TransEdit.

 

Bislang dachte ich, es wären Paketverluste. Jetzt wollte ich es genauer wissen. Das folgende Log spricht eine deutliche Sprache:

 

11:30:07 ReceiveData Discontinuity: 47307, 47308, 1

11:30:07 ReceiveData Discontinuity: 47309, 47307,-2

11:30:07 ReceiveData Discontinuity: 47308, 47309, 1

 

Der erste der drei Zahlenwerte ist die erwartete (= auf die zuletzt eingetroffene folgende) Sequence Number aus dem RTP Header, der zweite die tatsächliche, und der dritte die Differenz. Wie man sieht, kommt hier Paket 47307 nach 47308 an. Daneben gibt es gelegentlich auch wirkliche Paketverluste. Mit TCP passiert das nicht.

Link to comment

Hmm, bei WLAN könnte das vielleicht durch ein internes link layer enstehen, das verluste durch wiederholung versucht zu reparieren. Weiss ich aber nicht. Wenn alle datagramme denselben weg nehmen, sollte sich eigentlich an der reihenfolge nichts ändern dürfen.

Link to comment
Wenn alle datagramme denselben weg nehmen, sollte sich eigentlich an der reihenfolge nichts ändern dürfen.

 

Habe ich auch gedacht, aber die Wege des Herrn bzw. seiner Daten sind unergründlich... ;) hier geht das über WLAN zu einem vorsintflutlichen Telekom-Router, und von dort aus über LAN zum Client PC.

Link to comment

Ich zitiere mal:

 

There are lots of reasons why a network element might drop a packet or send it out of order. The most common reason is queue overrun. Many IP implementations have a maximum number of packets they will hold waiting to process. If they receive another packet (from another machine or from code on the same machine), they will often discard it. It is even possible for packets to be dropped or delayed by the wires connecting machines, due to attempts by multiple machines to transmit on the wire at the same time. When that happens, none of the packets may get through, and the sending machines may or may not attempt to retransmit.

Link to comment

@Kenaschon: Bist du noch online?

 

Im Anhang die Testversion 4.0.7.4. Damit sollte es bei dir deutlich besser gehen. Sie bringt Pakete in die richtige Reihenfolge. Bei meinem WLAN hat es jedenfalls die gewünschte Wirkung, d.h. es beseitigt die meisten Diskontinuitäten.

 

Die Version schreibt auch wieder ein Log. Bitte das Ergebnis anhängen.

TransEdit_Test_4_0_7_4.zip

Link to comment

Hab bei mir auch T-entertain mit dabei, nutze es allerdings aktuell nicht.

Hatte aber vor längerer Zeit mal eine Senderliste importiert (noch ohne Privatsender) und das klappte hier problemlos.

Habs grade noch mal probiert.

Keine Aussetzer oder so. Auch die HD-Kanäle gehen. Nur beim umschalten gibts ganz kurz etwas gewürfel.

Allerdings läuft hier alles über Lan.

Link to comment

Da geht tatsächlich noch etwas schief in einem Fall, der bei den hiesigen Tests nicht auftrat.

 

Macht aber nichts - die nächste (korrigierte) Testversion unten :) Außerdem gibt noch eine weitere Ursache für Störungen. Gelegentlich tauchen ungewöhnlich große Datenpakete auf, an die sich TransEdit erst anpassen muss, und dabei geht eine Ladung verloren. Das kannst du selbst beheben, indem du unter Settings -> Hardware für das IPTV-Gerät "Buffered TS Packets" auf 8 setzt.

TransEdit_Test_4_0_7_6.zip

Link to comment

Bei den HD Programmen läuft alles rund als auch bei den normalen Programmen.

 

Schön. Vielen Dank für deine Mitarbeit. Deine Kraut & Rüben-Streams waren ein ideales Testobjekt. Wenn der DVBViewer die packt, kann ihn in der Hinsicht nichts mehr erschüttern :)

 

Dann steht jetzt wohl eine neue Version an, richtig?

 

Eine DVBViewer GE-Version mit der Verbesserung ist schon oben:

 

http://www.DVBViewer.tv/forum/topic/8569-DVBViewer-ge/?p=408837

 

Da du keine Sat-Schüssel mehr hast, ist der DVBViewer GE vielleicht für dich interessant, weil er Internetradio vollständig integriert:

 

http://www.DVBViewer.tv/forum/topic/54513-internet-radio-mit-dem-DVBViewer-ge-35/

 

Den DVBViewer GE kannst du zusätzlich zum DVBViewer Pro installieren (ReadMe in der DVBViewer GE ZIP lesen!). Ein Bugfix-Release des DVBViewer Pro wird es womöglich um Pfingsten herum geben. Ein genauer Termin steht noch nicht fest.

Link to comment

 

Schön. Vielen Dank für deine Mitarbeit. Deine Kraut & Rüben-Streams waren ein ideales Testobjekt. .......

 

Ist bei meinem Stream etwas nicht in Ordnung? Falsche Einstellung?

 

Grüße

Manfred

Link to comment

Nein, ist schon ok. Die Datenpakete kommen nur ziemlich extrem durcheinandergewürfelt bei dir an an, obwohl der Server sie garantiert in der richtigen Reihenfolge abgeschickt hat. Sowas kann im Internet passieren, je nach dem, wie die Daten geroutet werden. Und auch lokal über WLAN ist das möglich, wie ich inzwischen gelernt habe (obwohl ich noch nicht verstanden habe, warum genau). Ist bei dir zusätzlich WLAN im Spiel?

 

Normalerweise sorgt in solchen Fällen das TCP-Protokoll für Ordnung, d.h. der Windows Protokoll-Stack sortiert die Daten. Bei IPTV handelt es sich jedoch um das wesentlich anspruchslosere UDP-Protokoll, darin eingeschachtelt RTP (kannst du alles bei Wikipedia nachschlagen...), und dann liegt es in der Verantwortung der Anwendung, die Pakete in die richtige Reihenfolge zu bringen. In der Hinsicht gab es im DVBViewer noch Verbesserungsbedarf.

Link to comment
  • 3 weeks later...

Mir ist noch etwas aufgefallen. (Hat nichts mit dem Problem weiter oben zu tun. Da ging es ja über Netzwerkkabel)

 

Ich wollte auch auf meinen Handy IP-TV schauen. Nur so zum Spaß.

 

Das läuft ja alles über W-LAN. Ging erst überhaupt nicht. Alles grün und total zerhackt.

 

Dann habe ich mal in meiner Fritz-Box gestöbert. Es ist eine 7270. Dort im Menü "WLAN" Untermenü "Funkkanal", gibt es eine kleine Box, in der man einen Haken setzten kann. Dieses kleine Kästchen nennt sich "WLAN-Übertragung für Live TV optimieren".

 

Und siehe da - IP-TV über WLAN geht. Ganz ohne Probleme.

 

 

Grüße

Manfred

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...