AVC raw-stream schneiden - fast ohne Neukodierung

may24

Selur. Dank mencoder habe ich es geschafft das video in einen avi Container zu packen (mencoder -ovc copy -oac copy -o video.avi video.mkv).
Nur leider ist VirtualDub nicht in der Lage den File wiederzugeben und demzufolge auch nicht (richtig) zu bearbeiten.
Zwar wird mir die korrekte Länge und Anzahl der Frames angezeigt, jedoch gibt's nur "schwarze Bilder" und immer noch beschwert sich VD das der encoder (x264vfw) zwar den Stream codieren kann aber die Optionen dafür nicht passen.

MPC kann ebenfalls das avi nicht wiedergeben. Einzig und allein VLC konnte das ...

Tatsächlich ist es so das z.B. avinaptic mir die PPS info's nicht anzeigen kann. Auch GSpot und Mediainfo machen da ziemlichen Ärger.

Ich habe da so'ne Theorie: Laut DGAVCIndex beginnt das erste IDR bei 0x029a.
Schaut man sich das aber im HexEditor an, so stellt man fest das es aber schon bei 0x0299 anfängt. Jetzt weiß ich allerdings nicht ob Donald Graft bei "1" anfängt zu zählen oder bei "0" (was die Bytepositionen angeht ...)
Deshalb waren meine ersten Cut-Versuche auch nicht gerade erfolgreich
Gibt es ein Byte das die Länge des PPS beschreibt ? Denn vielleicht ist das der Grund warum die PPS infos nicht bzw. falsch wiedergegeben werden ...

LessThanJake Vielen 10^9 Dank !!!
Deine Erläuterungen wahren mehr als nur sehr hilfreich. Ohne deine Info's hätte ich es nie geschafft.

Ja, es klappt jetzt :ja:

LessThanJake

Zitat von may24

Gibt es ein Byte das die Länge des PPS beschreibt ?

Nein, gibt es nicht. Der Decodingprozess ist bei H264 nicht linear. Das heißt es gibt keine Struktur im Sinne von fest aneinandergereihten Bitschematas, die immer genau an der selben Stelle im Stream zu finden sind, wie bspw. beim MP3-Header. Vielmehr besteht ein H264-Stream aus einer Aneinandereihung von NAL-Units, deren Typ man nach oben erläuterter Regel bestimmen kann. Nach der Identifizierung wird jeder NALU-Typ nach eigenen Regeln dekodiert. Dabei sind einzelne Elemente innerhalb dieser NALU zum Teil wiederum mit unterschiedlichen Verfahren kodiert. Im Klartext heißt das man kann bspw. Element 3 erst auslesen, wenn Element 1 und 2 zuvor dekodiert wurden. Die NALU wird dann so Schritt für Schritt bis zum nächsten Startcode (00 00 00 01) durchgeparst. Wie lang die NALU in Bytes ist spielt dafür keine Rolle, deshalb wird das nirgends gespeichert.
Wenn du wissen willst wie groß eine NALU in Bytes ist, kannst du sie im Hexeditor markiereren (Startcode bis nächster Startcode) und den Wert dann ablesen. Alternativ geben die diverse Analysetools aber auch die NALU-Size an, bspw h264parse von den mpeg4iptools oder ldecod_trace, hier werden die "emulation_prevention_three_bytes" allerdings rausgerechnet. Wenn du nichts programmieren willst, dann ist das aber eigentlich nicht weiter von Bedeutung und es reicht schon aus, wenn man den Stream anhand der Startcodes "lesen" und bearbeiten kann.

greets
LTJ

Jetzt mitmachen!