AVC Format Irrgarten

Schwierig das zu erklären, wenn man nicht alle Varianten im Detail analysieren kann...

Zitat von gispos

Gibt es denn keine Standards für einen Containertyp wie TS mit h.264 Videostream?

Im Gegenteil:

Zitat

Das schöne an Standards ist, dass man sich aus so vielen einen aussuchen kann. (Aphorismus)

Zunächst mal gibt es wohl "mindestens" zwei Haupt-Varianten von Transportstreams, die verschieden lange Blöcke haben - TS und M2TS. Wenn sich ein TS-Splitterfilter darauf verläßt, dass Blöcke eine bestimmte Länge haben, unterstützen sie nur die Hälfte.

Dann gibt es verschiedene Varianten, Interlacing zu speichern - "picture adaptive" und "macroblock adaptive". Decoderfilter, die nur eine Variante beherrschen, kommen bei der anderen aus dem Takt. So lief es eine Zeit lang bei libavcodec (ffdshow, DGAVCDec).

Es ist durchaus richtig, dass verschiedene Hersteller sich für je eine der Varianten der damit zusammenhängenden Standards entscheiden, und jeweils eine andere bevorzugen als ein anderer Hersteller. Wer alle spezifikationsgetreuen Videos abspielen können will, muss auch alle Varianten unterstützen, die nach dem theoretischen Standard erlaubt wären. Nicht nur die, die ein praktischer Standard üblicherweise verwendet. Das jedoch geht auf Kosten der Effizienz.

Zitat von LigH

Dann gibt es verschiedene Varianten, Interlacing zu speichern - "picture adaptive" und "macroblock adaptive".

Sind die gängigen Abkürzungen dafür zufällig paff und mbaff?

greets
LTJ

Genau.

PAFF = Picture Adaptive Frame/Field: Alle Bilder dürfen in beliebiger Folge und unabhängig insgesamt als Vollbilder oder Halbbilder gespeichert werden;

MBAFF = Macro-Block Adaptive Frame/Field: Gruppen von bis zu 16x16 Makroblöcken eines Bildes dürfen jeweils unabhängig vollbildartig oder halbbildartig gespeichert werden.

So gesehen ist PAFF eigentlich einfacher zu implementieren... Wer weiß, warum libavcodec damit dennoch Probleme hatte. MBAFF ist flexibler und ermöglicht z.B. bewegte und starre Bereiche eines Bildes bei Interlaced-Material jeweils optimal zu encodieren. Dafür muss sich aber der Gewinn auch lohnen, um den Mehraufwand an Steuerinformationen auszugleichen.

Nun ja, sagen wir mal...

Ein Transport-Stream hat grundsätzlich ein paar feste Größen, insbesondere was den Aufbau von Header-Informationen angeht, aber auch variable Größen, beispielsweise die Länge eines Blocks. So hat M2TS 192 Bytes, das sind 4 Bytes mehr als TS in anderen Anwendungsgebieten: diese enthalten Timecodes, damit schnell beliebig in der Datei positioniert werden kann (was bei der Übertragung per DVB überflüssig ist - da wird gezeigt, was gerade empfangen wird).

Splitterfilter, die fest auf 188 oder 192 Bytes programmiert sind, finden jeweils schon beim zweiten Paket keine sinnvollen Headerdaten mehr, weil die entweder schon vor 4 Bytes kamen oder erst in 4 Bytes kommen. Nur ein Splitter, der "Byte für Byte" arbeitet, könnte sämtliche Varianten von Transportstreams verarbeiten, wäre dabei aber um ein mehrfaches langsamer als einer, der sich auf bestimmte feste Längen spezialisiert hat.
__

Ebenso die Decoder - nur mal als theoretisches Beispiel: Wenn die SONY-Kamera grundsätzlich nur PAFF verwendet, reicht es für den SONY-AVC-Decoder, nur PAFF zu decodieren. Setzt man ihm einen Videostream mit MBAFF vor, versteht er ihn nicht, weil die Programmierer von SONY eben einen auf die Kamera angepassten und keinen allumfassenden Decoder programmiert haben. Oder so ähnlich.

