Das Märchen von der hohen HD-Bitrate

Anzeige

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

Realtime-Encoder "reservieren" bei H.264 Slots, wenn sie im Parallelmodus Bilder encoden. In diese Slots muss ein Teil (Slice) des Bildes passen. Dementsprechend wird komprimiert, bis es paßt. Die Größe der Slots wird statistisch ermittelt. Ist der Slot größer, als die komprimierten Daten, dann muss da irgendwas rein. Und da bietet H.264 viele Möglichkeiten. Die effektivsten ist via UserData/NULL NALU (die können Muxer am Ende nämlich entfernen und da andere Sender/Daten/Stream reinlegen). Ander Möglichkeit ist, Null-MBs einzufügen. Das sind Makroblöcke, die leer sind bzw. doppelt vorhanden sind. Klassisch wurde das bei MPEG-2 so gemacht, da werden Lücken aufgefüllt mit doppelten Slices. H.264 bietet noch weitere Möglichkeiten, wichtig ist aber, dass Muxer diese Lücken nicht entfernen bzw. anderswertig benutzen können, da diese im Binärstrom der Bilder enthalten sind und man diese nicht so einfach weg"muxen" kann.

Dass jetzt aber die SD-Bitrate unterschritten wird, stimmt aber nicht. Lücken entstehen nur dann, wenn die Ist-Bitrate kleiner der Soll-Bitrate wird. Ein Beispiel: Der Encoder soll einen Videostream mit 20 Mbit/s encoden. Dafür werden Slots statistisch den Bildern und Teilbildern zugeordnet. Passen diese Slices rein und ist noch Platz, müssen diese Slots aufgefüllt werden. Passen sie nicht rein, wird stärker komprimiert, bis es paßt. Senkt man nun die Bitrate, ergeben sich weniger Füller - aber natürlich werden auch zu "große" Bilder stärker komprimiert. Es geht somit auf die Qualität.

Richtigerweise muss man nun dazu sagen, dass am Ende der Muxer die NALU Füller nach der Encoderstufe wieder entfernen kann. Tun sich auch, wenn mehrere HDs zusammengemuxt werden. Es ist aber Unsinn, "NULL"-NALUs zu entfernen und dann den Transponder mit "NULL"-PIDs aufzufüllen, denn der Transponder muss immer voll sein. Die perfekte Slot-Zuordnung für die Encoder, sodass immer ein perfektes Bild entsteht - das ist aktuell noch das technische Problem. Weil man immer erst nach dem Encoden weiß, wieviel optimal gewesen wäre - das aber nicht mehr rückwärts in der Zeit an den Encoder melden kann.

 

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

Könnte man nicht den Encoder mitschreiben und aufzeichnen lassen wieviel optimal gewesen wäre.. und wenn er dann das wieder mal encodieren muss (z.B. den selben Film) ..macht er es perfekt

 

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

Versteh ich nicht ganz, warum sollte man die nicht entfernen? MarcN hat es doch auch gemacht und bekommt so eine viel niedrigere Datenrate...

Hmm, haben die MPEG2 Datenströme denn auch so viele Lücken (Null-MBs), dass diese ohne die Lücken auf ca. die Hälfte schrumpfen würden? Falls nein, so hat man ohne diese Lücken im H.264 im Endeffekt schon die selbe Bitrate wie bei SD, wenn ein ganzer Spielfilm auf einen DVD-5 Rohling passt
Uns interresiert ja im Endeffekt nur, wie man Aufnahmen ohne Qualitätsverlust möglichst klein kriegt, und das Entfernen der Filler-NALus scheint da sehr effektiv zu sein.

Okay, den Transpondern ist es natürlich egal, aber wir als Endverbraucher hätten schon einen Nutzen wenn Aufnahmen dadurch nur noch halb so groß sind

 

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

1280x720 * 12/8 = 1.382.400 Pixelwerte (4:2:0 YUV-Farbraum)

Jeder hat einen Wert von 16..240 (verschoben um -128 für UV) macht insgesamt 224^1382400 Bildermöglichkeiten. Wir haben nur 1e80 Quarks im Universum zur Verfügung, damit wäre eine Speicherung der besten Encodereinstellungen pro Bild schon mal nicht mehr machbar. Selbst bei Reduktion der Bilddaten ist schnell Schluss.

Filme usw. könnte man in der Tat vorher Multipass-Encoden und dann einfach einfüttern. Aber bei Live-Übertragungen geht das dann nicht mehr. Und wenn man für Live was anderes braucht benutzt man das für Live benutzte System für alles. Man tauscht ja den Motor auf der Autobahn auch nicht aus und verwendet bei Stadtfahrten einen anderen.

Bei Internetstreaming-Angeboten (der Pixelmatsch dt. Anbieter ist nicht gemeint, Deutsche Unternehmen sind zu doof und deutsche Kunden sind abspruchslos) - also bei echten Streaming-Angeboten, wird der Internetstream 1-2 Minuten versetzt gesendet und in dieser Zeit optimal encoded. Pseudomultipass. Das liefert dann optimales Bild pro Bandbreite.

 

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

