HEVC-Fülldaten entfernen

[Basic.Master]

Es wäre super, wenn der DVBViewer bzw. der DMS auch Fülldaten (in Form von der NAL Unit 38 = Filler Data) bei HEVC entfernen würden; bisher bleiben die in der Aufnahme drin. Ich hätte auch einen Test-TS, wenn nötig.

[Basic.Master]

Noch zur Ergänzung:

Die kommen im Test-TS (DVB-T2) in größeren, zusammenhängenden Blöcken vor (z.B. ein 4500-Byte-Block), so dass man sie (wie es bei H.264 in DVBv/DMS bereits passiert) entsprechend in Form von TS-Paketen entfernen könnte, die nicht an Anfang/Ende des zusammenhängenden Blocks liegen. Von der Größenordnung her waren z.B. 40 MB Fülldaten in 500 MB Video-ES enthalten.

[Griga]

vor einer Stunde schrieb Basic.Master:

Es wäre super, wenn der DVBViewer bzw. der DMS auch Fülldaten (in Form von der NAL Unit 38 = Filler Data) bei HEVC entfernen würden;

 

Das wäre wieder ein Fall für @Martin K, oder? Hast du noch Kontakt zu ihm?

 

[Griga]

P.S. Nach einer kurzen Recherche: Das hat Martin K. bereits 2017 ausgearbeitet, und es ist im DVBViewer und DMS integriert. Es gibt in der entsprechenden Unit jedenfalls eine Klasse THEVCFillerPacketRemover, die von TH264FillerPacketRemover abgeleitet ist und nur einen Override enthält:

 

//----------------------------------------------------- THEVCFillerPacketRemover

function THEVCFillerPacketRemover.IsFillerNalUnit(const B: Byte): Boolean;
begin
  result := B and $7E = $4C; //= 38 shl 1, 38 for HEVC filler data NAL unit (FD_NUT)
  FInUnitHeader := true;
end;

 

Das wird im DVBViewer und DMS Recorder auch verwendet.

 

[Griga]

P.P.S. Und es macht auch etwas. Kommt nur nicht viel bei herum (Snowboard-Weltcup im Ersten HD mit DVBViewer aufgenommen):

 

 

[Griga]

P.P.P.S: Das gibt es seit DVBViewer 6.04 bzw. November 2017:

 

 

Am 1.11.2017 um 09:07 schrieb hackbart:

Ergänzt: Aufnahme/Timeshift-Optionen: „Video-Fülldaten entfernen“ wirkt jetzt auch auf HEVC Video (vorher nur auf H.264 und MPEG2): Dank an Martin K. für den Code!

 

[Basic.Master]

vor 46 Minuten schrieb Griga:

P.P.P.S: Das gibt es seit DVBViewer 6.04 bzw. November 2017:

 

 

 

 

Im DMS ist es ebenfalls seitdem (Version 2.0.4) drin: https://www.DVBViewer.tv/forum/topic/59627-DVBViewer-media-server-2000/?do=findComment&comment=468333

 

vor einer Stunde schrieb Griga:

 

Das wäre wieder ein Fall für @Martin K, oder? Hast du noch Kontakt zu ihm?

 

 

Ja, tausche mich gerade parallel mit ihm dazu aus.

 

Bei Das Erste HD via BR bekommt er Fülldaten angezeigt; sind dort Adaptation Field Filler, genauso bei ZDF HD. Er nutzt den DVBViewer; den DMS nicht.

Bei mir nimmt der DMS auf - auch, wenn ich im DVBViewer eine Aufnahme starte. Bei ZDF HD sehe ich dabei ebenfalls Fülldaten.

 

Bei Das Erste HD via hr bleiben die Fülldaten dagegen bei komplett 0:

 

Im Hexeditor kann man sehen, dass die Filler-NALU dort vorkommt (hier Video-ES der Aufnahme demultiplext), und der Block auch groß genug ist, dass ein Teil davon (auf TS-Ebene) verworfen werden müsste:

:

 

Hier ein entsprechendes TS-Paket (nicht identisch mit derselben Stelle, wie im Screenshot davor):

 

Dahinter kommen in der Aufnahme bei der Video-PID dann nochmal über 10 TS-Pakete, die ausschließlich 0xFF im Payload haben.

 

vor 57 Minuten schrieb Griga:

P.S. Nach einer kurzen Recherche: Das hat Martin K. bereits 2017 ausgearbeitet, und es ist im DVBViewer und DMS integriert. Es gibt in der entsprechenden Unit jedenfalls eine Klasse THEVCFillerPacketRemover, die von TH264FillerPacketRemover abgeleitet ist und nur einen Override erhält:

 

//----------------------------------------------------- THEVCFillerPacketRemover