Bei libavcodec war es wohl genau anders herum. Vielleicht hatte ein Großteil der DVB-AVC-Streams ja MBAFF verwendet, weshalb das zuerst implementiert wurde, und Probleme mit AVCHD-Kameras wurden erst später bekannt?

Du vermischt auch gerade ein wenig Container und reinen Videostream im Sinne von RAW-Bytestream. Ein Container enthält immer Informationen darüber was, welche Art von Streams, in ihm stecken und zusätzlich weitere Informationen, wie bspw. Skalierungsfaktoren für anamorphe Quellen, Framerate, FourCC etc. Dazu muß erstmal ein Splitter her, der die Daten des Containers richtig verarbeiten kann.
TSRemux und TsMuxer sind im Grunde auch Splitter im weitesten Sinne, nur das sie Elementary Streams komplett in eine eigene Datei extrahieren und nicht Stück für Stück live an einen Decoder weiterleiten. Wenn diese nun bspw. einen m2ts-Container nicht sauber einlesen können, liegt das entweder daran, das der m2ts-Parsingprozess nicht sauber für alle Eventualitäten, die der Container bietet, gerüstet ist oder das Programm, mit dem zuvor die m2ts produziert wurde, nicht fehlerfrei arbeitet, beides ist denkbar.
Erst wenn ein fehlerfreies Splitten sichergestellt ist, sind wir bei dem Punkt der Dekodierung und das ist schon wieder ne ganz andere Geschichte und dann kommt das wieder zum Tragen was Ligh diesbezüglich auch schon meinte.
Der H264-Standard ist extrem umfangreich und ich wage zu behaupten, dass es keinen Decoder gibt, der sämtliche Features, die H264 bietet, implementiert hat. Demnach muß die Wahl des Decoders auf den Stream oder umgekehrt abgestimmt werden. Für diesen Zweck gibt es daher Level- und Profilbeschränkungen, an denen sich Programmierer und Entwickler von Hardware-Decodern orientieren können. Einen Header im eigentlichen Sinne gibt es bei H264 übrigens nicht. Der gesamte RAW-Bytestream ist in sog. NAL-Units aufgeteilt und jede davon hat eine Art eigenen Header. Notwendigerweise gibt es aber natürlich NALUs welche eine sog. Headerfunktion einnehmen. Die heißen Sequence Parameter Set (SPS) und Picture Parameter Set (PPS), die braucht ein Decoder zwingend um andere NALUs korrekt verarbeiten zu können. Anderes als bei bspw. MPEG4-ASP und MPEG2 können diese "Header"-NALUs aber mitten im Stream wechseln und dem Decoder somit signaliseiren: Hey, hier bitte anderes decodieren als gerade. Und das ist lange nicht alles was es so an Spielereien gibt, daher ist das schon eine kleine Herausforderung für einen Programmierer, der sein Werk gewissenhaft vollbringen will :).

greets
LTJ

H.264 steht keinesfalls am Anfang. Es wird bereits großflächig/erfolgreich im HDTV und auf BlueRay bzw. HD-DVD eingesetzt.
Und auch im Internet gewinnt es zunehmend an Bedeutung, nich erst seit der Flashplayer H.264 unterstützt.
Es gibt genaue Spezifikationen für H.264 und zusätzliche Einschränkungen für Hardware-Player (VBV, Profile, etc).
Das ist doch bei MPEG-2 prinzipiell nicht anders! Und auch MPEG-2 gibt es als ES, PS, TS, PVA und VOB.

