Entfernen von Adaptation Field Fülldaten bei ORF1/ORF2 HD

[Basic.Master]

Hallo,

letztens hab ich mich wieder gewundert, warum eine Aufnahme von ORF1 HD nach dem Demuxen auf einmal wesentlich kleiner war - jetzt weiß ich warum:

Via Astra werden bei ORF1 HD und ORF2 HD werden auf der Video-PID ca. 20-40 Prozent an Fülldaten gesendet. In diesem Fall handelt es sich nicht um H.264 Filler NAL Units oder simples Zero Byte Stuffing, sondern um spezielle TS-Pakete. Diese haben nur ein Adaptation Field (und keinen Payload), wobei dort am Anfang die Indicators/Flags alle 0 sind; der Rest vom Adaptation Field wird entsprechend mit 0xFF aufgefüllt:

Diese Fülldaten sind via Astra auf ORF1 HD und ORF2 HD zu beobachten, z.B. aber nicht auf ORF III HD. Beispielsweise bei Das Erste HD werden diese Fülldaten auch ausgestrahlt (1-2%).

Die Fülldaten werden beim ORF auch nicht immer ausgestrahlt; ein System habe ich noch nicht erkennen können. Beispielsweise enthält die Nachtwdh. von "Der Medicus - Teil 1" auf ORF2 HD vom 29./30.12.2014 ca. 36% Fülldaten (Aufnahmegröße brutto: ca. 8 GB) dieser Art. Die Nachtwdh. von Teil 2 in der Folgenacht enthält dagegen nicht ein einziges TS-Paket mit diesen Fülldaten (Aufnahmegröße brutto: ca. 4 GB).

Es wäre super, wenn DVBViewer bzw. Recording Service diese Fülldaten direkt beim Aufnahmen entfernen würden.

Für Aufnahmen, die schon gemacht wurden, habe ich den AFFcleaner entwickelt, der diese Fülldaten aus einem MPEG-TS entfernt:

[Joshua06]

DVBViewer hat diese Funktion die Fülldaten zu entfernen.

Edited May 26, 2015 by Joshua06

[Basic.Master]

Diese Funktion im DVBViewer entfernt Filler NAL Units und Zero Byte Stuffing, aber keine TS-Pakete mit dem o.g. Adaptation Field.

[Griga]

Ich habe die Pakete im Videostream von ORF1 HD (Astra 11303 H) auf Anhieb im TransEdit Analyzer gefunden. Im Prinzip dürfte es kein großes Problem sein, sie rauszuwerfen, insbesondere weil der continuity_counter in den Paketen ohne Payload gemäß ISO 13818-1 nicht weitergezählt wird.

 

Aber der Teufel steckt oft im Detail, und ich muss es mir erst im Code genau anschauen. Das kommende DVBViewer Pro 5.4.1 Beta-Release wird es wahrscheinlich noch nicht enthalten.

[Basic.Master]

Genau, das ist hier sehr praktisch mit dem Continuity Counter. Wobei ihr ihn ja beim Entfernen der anderen Arten von Fülldaten sowieso nochmal neuschreibt.

 

Wird das dann auch in den Recording Service eingebaut? Weil den benutze ich täglich; den DVBViewer selbst eigentlich nur zum Aktualisieren der Senderliste.

[Griga]

Genau, das ist hier sehr praktisch mit dem Continuity Counter.

 

...wenn es nicht zum Beispiel Internet-TV-Streams (Typ HLS, segmentierter TS) gäbe, die Pakete ohne Payload liefern, aber entgegen ISO 13818-1 den continuity_counter weiterzählen. Wenn man die einfach rauswirft, hat man nachher tausende von Diskontinuitäten in der Aufnahme, die zwar theoretisch die Wiedergabe nicht stören, aber in der Praxis sieht das womöglich anders aus Dem DVBViewer Filter habe ich extra deswegen abgewöhnt, sowas als Diskontinuität anzusehen und an die Decoder weiterzumelden. Um solchen Fällen vorzubeugen, muss man also den continuity_counter mitverfolgen, wenn man solche Pakete entfernt, und ihn gegebenenfalls korrigieren, oder sie wahlweise nur verwerfen, wenn sich der continuity_counter wiederholt.

 

Ich habe das Entfernen solcher leeren Pakete heute probeweise im DVBViewer GE implementiert, und zwar in der TFillerPacketRemover-Klasse. Das war nicht besonders schwierig und funktioniert soweit. Allerdings musste ich sie separat verwalten, weil ihre Anzahl im Gegensatz zu den Paketen mit Filler NAL Unit nicht in die continuity_counter-Korrektur eingeht.

 

Generell stellt sich auch die Frage, ob man das in der TFillerPacketRemover-Klasse macht, da diese sich nur um Videodaten kümmert. In Audiostreams könnten solche nutzlosen Pakete auch auftauchen. Ganz zu schweigen von DVB-Untertitel-Streams, die bei der ARD zum größten Teil aus Paketen ohne Payload bestehen. Aber was sind die Folgen, wenn man sie rauswirft, und der Stream vielleicht minutenlang in der Datei überhaupt nicht vorkommt? Dabei ist nicht nur die Wiedergabe im DVBViewer zu berücksichtigen, sondern allerlei andere Player, Streaming usw....

 

Das meinte ich mit "der Teufel steckt im Detail".

[Basic.Master]

Ärgerlich, dass sich manche Anbieter da nicht an die Norm halten. In diesem Punkt ist sie eindeutig.

Ein optionaler "strict"-Modus für die Prüfung auf Diskontinuitäten wäre BTW ganz praktisch; manchmal werden Diskontinuitäten in einer Aufnahme deswegen erst von meinem Schnittprogramm gemeldet. -.-

 

Es würde schon reichen, diese Fülldaten nur bei TS-Paketen mit der Video-PID zu entfernen. Ich habe mal eine Statistikfunktion eingebaut, die die entfernte Menge pro betroffener PID angibt. Bei ORF1 HD und Das Erste HD war dabei jeweils nur der Video-ES betroffen, keine Audio-ES (Videotext und DVB-UTs waren in den Aufnahmen nicht drin). Bei Audio-ES würden Fülldaten wegen CBR theoretisch auch keinen Sinn machen. Bei den DVB-UTs gibts die Fülldaten aber auch, wie du richtig sagst. Da wäre es zu verschmerzen, sie aus Kompatibiltätsgründen drinzulassen. Auch wenn (gute) Programme sich von sowas nicht stören lassen sollten; die vorhandene Erwähnung in der PMT sollte ihnen reichen.