function THEVCFillerPacketRemover.IsFillerNalUnit(const B: Byte): Boolean;
begin
  result := B and $7E = $4C; //= 38 shl 1, 38 for HEVC filler data NAL unit (FD_NUT)
  FInUnitHeader := true;
end;

 

Das wird im DVBViewer und DMS Recorder auch verwendet.

 

Da sieht jetzt eigentlich auch nichts falsch dran aus.

 

Es sieht generell so aus, als ob Adaptation Field Filler entfernt werden (daher bleibt der Filler-Anteil je nach Sender auch nicht bei 0), aber die Filler-NALUs nicht....warum auch immer...

Edited February 24 by Basic.Master

[Martin K]

Hallo zusammen,

 

ZDF HD via DVB-T2 scheint auch nur Adaptation Field Stuffing zu verwenden. Links das Original (Aufnahme per TransEdit mit selektierten PIDs), Rechts nach Bereinigung durch TSPlayer (der dürfte ja bzgl. Fülldaten-Entfernung dieselbe Implementierung haben):

 

Beim BR-Fernsehen über den BR sieht es genauso aus.

 

Hier die Aufnahme von Basic.Master (Das Erste über den hr), hier handelt es sich offensichtlich um Filler NAL Units. Links seine Originalaufnahme mit dem DMS erstellt und aktivierter Entfernung von Fülldaten, rechts wieder nach Bereinigung durch TSPlayer:

 

Leider habe ich aktuell selbst keine Empfangsmöglichkeit von DVB-T2 über den hr und beim BR ist es wie erwähnt "nur" Adaptation Field Stuffing...

 

Kann es sein, dass es die Implementierung zur Entfernung der Filler NAL Units nur in den TSPlayer und DVBViewer geschafft hat, nicht aber in den DMS?

 

[Griga]

vor 4 Stunden schrieb Martin K:

Kann es sein, dass es die Implementierung zur Entfernung der Filler NAL Units nur in den TSPlayer und DVBViewer geschafft hat, nicht aber in den DMS?

 

DVBViewer und DMS haben in der Hinsicht eine gemeinsame Code-Basis. Unter Debugger-Controlle zeigt hier ein Breakpoint, dass der DMS bei Aufnahmen vom Ersten HD (NRW) HEVC Filler NAL Units erkennt und TS-Pakete, die komplett innerhalb solcher Units liegen (nur 0xFF) verwirft. Der TSPlayer entfernt keine weiteren Daten.

 

In den DMS Optionen gibt es zwei Einstellungen "Video-Fülldaten entfernen". Einmal für Aufnahmen, einmal für Web/UPnP -> Live Streamserver. Liegt vielleicht eine Verwechslung vor?

 

Zu beachten ist auch, dass die entsprechende Einstellung im DVBViewer -> Optionen -> Aufnahmen nicht für den DMS gilt, sondern nur für vom DVBViewer ausgeführte Aufnahmen.

 

vor 4 Stunden schrieb Basic.Master:

Bei Das Erste HD via hr bleiben die Fülldaten dagegen bei komplett 0:

 

Ist sicher, dass der DMS die Aufnahme durchgeführt hat, und nicht der DVBViewer?

 

[Basic.Master]

vor 13 Stunden schrieb Griga:

 

In den DMS Optionen gibt es zwei Einstellungen "Video-Fülldaten entfernen". Einmal für Aufnahmen, einmal für Web/UPnP -> Live Streamserver. Liegt vielleicht eine Verwechslung vor?

 

Zu beachten ist auch, dass die entsprechende Einstellung im DVBViewer -> Optionen -> Aufnahmen nicht für den DMS gilt, sondern nur für vom DVBViewer ausgeführte Aufnahmen.

 

Die Option ist in allen drei Fällen eingeschaltet:

• DMS für Aufnahmen
• DMS für Streaming
• DVBViewer für Aufnahmen

vor 13 Stunden schrieb Griga:

Ist sicher, dass der DMS die Aufnahme durchgeführt hat, und nicht der DVBViewer?

 

Ja, im Normalfall nutze ich nur den DMS; der DVBViewer läuft fast nie. Ich habe im DVBViewer jetzt nur mal zu Testzwecken eine Aufnahme gemacht (dazu temporär die DMS-Anbindung deaktiviert), um zu prüfen, ob beide Programme gleichermaßen betroffen sind. Ursprünglich auf das Problem bin ich bei Aufnahmen gestoßen, von vor ein paar Tagen.

 

Testweise habe ich nochmal im TransEdit von Hand einen Scan gemacht, das Programm im DVBViewer importiert und dafür den alten Eintrag in der Senderliste gelöscht. Extra auch umbenannt, damit klar ist, dass die Senderdaten im DMS neu geladen wurden, nach Speichern im DVBViewer. Hat keine Änderung gebracht.

 