Egal welches Format man verwendet, die Frage ist immer, was man damit machen will und welche Software man einsetzt.
Man kann nicht irgendeine Software benutzen, die gar nicht für das, was man vor hat, geeignet ist, und sich dann beschweren.
Wenn man sich im Klaren daüber ist, welches Material man vor sich hat, kann man auch die passende Software auszuwählen.
Und wenn es (noch) keine passende Software geben sollte, dann ist daran nicht der Standard schuld...

Zitat

Sony Vegas 8 als beworbenes AVCHD Produkt, öffnet nur mit Sony Cams aufgenommenes Material.

Es ist Sony, was hast du erwartet? …

Zitat

Ist h.264 nicht ein festgelegtes Kompressionsverfahren wie MPEG2.

Doch, aber nicht jeder Encoder/Decoder implementiert den kompletten Umfang. Es gibt keinen Zwang dazu, AVC in einem bestimmten Umfang zu implementieren, sondern nur offizielle Empfehlungen in form von Profilen und Leveln. Welche Features der En/Decoderhersteller tatsächlich unterstützt, ist allein Entscheidung des Herstellers. Kompatibilität mit der Konkurrenz (= anderer AVC-Software) steht dabei natürlich oft nicht unbedingt im Vordergrund. Freilich wärs schön, wenn AVC immer das selbe wäre, aber bring mal eine komplette Industrie mit vielfachsten Anwendungsgebieten so weit auf einen Nenner. Das ist von vorn herein zum Scheitern verurteilt.

Ich glaube, du musst dir erstmal vor Augen halten, dass AVC nur den Videostrom beschreibt. Audio-, Untertitel-, Container-, sonstige Formate sind davon erstmal unabhängig und prinzipiell austauschbar. Bei TS und M2TS ist ja containermäßig nicht das Ende erreicht. AVC passt auch bestens in Matroska oder MP4. Und wenn mans genug vergewaltigt, kann mans sogar in AVI prügeln.

Zitat

Wäre das nicht das gleiche als wenn es vom Standard DVD Format VOB (MPEG2) unterschiedliche Varianten geben würde, für die man sich jeweils einen Player kaufen müsste (siehe VHS, Beta, Video 2000)?

Das Verhältnis MPEG-2 <-> DVD ist in etwas vergleichbar mit dem Verhältnis AVC <-> BluRay. Einfach gesagt nehmen beide ein extrem flexibles Format, zurren das auf bestimmte Parameter fest und bauen noch ein bisschen Infrastruktur außen herum. Die Variantenvielfalt ist also nix Neues, die gibt es, seit es MPEG gibt.

Die DVD-Spezifikation ist beispielsweise die Spezifikation für den MPEG-Program-Stream, allerdings teilweise

- eingeschränkt (z.B. auf bestimmte Auflösungen)
- erweitert (z.B. Private-Streams mit detaillierten Angaben zum erlaubten Inhalt)
- konkretisiert (z.B. Blockgröße, maximale Anzahl bestimmter Streamtypen, Häufigkeit von Systemblöcken)
- darüber hinaus gehend (nicht mehr MPEG: logische Struktur der VOB-Dateien, IFO-Dateien zusätzlich)

Entsprechend ist das AVCHD-Format eine Abwandlung des MPEG-Transport-Streams in ähnlicher Weise, und DVB-Transport-Streams sind eventuell auf andere Art abgewandelt. Das geschah - wie schon erwähnt - in Hinblick auf den Verwendungszweck: Bei Fernsehsendungen steht eben z.B. Übertragungssicherheit im Vordergrund, bei Dateien auf Festplatte z.B. wahlfreier Zugriff.

Auch der AVC-Encoder in Kameras hat andere Prioritäten als ein AVC-Encoder im Studio: Während bei einer Aufzeichnung in der Kamera für den Encoder keine Zeit bleibt, das Video optimal komprimiert zu speichern (Echtzeit, aber fix!), müssen Fernsehstationen u.U. die Streams mehrerer Fernsehsender gegeneinander optimieren, um das Bouquet (Sendergruppe), das eine begrenzte Bitrate hat, sinnvoll auszulasten.