Das Märchen von der hohen HD-Bitrate

Anzeige

AW: Das Märchen von der hohen HD-Bitrate

Hat was mit der Bitratenreservierung der Stax-Muxer zu tun. Die ersten 3 Generationen der AVC Encoder konnten extrem schlecht die tatsächlich benötigte Bitrate voraussagen, die haben dann in einer Post-Stufe zuviel reservierte Bitrate mit Filler aufgefüllt, da die Rückmeldung an die Stax ja keine Umverteilung zuviel reservierter Bitrate an andere Streams erlaubt. Ist ja Echtzeit. In der 1. und 2. Generation hat man eh mit konstanter Bitrate encodet, bzw. die Programme anteilig der Gesamtbitrate zugeordnet. Die mittlerweile 5. Generation der AVC Encoder hat bessere Voraussagen bzgl. benötigter Bitrate und kann andererseits zielgenauer eine vorgegebene Bitrate einhalten, sodass weniger Reserve nötig ist. In Echtzeit kann man Fehlentscheidungen nicht korrigieren, mehr als nötig ist Null-Auffüllung, weniger als notwendig ist Bildfalschdekodierung/-beschädigung. Letzteres muss vermieden werden, dadurch übermäßig mehr Reservierung.

Bleibt noch die Frage offen, warum Filler-NALU und keine NULL-Packet (1FFFh) - die Encoder liefern einen der Bitrate vorgegeben Bitstream an die Stax. Es ist marketingmäßig schwer zu vermitteln, warum die Bitrate so unsauber ist. Mit Filler NALU ergibt das eine schöne, den vorgaben entsprechende Bitrate. Technisch ist das für die STBs auch kein Unterschied.


Stax = Statistical Time Division Multiplexer (STDM oder nur TDM) ; führt die einzelnen Streams zusammen, die von den einzelnen Encodern kommen und kommuniziert mit diesen. Encoder und Stax können dabei Kilometer voneinander entfernt aufgestellt sein. Die Stax reserviert Bitrate für den Ausgabemultiplex und gibt eine Ober- und Untergrenze dynamisch an die Encoder weiter. Die Stax erstellt und verwaltet i.d.R. auch alle Steuerungsinformationen PAT/PMT/NIT usw. sowie (!) auch die Verschlüsselung via externer Paketmanipulation.

 

AW: Das Märchen von der hohen HD-Bitrate

Verschiedene Sender haben da unterschiedliche Präferenzen wie es scheint.

-Die dt ÖR senden nur noch wenige NALUs, und gar keine 1FFFh ( nur ein geringer Puffer ist vorhanden, wahrscheinlich auch wg. EPG etc.). NALUs sendet nur arte. Es wird zwar VBR gesendet auf allen ÖR HDs, aber sehr schwach schwankend, die Bitrate bleibt meist bei ihrem Durchschnittswert.
- Ausnahme WDR: der WDR setzt auf eine stark schwankende Bitrate, die keine NALUs enthält, dafür hat man eine hohe und stark schwankende 1FFFh Rate. Das liegt wohl auch an der Mischnutzung mit MPEG2 für die Regionalversionen und dyn. PMT Umschaltung.
- die deutschen HD+ Gängler setzen alle voll auf stark schwankende Raten, ohne NALUs, und auch kaum 1FFFh. Die verfügbare gesamte Nettorate wird statistisch komplett auf die Streams verteilt.
- die BBC setzt ebenfalls auf stark schwankende Raten, ohne NALUs, dafür sehr hoher 1FFFh Anteil auf den Transpondern. Die Encoder sind auf möglichst niedrige Datenraten optimiert, oft geht es auf unter 5Mbit/s runter. Es geht bei wirklich nur anspruchsvollen Inhalten rauf. Ansonsten werden "haufenweise" 1FFFh versendet.
- ITV sendet konstant mit 10Mbit/s, der zwischen 0,8-1Mbit/s NALUs enthält.
- Channel4 HD ist ähnlich, 9,7Mbit/s mit ca. 0,6Mbit/s NALUs.

 

AW: Das Märchen von der hohen HD-Bitrate

