Diskussion:MPEG-Transportstrom

Letzter Kommentar: vor 2 Jahren von Netpilots in Abschnitt Zu viele Weblinks welche nicht richtig funktionierten

Gehört m2t auch hier rein ? Bearbeiten

Hab gerade von meinem DVB-T Stick eine Aufzeichung im m2T Format gemacht mit Kaffeine / Linux. Ist dieses .m2t format hier schon beschrieben ? Ansonsten fehlt das in der Suche in der Wikipedia.DE gruß Peter (nicht signierter Beitrag von 84.189.18.140 (Diskussion) 21:53, 7. Sep. 2013 (CEST))Beantworten

Bahnhof? Bearbeiten

So ein Kauderwelsch....... toll das erklärt wird was dieses Format ist, nur steigt da ein normaler Internetuser wie ich der sich mal kurz über die Dateiendung informieren möchte nicht durch. Das ist eher für Informatiker geeignet. ....ja und womit kann man diese Files nun abspielen?--IchHier--15er (Diskussion) 18:56, 2. Aug. 2012 (CEST)Beantworten

Fehlerkorrektur Bearbeiten

Auch DVDs und CDs haben eine Bitfehlerwahrscheinlichkeit und werden daher mit Fehlerkorrekturmaßnahmen abgesichert. Da die DVD Pressfehler enthalten kann, wird diese auch dann gezeigt, wenn die DVD Fehlerhafte Sektoren enthält, sie ist damit nicht so „betriebssicher” wie eine Daten-DVD: Der MPEG-Datenstrom so angelegt, dass fehlende Blöcke erkannt und übersprungen werden können, die DVD wird auch abgespielt, wenn einzelne Blöcke defekt sind. Die Gegenüberstellung von Programmstrom und Transport-Strom ist daher nicht geeignet den Transport-Strom zu erklären.

Die Robustheit der Wiedergabe gegen Blockverluste gehört in den Artikel von MPEG und vom Datenformat des Program-Guides und ist vermutlich verschieden ausgeprägt. -- (Diskussion) 09:35, 20. Nov. 2012 (CET)Beantworten

Fehlerhafte PCR (Program Clock Referenz) Zykluszeiten? Bearbeiten

Laut MPEG Spec (13818) steht im PCR Kapitel 2.7.2 folgende Aussage:

"The Transport Stream shall be constructed so that the time interval between the bytes containing the last bit of program_clock_reference_base fields in successive occurrences of the PCRs in Transport Stream packets of the PCR_PID for each program shall be less than or equal to 0,1 seconds."

Laut aktuellem Wiki-Artikel wird hier von der Hälfte der Zeit ausgegangen? => kann das jemand verifizieren?

shall be less than or equal to 0,1 seconds.
Übersetzt in Deutsch: Soll weniger oder gleich 0,1 Sekunden sein.
0,1 Sekunde = 100 ms. Im Artikel wird 40-50ms erwähnt. Ist also weniger oder gleich 100ms
q.e.d :-)
--EkkehardDomning (Diskussion) 13:35, 1. Jun. 2017 (CEST)Beantworten


Im Artikel steht folgender Satz:
"Zum einen darf die absolute Zeit zwischen zwei Paketen mit einer PCR-Information nicht mehr als 50 ms betragen, zum anderen darf das Jitter der einzelnen Werte nicht größer als 500 ns sein."
Zum das widerspricht den 100ms als Maximalzeit, außerdem beziehen sich soweit ich das aus verschiedenen Quellen ersehen konnte die 500 ns auf die Genauigkeit des Zeitstempels, nicht auf den Jitter der übertragenen Pakete
Die Zeiten sind in der TR 101 290 festgelegt.
In Kapitel 5.2.2 Second priority: recommended for continuous or periodic monitoring befindet sich die Tabelle 5.0b: MPEG-2 TS parameters of 2nd priority. Dort finden sich zwei Fehlerklassen 2.3 PCR_error (unterteilt in 2.3.a PCR_repetition_error und 2.3.b PCR_discontinuity_indicator_error) und 2.4 PCR_accuracy_error.
In 2.3 findet sich Time interval between two consecutive PCR values more than 40 ms und The difference between two consecutive PCR values (PCRi+1 – PCRi) is outside the range of 0...100 ms without the discontinuity_indicator set. Beides scheint sich zunächst zu widersprechen. Man muss jedoch sehen, dass sich der erstere Fehler auf die physikalisch ablaufende Zeit bezieht, die zwischen zwei empfangenen PCR-Werten liegt. Der zweite Fehler bezieht sich dagegen auf den im PCR-Feld übertragenenen Wert.
In den vorhandenen Implementierungen wird sehr häufig der PCR-Zeitstempel alle 35ms übertragen und auf einen Fehler > 50ms geprüft.
In 2.4 PCR_accuracy_error findet sich dann noch PCR accuracy of selected programme is not within ±500 ns. Diese Aussage bezieht sich ebenfalls auf den im Zeitstempel übertragenen Wert.
Quelle: ETSI TR 101 290 V1.3.1 (2014-07) - Digital Video Broadcasting (DVB); Measurement guidelines for DVB systems Seite 23
--EkkehardDomning (Diskussion) 16:03, 1. Jun. 2017 (CEST)Beantworten

Fehlerauswirkung Bearbeiten

"Durch kurze Pakete gewährleistet man, dass kleine Übertragungsfehler auch nur kleine Auswirkungen haben" - das ist so verkürzt nicht ganz richtig. Wird durch ein gestörtes Paket ein i-Frame beschädigt, kann es zu bildschirmfüllenden Artefaktgewittern in grün oder Magenta kommen, die bist zum nächsten i-Frame stehen bleiben können, also etliche Zehntelsekunden lang.

Es sind halt nicht alle Bits gleich wichtig... 134.247.251.245 16:35, 26. Feb. 2018 (CET)Beantworten

Letztlich wird das I-Frame auf der Ebene des Elementarstroms beschädigt und da sind dann die Pakete erheblich größer, bis zu 64KByte. Auf TS-Paketebene ermöglicht zB. "Continuity Counter" schon dort das Fehlen eines Paketes zu erkennen, ohne nährere Informationen über seinen Inhalt haben.

--EkkehardDomning (Diskussion) 20:53, 26. Feb. 2018 (CET)Beantworten

Zu viele Weblinks welche nicht richtig funktionierten Bearbeiten

Bei der Durchsicht hat sich ergeben, dass fast alle Weblink nicht den Richtlinien von Wikipedia entsprechen. Da es so viele sind, habe ich mir erlaubt die gelöschten Links hier in die Diskussion zu "retten". Vielleicht lassen sich welche reparieren um doch noch wertvolle Informationen im Artikel zu sehen. Autoren welche die Links damals in den Artikel brachten sind gebeten was zu versuchen. Ich selbst werde bei Gelegenheit die stark reduzierte Tabelle zu erweitern.

So stand es ursprünglich im Artikel.

--Netpilots 08:55, 25. Mär. 2022 (CET)Beantworten

Das tektronix-Poster findet sich jetzt hier: https://www.tek.com/en/documents/poster/mpeg-poster-dvb --EkkehardDomning (Diskussion) 11:00, 25. Mär. 2022 (CET)Beantworten
Danke @EkkehardDomning, dein Link ist jetzt im Artikel. Du hättest ihn auch gleich selbst rein tun dürfen. --Netpilots 14:50, 25. Mär. 2022 (CET)Beantworten