H.264 NALU Byteausrichtung

Ich versuche, die H.264 NALU-Header in den folgenden Daten in einem MOV-Container Kopf zu bekommen.H.264 NALU Byteausrichtung

Beispiel aus der Datei:

00 00 00 02 09 30 00 00 00 0E 06 01 09 00 02 08 
24 68 00 00 03 00 01 80 00 00 2B 08 21 9A 01 01 
64 47 D4 B2 5C 45 76 DA 72 E4 3B F3 AE A9 56 91 
B2 3F FE CE 87 1A 48 13 14 A9 E0 12 C8 AD E9 22 
...

Bisher habe ich angenommen, dass der Bitstrom nicht aufgrund der Startcode-Sequenz an die ein Bit nach links versetzt Byte ausgerichtet ist:

0x00 0x00 0x00 0x02 -> 00000000 00000000 00000000 00000010

Also habe ich diese und nachfolgende Bytes auf das richtige ein Bit verschoben, was zu dem folgenden Startsequenzcode und den Anfangsblockbits für den ersten Anfangsblock führt:

0000000 00000000 00000000 00000001 [0 00 00100]

aber ich unstuck komme, wenn ich im Beispiel folgenden Bytefolge reach:

0x00 0x00 0x00 0x0E

es ist ein weiterer Startsequenz Code Ich gehe davon aus, aber mit einer anderen Byte-Ausrichtung.

00000000 00000000 00000000 00001110 00000110 00000001 00001001 00000000

Nach Byte-Ausrichtung ich folgende Headerbyte bin immer:

00000 00000000 00000000 00000001 [1 10 00000]

Das erste Bit im Header (der forbidden_zero_bit) nicht Null ist, die die Regel verletzt, dass es Null sein muss

Wo stolpere ich?

Mache ich hier falsche Annahmen?

Quelle

2016-04-26 Pobbel

Wie bereits beantwortet, verwendet der MOV-Container (oder MP4) keine Annex B-Codierung mit Startcodes. Es verwendet MP4-artige Codierung, wobei NALs das Feld NALUnitLength vorangestellt wird. Dieses Feld kann eine andere Größe haben (und diese Größe wird an einer anderen Stelle im Container angezeigt), aber normalerweise sind es 4 Bytes. In Ihrem Fall ist NALUnitLength wahrscheinlich 4 Bytes und 3 NALs von Ihrem Dump haben die Größen: 2-Byte (00 00 00 02), 14-Byte (00 00 00 0E) und 11016-Byte (00 00 2B 08).

Quelle

2016-04-26 17:58:56 nobody555

Danke nobody555, diese zusätzliche Information hilft viel und macht jetzt mehr Sinn. Ich werde dies mit den Atomdaten der Stichprobengröße für meinen eigenen Nutzen bestätigen müssen, aber für jetzt hat dies klar gemacht und macht jetzt Sinn. Prost. – Pobbel

Ich habe bestätigt, dass dies tatsächlich zu den Atomgrößen wie beschrieben passt. Ich kann keinen Verweis auf diese Kodierung in der MOV-Entwicklerreferenz finden https://developer.apple.com/library/mac/documentation/QuickTime/QTFF/QTFFPreface/qtffPreface.html Ist diese Kodierung Teil von ITU-T H.264 oder vielleicht ISO/IEC 14496-15? – Pobbel

Es ist nicht Teil der ITU-T H.264-Spezifikationen sicher.Wie für ISO/IEC 14496-15 ist das wahrscheinlich, aber ich habe keinen Zugriff darauf (es ist nicht kostenlos) und kann das also nicht überprüfen. – nobody555

Startcodes werden im Byte-Stream-Format (H.264 Anhang B) verwendet und sind selbst Byte-ausgerichtet. Der Decoder soll den Startcode durch Überprüfung der Bytefolgen ohne Bitverschiebungen identifizieren.

MOV, MP4-Container verwenden keine Startcodes, jedoch haben sie ihre eigene Struktur (Atome, Boxen) mit Parametersatz NAL-Einheiten ohne Präfixe in Beispielbeschreibungsatomen und dann Daten selbst getrennt als ursprüngliche NAL-Einheiten.

Was Sie zitiert haben, ist vermutlich ein Fragment von MOV-Atomen, die Dateistrukturbytes und nicht NAL-Einheiten entsprechen.

Quelle

2016-04-26 12:14:43

Danke Roman. Ja, die Daten stammen vom Anfang des 'mdat'-Atoms. Ich werde etwas mehr auf H.264-Codierung speziell im MOV-Format lesen müssen. – Pobbel

Antwort

Verwandte Themen