SUPER RTL HD scheint da eine Ausnahme zu sein.
Ich hab "Once Upon A Time" immer Mittwochs bei SUPER RTL HD aufgezeichnet. Da die bis einschließlich Folge 17 immer noch oben rechts dauerhaft "NEUE FOLGE" im Bild stehen hatten hab ich auch immer Sonntags (mit Ausnahme von Folge 11 und 15) die WDH bei RTL HD aufgezeichnet und die SUPER RTL HD-Aufnahmen wieder entsorgt. Ab Folge 17 haben sie die Einblendung dann wie gesagt weggelassen und ich hab nur noch Mittwochs bei SUPER RTL aufgezeichnet.

Die SUPER RTL HD-Aufnahmen sind allesamt nahezu bis auf den MB genau gleich groß (2,61 GB) während die RTL HD-Aufnahmen zwischen 1,4 und 2,1 GB schwanken. Die SUPER RTL HD-Bitrate liegt dabei nahezu konstant bei 9 MBit/s während die Bitrate bei RTL HD lustig hoch und runter geht. Hier mal der Vergleich zwischen zwei Episoden:

Folge 9 von RTL HD:


Folge 21 von SUPER RTL HD:


Keine Ahnung, ob die HD Austria-Sender auf dem Transponder von SUPER RTL HD auch konstant mit 9 MBit/s senden oder ob nur SUPER RTL HD davon betroffen ist.

 

AW: Das Märchen von der hohen HD-Bitrate

Geht das mit jeder Encoding Software? Bei Handbrake z.B. will er auch x.264 benutzen (und ne Bitrate genannt bekommen), bevor er das in .mkv umpackt und das wäre ja eine weitere Komprimierung, die man ja nicht haben will.

(Falls ich nicht antworte, hat die Post-Benachrichtigungsfunktion bei mir wieder nicht geklappt, also nicht als Desinteresse verstehen.)

 

AW: Das Märchen von der hohen HD-Bitrate

Wow -- Uralt-Thread re-aktiviert.

Handbrake kann nicht nur neu verpacken, du würdest auch neu encodieren.

Wenn du das nicht möchtest, nimmst du tsdoctor (das entfernt auch die NALUs), X-Media-Recoder oder ähnliches.

 

AW: Das Märchen von der hohen HD-Bitrate

*ausgrab*

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).

Im Forum für DVBViewer bzw. Recording Service habe ich mal vorgeschlagen, diese Fülldaten direkt beim Aufnahmen zu entfernen.
Für Aufnahmen, die schon gemacht wurden, habe ich den AFFcleaner entwickelt, der diese Fülldaten aus einem MPEG-TS entfernt:

 

AW: Das Märchen von der hohen HD-Bitrate

Die sind wahrscheinlich da, um besser dynamisch die Bitraten versch. Sender auf demselben Transponder verteiln zu können, aber gleichzeitig noch einen Puffer zu haben.

 

AW: Das Märchen von der hohen HD-Bitrate

Erstmal natürlich klasse, dass Du ein eigenes Tool entwickelt hast.
Ich fange gerade erst an mich damit zu beschäftigen, wie TS-Dateien am besten zu bearbeiten sind. Bisher las ich, dass TS-Doctor dafür sehr geeignet sei. Was ist denn der Unterschied von Deinem Tool zu TS-Doctor (außer dass das Geld kostet)? Was wäre für einen Anfänger zu empfehlen?

 

AW: Das Märchen von der hohen HD-Bitrate

Die Frage ist, was du mit deinen Aufnahmen machen möchtest:
Wenn du deine Aufnahmen im TS-Format belässt und nur diese speziellen Fülldaten hier entfernst möchtest, dann wäre der AFFcleaner das einfachste. Wenn du jetzt aber noch z.B. Vor-/Nachlauf wegschneiden willst oder in ein anderes Containerformat (z.B. MKV) umwandeln willst, dann wäre ein anderes Tool dafür nötig. Das könnte z.B. der TS-Doctor sein.

Im entsprechenden Unterforum http://forum.digitalfernsehen.de/forum/digitale-audio-und-videobearbeitung/ gibt es in Sachen Weiterverarbeitung von Aufnahmen einige Threads. Wenn du etwas bestimmtes machen willst, kannst du ansonsten aber auch einen neuen Thread erstellen.

 

AW: Das Märchen von der hohen HD-Bitrate

Diese neuen, speziellen TS-Paket-Fülldaten werden aber schon auch vom TS-Doctor entfernt, oder?