Um Null-MBs zu entfernen muss der Muxer die Daten binär dekodieren, säubern und reencodieren. Der Vorgang ist verlustfrei, aber rechenintensiv. NALUs zu entfernen ist dagegen primitiv, Startcode suchen, und löschen bis zum nächsten Startcode. Das andere wäre, komplett auf Strukturebene zu entpacken, dazu VLC/Huffman Decodierung - die Duplikate über Listen erkennen, entfernen und zurück VLC/Huffmann Encoden. Keines dieser Vorgänge ist verlustbehaftet, nur "teuer" im Sinne von Rechenleistung.

MPEG-2 läßt sich auch optimaler packen, verlustfrei. Nachträgliche Vertical Motioncompensation ist bei den Realtime-Encodern eh durch die Parallelisierung unterentwickelt. Slice-Duplikate entfernen. Alignment usw. Da kommen je nach Bewegung 2-5% zusammen.

Bei H.264 läßt sich noch deutlich mehr machen. Arithmetische Kodierung, optimierte Huffman-Tabellen verwenden über die Filmlänge, Slot/GOP-Restrukturierung, BI-Frames usw - viel, viel Rechenaufwand und dann sind bei Realtime-Encodern so um die 15-20% drin. Das ist zwar ne Neukodierung, allerdings ist das dekodierte Bild identisch - die Umwandlung verlustfrei.

 

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

Einen Versatz von 1-2 Min. würde ich für eine bessere Bildqualität bei niederiger Datenrate (also einer effizienteren Encodierung durch Multipass) gerne in Kauf nehmen. Spielt ja für den Sender auch keine Rolle, wenn er Sachen "vom Band" einfach 1-2 Min. "früher rausschickt" (damit EPG usw. wieder stimmen).
Bei Live-Übertragungen könnten man dann ja wieder mit diesen Slots und Filler-NALUs arbeiten, damit man hier keine so große Verzögerung hat. Ich denke das düfte nur ein kleiner Schalter am Encoder sein, vergleichbar mit Umschaltung 4:3/16:9 (bei SD, bzw. beim H.264 Encoder muss hier dann ja auch zwischen Pillarbox umgeschaltet werden) oder die Umschaltung 2.0/5.1 bei AC-3, aber keinesfalls eines Motorwechselns auf der Autobahn... vielleicht eher dem Gangwechsel, um beim Beispiel zu bleiben, oder fährst du auch in der Innenstadt im 5. Gang?

 

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

Hey, ich predige seit Jahren, dass H.264 im TV Bereich reiner Schwachsinn ist. Diese Format ist nicht ausgelegt für Echtzeitencodierung in Kombination mit niedrigster Bandbreite. Dirac (Wavelet-Compression) ist dem um Welten voraus. Im professionellen Bereich setzt NIEMAND H.264 als Kompressionsstandard in der Produktion ein, der "Mist" wird nur auf die Konsumenten losgelassen. Auf Medien ist das natürlich was anderes, da erreicht H.264 sein Optimum. Sieht man doch an den Esel TV-Stream im Internet.

MPEG-4 ist nur ein durch einen dämlichen Hype entstanden, erinnert etwas an VHS/Beta, und da jeder sein eigenes H.264 kurzzeitig entwickelt hat. Apple(Quicktime), Sorenson, Microsoft(WMV, später VC-1), DivX (die blieben aber bei ASP hängen) - und irgendwann ging dann der Blödsinn in die DVB-Spec ein.

 

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

Ist denn diser Versatz fest "planbar" oder hängt der vom zu sendenden Material ab? (sorry, hab von dem ganzen Thema hier Null Ahnung aber es fasziniert mich trotzdem )

Wenn er nämlich nicht immer gleich ist wäre es ja für die Sender unmöglich irgendwelche SEndezeiten einzuhalten

PS: Was ist ein Esel TV Stream?

 

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

Der Versatz ist fest planbar. Man könnte im DVB-Bereich fix einen 15s Versatz einbauen und dann 2 Encoderstufen benutzen. Die erste Stufe voranalysiert das Bild und schickt diese Infos an die 2. Encoderstufe. Dann wäre das Bild deutlich optimaler. Könnte man z.B. bei Sky auf allen Nicht-Sport-Sendern machen.

Ich arbeite aber nicht für Sky und deren Leute sind einfach viel zu klug für diese Idee. Drum erfreue ich eben LM mit meinen Ideen.

 

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

Hab gerade mal nach diesem Dirac gegooglet un das hier gefunden: http://www-ee.uta.edu/Dip/Courses/EE5359/ArunaRavi_MSThesis.pdf

Da steht in der Zusammenfassung das H.264 und Dirac was die Qualität anbetrifft ungefähr gleichauf sind.. H.264 wäre sogar noch ein bischen performanter. Warum ist Dirac dann besser geeignet für Broadcasting?