ach herrje, da muss man wohl etwas weiter ausholen
vor etlichen Monaten hatte ich schon das zweifelhafte Vergnügen, einige problematische PVA-Daten von pdvb anzuschauen.
Dabei fallen gleich mehrere Non-Konformitäten auf.
Video:
die besagten "E4" Pakete sind im Grunde die originalen PES-Kopfdaten von/vor jedem Bild aus dem Transportstrom.
Aufgabe von pdvb wäre es, diese zu entfernen und entsprechend dem Zielformat umzuformen. Tut's aber nicht, daher bleiben die über.
Stattdessen werden nur die PTS(Zeitstempel) ausgelesen und neue PES-Kopfdaten noch obendrauf gesetzt. (bzw. im PVA-Fall nur PTS + PVA-Kopf).
Da wir jetzt aber E0 bis EF im Quellvideostrom haben können, müsste rme4 auch diese erkennen und entfernen/patchen. aber es heißt ja nun rme4 und wird wohl daher nur E4 entfernen (was IMO unzureichend wäre) /E1 s.u.
Da es in Pj.X nicht vorgesehen ist, Fehler stillschweigend zu 'schlucken', wird hier eben jeder gemeldet. Das macht's natürlich langsam (dem durch abschalten der Meldungen aber entgegengewirkt werden kann), zeigt zudem die Masse an Fehlern im Strom (jedes Bildpaket halt muß bereinigt werden -> vgl. Bild 1 im Thread).
Pj.X ist daher (weiß nich mehr seit wann) darauf eingestellt, dieses "E4" Problem zu beheben, jedoch nicht nur "E4" s.o.
man wage nicht dran zu denken, wenn pdvb auch noch die Zeitstempel gegen 0 neu umrechnen würde, was es zzt. noch nicht macht..
die 'grünen Klötze' sind ja nun wieder ganz anderen Ursprungs, lediglich Zoran hat hier wohl in seiner FW für MpegDecoder ein Problem.
wobei die ARD nach letztem Stand tlw. ihre Encoder diesbzgl. mit geänderter FW (von SA) (resultierend aus unseren Tests dazu) umstellen wird.
Audio:
im PVA-Format ist für Ton spezifiziert, dass jedes darin verpackte originale (nicht Video-) PES-Paket im vorangestellten PVA-Kopf mit einem Flag angekündigt wird (vgl. TS-Pakete) und zwar mit jedem neu begonnenen Paket. Das originale Paket incl PES-Kopf hat dabei unmittelbar dem PVA-Kopf zu folgen, bei Überschreitung der max. Paketgröße darf eine Teilung in mehrere erfolgen, die weiteren dann natürlich ohne PES-Kopf.
was passiert nun hier?
Entweder wird niemals dieses Pflicht-Flag gesetzt, oder nur unregelmäßig bei ein paar PVA-Paketen. Entsprechend kann bei PVA-getreuer Analyse die Tonspur nicht fehlerfrei ausgelesen werden. (-> vgl. Bild 2 im Thread).
(deshalb die Wahloption in Pj.X dies ggf. abzuschalten)
Auch hier gibt es noch div. andere Negativbeispiele (frühere Multidec-Streamengines bspw. waren in dieser Hinsicht extrem instabil und Quell von üblen Aufnahmen).
So kommt/kam es z.B. auch vor, dass im (falschen) PVA-Format eine Tonspur-ID, die bspw. bei arte eigentlich "C3" hat, von der Streamingengine in einem PVA-Paket die korrekte "C3" für den PES-Kopf behielt, im nächsten jedoch wiederum "C0" (weil dies ja wohl Standard ist, nur halt in dem Fall garnicht so im Original vorhanden) an dieser Stelle aber absolut unpassend, zudem natürlich ohne 'Flag' und viell. sogar noch um ein paar Bytes 'verrutscht'.
was also soll man dazu noch sagen, als dass man solche Fehler IMO nicht 'verschweigen' sollte bei der Abarbeitung in einem Tool, denn sonst gewinnt man nur einen falschen Eindruck..
und wenn wir schon dabei sind
Hauppauge scheint es auch mit der aktuellsten SW 2.18 für z.B. ihre DEC-Produktreihe nicht hinbekommen zu haben, die Größe der AC3-Pakete korrekt anzugeben, stattdessen immer noch mit 6Byte zuviel. Sowohl im Mpg als auch als separate Datei, die im übrigen zwar .ac3 heißt, aber auch noch im (fehlerhaften) PES-Format vorliegt.
/E1
aus dem dvdboard zu rme4:
Tatsächlich entfernt RME4 sogar alle Pakete, deren Syncwort zwischen 000001E0 und 000001EF liegt, also alle Pakete, die als PES-Header eine Zeitangabe enthalten könnten.
hieraus ist jedoch nicht ganz ersichtlich, ob auch 'vergessene' PES-Köpfe 'ohne Zeitangabe' tatsächlich behandelt werden, was ein weiterer Fehler sein kann. Pj.X schenkt dem Sonderfall dann zumindest auch seine Aufmerksamkeit..