Ich habe dir per PN die support.zip und die von TransEdit erzeugte .ini-Datei geschickt.

[Griga]

Ich kann das nicht nachvollziehen.

 

Zwei Aufnahmen gleichzeitig vom selben DVB-T2-Sender (One HD, Straßen von San Francisco), eine mit dem DMS und "Fülldaten entfernen" (Hexview links), die andere mit dem DVBViewer ohne die Option (Hexview rechts):

 

 

Man sieht in beiden Screenshots den Beginn der Filler NAL Unit 00 00 01 4C im gleichen Paket. In der DVBViewer-Aufnahme rechts folgen weitere zu der Unit gehörende mit FF gefüllte Pakete. Insgesamt sind es 7 Stück. Die fehlen in der DMS-Aufnahme, in der man jedoch sieht, mit welcher Boshaftigkeit der Muxer Filler NAL Unit und Adaptation Field Stuffing kombiniert.

 

vor 19 Stunden schrieb Basic.Master:

Im Hexeditor kann man sehen, dass die Filler-NALU dort vorkommt (hier Video-ES der Aufnahme demultiplext), und der Block auch groß genug ist, dass ein Teil davon (auf TS-Ebene) verworfen werden müsste:

 

Vom Elementary Stream kannst du nicht ausgehen. Man muss sich schon den TS anschauen. Der Remover kann keine Pakete rauswerfen, die ein Adaptation Field mit einer PCR oder sonstwas enthalten. Siehe oben. Das taucht im ES nicht mehr auf.

 

[Basic.Master]

Ich verstehe es auch nicht...

 

vor 2 Stunden schrieb Griga:

Vom Elementary Stream kannst du nicht ausgehen. Man muss sich schon den TS anschauen. Der Remover kann keine Pakete rauswerfen, die ein Adaptation Field mit einer PCR oder sonstwas enthalten. Siehe oben. Das taucht im ES nicht mehr auf.

 

Nach dem oben gezeigten TS-Paket geht es in der Aufnahme mit folgenden TS-Paketen weiter:

 

  

 

usw.....ergo nur Payload und zwar genau der, den er hier eigentlich verwerfen müsste.

 

Filler-Entfernung bei H.264 geht übrigens, genauso wie bei UHD1 auf Astra 19,2°O, der in HEVC sendet und beim Hinweis-Standbild Filler-NALUs hat (die entsprechend vom DMS verworfen werden). Was den Unterschied macht, weiß ich nicht...

[Griga]

vor 4 Stunden schrieb Basic.Master:

Was den Unterschied macht, weiß ich nicht...

 

Ein Faktor, der das Eliminieren von Paketen verhindert, könnte die Angabe einer PES-Paketlänge verschieden 0 im PES Header sein. Gleich 0 bedeutet "unbestimmte Länge" und ist bei DVB Live Streams üblich, weil der Encoder die Länge im Voraus meist nicht weiß. Bei einer konkreten Längenangabe kann der Remover keine Pakete rauswerfen, weil die Länge dann ja nicht mehr stimmen würde.

 

Ob das der Fall war, lässt sich den obigen Screenshots nicht entnehmen. Es wäre ungewöhnlich, aber ich ich habe bei den von der ARD verwendeten Muxern/Encodern schon so manche Grausamkeit gesehen, insbesondere nach der Umstellung der Sat-Radiosender auf LOAS/LATM AAC. Damals bestand das Institut für Rundfunktechnik (IRT) schon nicht mehr, das vielleicht ein Auge drauf gehabt hätte, also blieb der Job mit vielen anstrengenden Analysen im Hexviewer und einem regen Mailaustausch mit der Technik des HR an mir hängen (siehe hier), natürlich ehrenamtlich - nicht mal meine Rundfunkgebühren habe ich erstattet bekommen

 

Gegen die Vermutung spricht, dass Martin K. nachträglich Pakete im TSPlayer eliminieren konnte, der den glichen Code benutzt. Trotzdem müsste ich mal eine Testaufnahme eines betroffenen Streams sehen, und zwar ohne entfernte Fülldaten... Transfer gegbenenfalls via WeTransfer. Eine solche Datei lässt sich für eine Live-Simulation in die Senderliste integrieren,  so dass ich sie mit dem DMS erneut aufnehmen kann.

 

[Basic.Master]

Bei dem PES-Paket, von dem ich die Screenshots gepostet habe, ist die PES-Länge auf 0 gesetzt. Kann es sein, dass im DMS (und ggf. auch DVBViewer) die PES-Länge pauschal mit 0 überschrieben wird? Denn bis zum nächsten PES-Paket hat die Video-PID ~35 TS-Pakete, deren Payload ergo ~6,5 KB ist und längenmäßig vom PES-Längenfeld abgebildet werden könnte.

 

Denn........ein Blick in einen kompletten, unveränderten Muxdump zeigt: Es kommt vor, dass es eine PES-Länge > 0 gibt (siehe Screenshot). Bisher kam mir dieser Fall noch nie unter; bei Video-ES habe ich da ausnahmslos immer 0 gesehen - wie du schon sagst, weiß der Encoder ggf. noch gar nicht, wieviel Platz er braucht. Und normalerweise ist das PES-Paket für ein Frame ja größer, als die 16bit es codieren könnten. Aber bei der Muxausnutzung bei DVB-T2 mit HEVC kann das natürlich auch mal kleiner sein. Ist ein ungewöhnliches Verhalten, aber ich sehe da jetzt erstmal keine Nonkonformität.

 

Man könnte die TS-Pakete innerhalb einer Filler-NALU hier dann ja trotzdem rauswerfen, indem man die PES-Länge für die Video-PID halt pauschal einfach immer auf 0 setzt (falls das nicht bereits passiert; s.o.) - egal, welcher Wert vorher dort stand.

 

Ja, bei der Inbetriebnahme der Radiosender per AAC hätte man tiefgehend testen sollen, bevor man damit on-air geht, auch wenn das öffentlich erstmal unter "Testbetrieb" lief. In diesem Zustand, offensichtlich ohne tiefergehende Prüfung, hätte man das nicht aufschalten dürfen....wäre mit dem IRT eher nicht passiert. So musste man dann im Nachgang die Fehler ausmerzen...gab ein schlechtes Bild ab und wäre absolut vermeidbar gewesen, in meinen Augen.

 

Warum der TSPlayer bei der DMS-Aufnahme trotzdem nochmal Fülldaten entfernt hat, ist echt ein Rätsel. Ich habe dir den Muxdump hochgeladen, siehe PN.

 

Edit: Natürlich kein Rätsel - wenn pauschal auf 0 gesetzt wird, dann werden im nächsten Durchlauf (TSPlayer) die Fülldaten dann entfernt.

 

Edited February 25 by Basic.Master

[Martin K]

vor 2 Stunden schrieb Griga:

 

Ein Faktor, der das Eliminieren von Paketen verhindert, könnte die Angabe einer PES-Paketlänge verschieden 0 im PES Header sein. Gleich 0 bedeutet "unbestimmte Länge" und ist bei DVB Live Streams üblich, weil der Encoder die Länge im Voraus meist nicht weiß. Bei einer konkreten Längenangabe kann der Remover keine Pakete rauswerfen, weil die Länge dann ja nicht mehr stimmen würde.

 

Die Länge setzen wir auf 0, das hatten wir damals schon berücksichtigt, Griga 😉

      //set PES_packet_length to 0 to avoid an erroneous length indicator if filler packets in ES payload are removed
      if (FHeaderPos <= 4) and (FHeaderPos + n > 4) then
        P[4-FHeaderPos] := 0;
      if (FHeaderPos <= 5) and (FHeaderPos + n > 5) then
        P[5-FHeaderPos] := 0;

 

[Martin K]

...vorher kopieren wir aber den Header in FHeader und:

FPESLengthPresent := PWord(@FHeader[4])^ <> 0;

Wobei das Paket behalten wird, wenn FPESLengthPresent gesetzt ist!

[Griga]

vor 10 Stunden schrieb Martin K:

Die Länge setzen wir auf 0, das hatten wir damals schon berücksichtigt (...) Wobei das Paket behalten wird, wenn FPESLengthPresent gesetzt ist!

 

Was wir in unserer Jugend alles veranstaltat haben ... war mir komplett entfallen. Das erklärt es natürlich. Ich wäre dem gestern abend weiter nachgegangen, aber dann hat sich mein Kater vor den Monitor gesetzt, so dass ich nichts mehr sehen konnte, und wollte dies und das.  Außerdem hatte ich ihm eine gemeinsame Nachtwanderung bei Mondschein versprochen, und wir waren erst gegen Mitternacht wieder zu Hause. Ist so'ne Art Petterson & Findus-Setup hier...

 

Danke, dass du die Klärung übernommen hast. Ich denke, FPESLengthPresent und das Beibehalten von Paketen, wenn die Variable auf true steht, kann entfallen. Ich weiß nicht mehr, ob mir damals die Konsequenzen klar waren, wenn es im Code verbleibt. Jedenfalls fliegt es jetzt raus, womit das Problem gelöst sein dürfte.

 

[Basic.Master]

Habe vor ein paar Tagen die DMS-Beta 3.2.5.2 mit dem Fix installiert; funktioniert bei mir soweit problemlos und löst das Problem.👍