x264 Frameanalyse (B-Frame-Häufigkeit)

[akapuma]

Hallo,

beim Encodieren mit x264 lasse ich max. 4 konsekutive B-Frames zu. Auf ein P oder I-Frame kann also folgendes folgen:

- kein B-Frame
- ein B-Frame
- zwei B-Frames
- drei B-Frames
- vier B-Frames

Gibt es ein Tool, daß mir obige Verteilung für den ganzen Film anzeigt, z.B. 250x0, 3257x1, 1742x2, 230x3, 97x4?

Gruß

akapuma

[Selur]

Mal die loglevel Einstellungen durchgechecked?

Cu Selur

[Kopernikus]

Mit dem -v Parameter gibt x264 dir detaillierte Statistiken zu jedem encodeten Frame aus. Da steht auch dabei welcher Frametyp. Falls dir das zu unübersichtlich ist, müsstest du vielleicht die ausgabe in eine Datei schreiben und mit einem Skript die Verteilung rauslesen.

[akapuma]

Mal die loglevel Einstellungen durchgechecked?Wo find ich die? Das müßten ja die Werte von 2ten Pass sein, oder steht schon beim ersten fest, welcher Frame was wird?

Falls dir das zu unübersichtlich ist, müsstest du vielleicht die ausgabe in eine Datei schreiben und mit einem Skript die Verteilung rauslesen.Leider gelingt es mir nicht, die Daten (z.B. mit >x264.log) in eine Datei umzuleiten.

Am liebsten wäre mir natürlich ein Tool, das alle Info's am fertigen Film ermitteln könnte.

Gruß

akapuma

[Kopernikus]

Leider gelingt es mir nicht, die Daten (z.B. mit >x264.log) in eine Datei umzuleiten.

Versuch mal sowas wie "x264 irgendwelche Optionen 1>x264.log 2>1 3>1" Damit wird stdout stderr und stdlog (oder so) auf die Datei umgeleitet.


Am liebsten wäre mir natürlich ein Tool, das alle Info's am fertigen Film ermitteln könnte.

Gruß

akapuma

Es gibt die Kommerzielle Variante Elecard Streameye für 300 $ (aber auch eine kostenlose Testversion)
http://elecard.com/products/product.php?product_id=146

oder du versuchst mal h264_parse aus dem MPEG4IPTools:

http://www.aziendeassociate.it/cd.asp?dir=/mpeg4iptools

Das funktioniert aber wahrscheinlich nur mit RAW Streams.

[LigH]

Oder so?

Noch mal für alle:

0 = stdin ("Programm < Eingabedatei" = "Programm 0< Eingabedatei")
1 = stdout ("Programm > Ausgabedatei" = "Programm 1> Ausgabedatei")
2 = stderr ("Programm 2> Fehlerprotokoll")

Dateihandle 3 kenne ich nicht als "Standard".

[Kopernikus]

Wie gesagt, oder so...;)

[akapuma]

Hallo,

der Tip von Kopernikus mit h264_parse war gut. Auch wenn ich per graphedit erst eine RAW-Datei draus machen (http://www.technik.movie2digital.de/thread.php?threadid=25288&sid=36d9bd5cddfa18773510f638586893d8) mußte (wo Selur sich überall rumtreibt:D)

h264 zeigt z.B. meine Encodingeinstellungen:
cabac=1 ref=6 deblock=1:1:1 analyse=0x3:0x133 me=hex subme=6 brdo=1 mixed_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=1 cqm=0 chroma_qp_offset=0 slices=1 nr=0 bframes=4 b_pyramid=1 b_adapt=1 b_bias=30 direct=2 wpredb=1 bime=1 keyint=300 keyint_min=25 scenecut=40 rc=2pass bitrate=490 ratetol=1.0 rceq='blurCplx^(1-qComp)' qcomp=0.60 qpmin=10 qpmax=51 qpstep=8 cplxblur=20.0 qblur=0.5 ip_ratio=1.40 pb_ratio=1.30.
Dann folgen die Info's zu den einzelnen Frames:
Nal length 987 start code 4 bytes
ref 3 type 5 Coded slice of an IDR picture
first_mb_in_slice: 0
slice_type: 7 (I)
pic_parameter_set_id: 0
frame_num: 0 (10 bits)
idr_pic_id: 0
pic_order_cnt_lsb: 0
Nal length 1482 start code 4 bytes
ref 2 type 1 Coded slice of non-IDR picture
first_mb_in_slice: 0
slice_type: 5 (P)
pic_parameter_set_id: 0
frame_num: 1 (10 bits)
pic_order_cnt_lsb: 10
Nal is new picture
Nal length 615 start code 4 bytes
ref 2 type 1 Coded slice of non-IDR picture
first_mb_in_slice: 0
slice_type: 6 (B)
pic_parameter_set_id: 0
frame_num: 2 (10 bits)
pic_order_cnt_lsb: 6
Nal is new picture
Nal length 291 start code 4 bytes
ref 0 type 1 Coded slice of non-IDR picture
first_mb_in_slice: 0
slice_type: 6 (B)
pic_parameter_set_id: 0
frame_num: 2 (10 bits)
pic_order_cnt_lsb: 2
Nal is new picture
Nal length 323 start code 4 bytes
ref 0 type 1 Coded slice of non-IDR picture
first_mb_in_slice: 0
slice_type: 6 (B)
pic_parameter_set_id: 0
frame_num: 2 (10 bits)
pic_order_cnt_lsb: 4
Nal is new picture
Nal length 339 start code 4 bytes
ref 0 type 1 Coded slice of non-IDR picture
first_mb_in_slice: 0
slice_type: 6 (B)
pic_parameter_set_id: 0
frame_num: 2 (10 bits)
pic_order_cnt_lsb: 8
Nal is new picture

Das war von, jetzt kommt ganz hinten:

Nal length 3878 start code 4 bytes
ref 2 type 1 Coded slice of non-IDR picture
first_mb_in_slice: 0
slice_type: 5 (P)
pic_parameter_set_id: 0
frame_num: 2 (10 bits)
pic_order_cnt_lsb: 4
Nal is new picture
Nal length 4833 start code 4 bytes
ref 2 type 1 Coded slice of non-IDR picture
first_mb_in_slice: 0
slice_type: 5 (P)
pic_parameter_set_id: 0
frame_num: 3 (10 bits)
pic_order_cnt_lsb: 6
Nal is new picture
Nal length 3753 start code 4 bytes
ref 2 type 1 Coded slice of non-IDR picture
first_mb_in_slice: 0
slice_type: 5 (P)
pic_parameter_set_id: 0
frame_num: 4 (10 bits)
pic_order_cnt_lsb: 8
Nal is new picture
Nal length 2548 start code 4 bytes
ref 2 type 1 Coded slice of non-IDR picture
first_mb_in_slice: 0
slice_type: 5 (P)
pic_parameter_set_id: 0
frame_num: 5 (10 bits)
pic_order_cnt_lsb: 10
Nal is new picture
Nal length 2429 start code 4 bytes
ref 2 type 1 Coded slice of non-IDR picture
first_mb_in_slice: 0
slice_type: 5 (P)
pic_parameter_set_id: 0
frame_num: 6 (10 bits)
pic_order_cnt_lsb: 12
Nal is new picture
Das Ergebnis verwirrt mich etwas. Was heißt "frame_num" und "pic_order_cnt_lsb"? Eine Duchnummerierung gibt's ja nicht, der Film hat (geschätzt) > 100000 frames.

Gruß

akapuma

[Kopernikus]

frame_num und pic_ord_cnt sind Laufvariablen, die relativ zum letzten IDR Frame laufen. In diesem Fall ist frame_num*2 = pic_ord_cnt, denn das Video ist progressive. Wenn es interlaced encodet wäre, würde mit mbaff und paff das alles nochmal anders aussehen.

[akapuma]

Bevor ich mich in den nächsten Tagen ans Auswerten mache: Die Reihenfolge der Frames ist doch die gleiche, wie sie abgespielt werden, oder? Also nix vertauscht wie bei XviD und packed bitstream?

Gruß

akapuma

[Kopernikus]

Nein, beide Werte steigen in Decoding Reihenfolge an, d.h. die Referenzen, auf die sich ein B-Frame bezieht, haben eine niedrigere frame_num als das B-Frame selbst. Die Reihenfolge in deiner Textdatei ist also eine andere als die Darstellungsreihenfolge.

[akapuma]

Hallo,

ich habe mal mit der Auswertung angefangen. Zuerst habe ich mal die Anzahl aufeinanderfolgender B-Frames gezählt:

1: 19798
2: 3009
3: 2040
4: 10768

Das hatte ich schonmal nicht erwartet! Ich hätte eher mit kleiner werdenden Zahlen gerechnet.

Ein Problem hab ich aber noch. Der Film beginnt von vorn wie folgt:
IPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBPPIPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPBPBBBPBBPBBBPBBPBBBPBBPBBPBBBPBBBPBBBPBBBBPBBPBPBPBPBPBPBPPPPPBPBPPPPPPIPBPBPBPBPBPBPBPBBPBPBPBBPBBPBBBPBBBBPBBPBBBPBBPBBPBBPBBPBBPBPBPBBPBBBPBBPBPBPBPBPBPBPPPPBPBPBPBPBPBPBPBPBPBPBPPBPPBPPPBPPBPBPPBPBPBPBPBPBPBPBPBPBPBBBBPBBBPBPBPBPBPPPPPPPPPPPPPBPBPBBBBPBBBBPBBBBPBBBBPBPIPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPBPBBPBPPPPPPPPBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBPBBBPBBPBBPBBPBPBPBPBPBPBPBPBPBPBPBPBPBPBPBPBPBPBPBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBPBBBPBBBPBBPBBPBBPBPIPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPBPBPBPBPBPBPBPPBPBPPBPBPBPBPBPBPBPBPBPB Erst kommt ein I-Frame, dann ein P-Frame, dann 4 B-Frames. Die Wiedergabereihenfolge lautet aber (wie ich Kopernikus verstanden habe) IBBBBP. Woran erkenne ich aber dann 0 B-Frames, also, wenn z.B. auf ein wiedergegebenes I-Frame ein wiedergegebenes P-Frame kommt? An der Reihenfolge "IP" jedenfalls nicht.

Gruß

akapuma

[LigH]

In MPEG-1/2 wird in einer GOP zu jedem Frame die Wiedergabeposition abgespeichert, wobei die Frames normalerweise in der Decodier-Reihenfolge im Datenstrom abgelegt sind (am Beispiel der verbreiteten 2-B-Variante):

Group Start Code
- Picture Start Code: I-Frame an Playback-Position 0
- Picture Start Code: P-Frame an Playback-Position 3
- Picture Start Code: B-Frame an Playback-Position 1
- Picture Start Code: B-Frame an Playback-Position 2
- Picture Start Code: P-Frame an Playback-Position 6
- Picture Start Code: B-Frame an Playback-Position 4
- Picture Start Code: B-Frame an Playback-Position 5
- ...

MPEG-4 kenne ich noch nicht auswendig; die Struktur wird hier eventuell etwas komplexer sein, aber generell sicher vergleichbar.

[akapuma]

Hallo,

ich glaube, das Zählen geht viel einfacher:
IBPBPBBPBBPBBBPBBBP
Zu jeder B-Frame-Gruppe (B, BB oder BBB) gehört anteilmäßig ein I oder P-Frame. Jetzt habe ich z.B. 20x1B, 10x2B, 5x3B und 8x4B = 43 B-Frame-Gruppen. Wenn ich jetzt in Summe 50 P+I-Frames habe, brauche ich für die B's aber nur 43. Daher habe ich 50-43=7 x 0 B's. (Genau genommen 50-43-1=6, da der Film mit einem I oder B enden sollte)

Gruß

akapuma

[akapuma]

Hallo,

ich hab mal was gebastelt:

- mache aus der mkv-x264-Datei eine RAW-Datei (siehe Post 8)
- mache mit h264_parse eine Log-Datei, z.B. h264_parse film.raw >film.log (siehe Post 5)
- rufe h264ex film.log auf

Man erhält auf dem Bildschirm:
x264 - core 44 svn-436 - H.264/MPEG-4 AVC codec - Copyleft 2005 - http://www.videolan.org/x264.html - options: cabac=1 ref=6 deblock=1:1:1 analyse=0x3:0x133 me=hex subme=6 brdo=1 mixed_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=1 cqm=0 chroma_qp_offset=0 slices=1 nr=0 bframes=4 b_pyramid=1 b_adapt=1 b_bias=30 direct=2 wpredb=1 bime=1 keyint=300 keyint_min=25 scenecut=40 rc=2pass bitrate=490 ratetol=1.0 rceq='blurCplx^(1-qComp)' qcomp=0.60 qpmin=10 qpmax=51 qpstep=8 cplxblur=20.0 qblur=0.5 ip_ratio=1.40 pb_ratio=1.30."

Frames: 136412
IDR: 1230 .9 %
I: 1332 .98 %
P: 60072 44.04 %
B: 75008 54.99 %

b0: 25788 72.41 %GB 0 %FB
b1: 19798 55.59 %GB 26.39 %FB
b2: 3009 8.45 %GB 8.02 %FB
b3: 2040 5.73 %GB 8.16 %FB
b4: 10768 30.23 %GB 57.42 %FB - Zuerst die verwendeten x264-Einstellungen
- Anzahl der Frames
- Anzahl der IDR-Frames
- Anzahl der I, P und B-Frames
- Häufigkeit konsekutiver B-Frames. %GB heißt Gruppenbezogen (auf die Anzahl der Häufigkeiten 0, 1, 2 etc. bezogen). %FB heißt Framebezogen. b2: 26,39%FB bedeutet, 26,39% aller B-Frames sind zu zweit

Man erhält noch zusätzlich 2 Dateien. In der einen stehen die Frames:
RPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBPPRPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPBPBBBPBBPBBBPBBPBBBPBBPBBPBBBPBBBPBBBPBBBBPBBPBPBPBPBPBPBPPPPPBPBPPPPPPRPBPBPBPBPBPBPBPBBPBPBPBBPBBPBBBPBBBBPBBPBBBPBBPBBPBBPBBPBBPBPBPBBPBBBPBBPBPBPBPBPBPBPPPPBPBPBPBPBPBPBPBPBPBPBPPBPPBPPPBPPBPBPPBPBPBPBPBPBPBPBPBPBPBBBBPBBBPBPBPBPBPPPPPPPPPPPPPBPBPBBBBPBBBBPBBBBPBBBBPBPRPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPBPBBPBPPPPPPPPBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBPBBBPBBPBBPBBPBPBPBPBPBPBPBPBPBPBPBPBPBPBPBPBPBPBPBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBBPBBBPBBBPBBBPBBPBBPBBPBPRPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPBPBPBPBPBPBPBPPBPBPPBPBPBPBPBPBPBPBPBPBP R bedeutet IDR-Frame

In der nächsten stehen Häufigkeiten der IDR-Intervalle:
(25,5)
(26,9)
(27,5)
(28,4)
(29,12)
(30,7)
(31,7)
(32,5)
(33,8)
(34,8)
(35,10)
(36,4)
........
Gruß

akapuma

[bond]

ich schätze mal, dass man über pic_order_cnt_lsb die display reihenfolge ableiten kann? nur geraten...

[Kopernikus]

@bond: nein, pic_order_cnt_lsb ist in decoding reihenfolge.

@akapuma: mmmh, ob man es sich so einfach machen kannn, weiß ich nicht, es können z.B. auch B-Frames als Referenzen verwendet werden.

[bond]

@bond: nein, pic_order_cnt_lsb ist in decoding reihenfolge.sicher? ich dachte decoding order ist storage order

wenn du dir die werte für pic_order_cnt_lsb ansiehst sieht man, dass sie für b-frames nicht mit der storage order übereinstimmen.

[Kopernikus]

Ok, ich habs nochmal genau nachgelesen:

pic_order_cnt_lsb specifies the picture order count modulo MaxPicOrderCntLsb for the top field of a coded frame or
for a coded field. The size of the pic_order_cnt_lsb syntax element is log2_max_pic_order_cnt_lsb_minus4 + 4 bits.
The value of the pic_order_cnt_lsb shall be in the range of 0 to MaxPicOrderCntLsb – 1, inclusive.

und

picture order count: A variable having a value that is non-decreasing with increasing picture position in
output order relative to the previous IDR picture in decoding order or relative to the previous picture
containing the memory management control operation that marks all reference pictures as “unused for
reference”.

und

output order: The order in which the decoded pictures are output from the decoded picture buffer.

somit steigt der pic_ord_cnt_lsb in Anzeigeeihenfolge an.

[akapuma]

somit steigt der pic_ord_cnt_lsb in Anzeigeeihenfolge an.und wird bei jedem IDR-Frame wieder auf 0 gesetzt. Dann werde ich mich nächste Woche mal hinsetzen und die Frames sortieren.

Sehe ich es richtig, daß ein IDR-Frame immer ein I-Frame ist?

Gruß

akapuma

[bond]

Sehe ich es richtig, daß ein IDR-Frame immer ein I-Frame ist?yep, ein ird-frame is ein i-frame vor das kein anderes frame referieren darf. dh wenn man nur 1 reference frame erlaubt ist jedes i-frame auch ein idr-frame

[akapuma]

yep, ein ird-frame is ein i-frame vor das kein anderes frame referieren darf. dh wenn man nur 1 reference frame erlaubt ist jedes i-frame auch ein idr-frameMit -r 6 lasse ich aber 6 reference frames zu.

Gruß

akapuma

[Selur]

:p

[akapuma]

:p????

Gruß

akapuma

[Selur]

:P sollte einen :zunge:-Simlie erzeugen

[akapuma]

Hallo,

jedes Frame hat einen "pic_ord_cnt_lsb"-Wert, der sich auf die Position nach dem letzen IDR-Frame bezieht. Soweit ich es erkennen konnte, werden die "pic_ord_cnt_lsb"-Werte nach jedem IDR-Frame auf null gesetzt. Die Info müßte mir doch ausreichen, um die Abspielreihenfolge bestimmen zu können.

Und was heißt -r 6? Wenn ein Frame auch auf Frames referenzieren dürfte, die außerhalb zweier IDR-Frames liegen würden (bis zu 6 Stück?), dann wäre der Film ja quasi unschneidbar.

Gruß

akapuma

[bond]

-r 6 bedeutet, dass ein frame maximal auf die 6 frames davor referieren darf

zb falls sich bei PPIPPP das letzte P auf das erste P bezieht wäre das I kein idr frame. falls das I ein idr frame wäre dürfte kein frame nach dem I auf ein frame davor referieren, dh das letzte P dürfte sich maximal auf das erste P nach dem I referieren

alles klar?

[Kopernikus]

H.264 verwendet einen etwas komplexeren Referenzmechanismus als die anderen MPEGs. Der Encoder kann im Bitstream einzelne Frames als short-term-references, long-term-references oder not-used-as-reference markieren. So kann sich ein Frame auf fast beliebige bereits dekodierte Frames in der selben GOP beziehen, nicht notwendigerweise auf die direkt davor oder dahinter. Aus den möglichen Referenzframes wird zu bei der Dekodierung eines Frames eine (bei B-Frames sogar zwei) Liste(n) zusammengestellt, die alle short-term und long-term references enthält. Aus diesen wird dann eine mit Bewegungsvektoren eine Vorhersage erstellt.

Die -r Option bei x264 gibt die maximale Länge dieser Liste an. Zusammen mit mixed-refs kann es also bei -r 6 sein, dass ein Frame auf bis zu 6 andere Frames bezieht. Diese können in der ganzen GOP wild verteilt sein.

[Selur]

Wichtig ist dabei halt, dass die GOP nicht verlassen wird, man also nicht mehr durch 'normal' I-Frames sondern nur noch durch IDR-Frames 'eingeschränkt' ist.

Cu Selur

[akapuma]

Hallo,

hier eine neue Version mit folgenden Änderungen:

- Alle Frames werden anhand der "pic_ord_cnt_lsb"-Werte sortiert
- In der Ausgabedatei mit den Frames werden diese entsprechend sortiert (in der Abspiel=Anzeigereihenfolge) ausgegeben
- In der Ausgabedatei mit den Intervallen werden die I-IDR-Frame-Intervalle sowie die I-non-IDR-Frame-Intervalle ausgegeben.

Interessant:
Ich habe eine mindest-GOP-Länge von 25 beim Encodieren angegeben. Folge:
Alle I-Frames, die weniger als 25 Frames auf einen IDR-Frame folgen, sind non-IDR-I-Frames.
Alle IDR-Frames, die nach 25 Frames auf einen IDR-Frame folgen, sind IDR-I-Frames

Gruß

akapuma

Edit 06.03.05: Version erneuert, alte nahm keine Parameter an

[akapuma]

Hallo,

neue Version:

- die letzte GOP wurde nicht ausgewertet
- bei den gruppenbezogenen b-Frame-Prozenten wurden zu hohe Werte angezeigt, da Gruppen mit 0 B-Frames nicht berücksichtigt wurden

Die beiden o.g. Fehler wurden behoben.

Gruß

akapuma

[akapuma]

der Tip von Kopernikus mit h264_parse war gut. Auch wenn ich per graphedit erst eine RAW-Datei draus machen (http://www.technik.movie2digital.de/thread.php?threadid=25288&sid=36d9bd5cddfa18773510f638586893d8) mußte (wo Selur sich überall rumtreibt:D)Hallo,

warum habe ich mkv2vfr via graphedit genommen, und nicht mkvextract?

Gruß

akapuma

[Selur]

weil mkvtoolnix das vermutlich noch nicht lange kann ? ;)

[akapuma]

weil mkvtoolnix das vermutlich noch nicht lange kann ? ;)Das wäre nicht auszuschließen. Auf jeden Fall ist mkvextract einfacher zu bedienen.

Gruß

akapuma

[Selur]

Stimmt, nur anfangs konnte mkvextract avc Streams nicht ordentlich raw extrahieren, irgendwann ging es dann über den DriectShowFilter mti graphedit und noch etwas später auch in mkvextract. ;)

Cu Selur

[akapuma]

Hallo,

ich verwende "h264_parse aka.raw", um einige Informationen über den Film zu bekommen.

Früher hatte ich aus dem Film im mkv-Container mit Haalis MP4 AVC to RAW converter via graphedit die raw-Datei aus der mkv-Datei extrahiert. h264_parse funktioniert damit.

Nun habe ich anstatt dessen mkvextract mit der gleichen Quelle probiert. h264_parse gibt aber folgendes aus:
h264_parse.exe - mpeg4ip version 1.5.5
couldn't find start code in buffer from 0

Ich habe mkvextract mit folgenden Varianten probiert:
mkvextract tracks aka.mkv --raw 1:aka.raw
mkvextract tracks aka.mkv --fullraw 1:aka.raw

Was mache ich falsch?

Gruß

akapuma

[bond]

zum einfachen ablesen wie die b-frames eingesetzt wurden kann man auch mp4videoinfo von mpeg4ip verwenden

Hallo,

ich verwende "h264_parse aka.raw", um einige Informationen über den Film zu bekommen.

Früher hatte ich aus dem Film im mkv-Container mit Haalis MP4 AVC to RAW converter via graphedit die raw-Datei aus der mkv-Datei extrahiert. h264_parse funktioniert damit.

Nun habe ich anstatt dessen mkvextract mit der gleichen Quelle probiert. h264_parse gibt aber folgendes aus:
h264_parse.exe - mpeg4ip version 1.5.5
couldn't find start code in buffer from 0

Ich habe mkvextract mit folgenden Varianten probiert:
mkvextract tracks aka.mkv --raw 1:aka.raw
mkvextract tracks aka.mkv --fullraw 1:aka.raw

Was mache ich falsch?

Gruß

akapumavermutlich erstellt mkvextract keinen 100% korrekten raw stream

[akapuma]

vermutlich erstellt mkvextract keinen 100% korrekten raw stream:heul:

Zumindest ist er kürzer:

haali: 223.516kB
mkvextract --raw: 223.359kB
mkvextract --fullraw: 223.399kB


Gruß

akapuma

[Mosu]

Nun habe ich anstatt dessen mkvextract mit der gleichen Quelle probiert. h264_parse gibt aber folgendes aus:
h264_parse.exe - mpeg4ip version 1.5.5
couldn't find start code in buffer from 0

Ich habe mkvextract mit folgenden Varianten probiert:
mkvextract tracks aka.mkv --raw 1:aka.raw
mkvextract tracks aka.mkv --fullraw 1:aka.raw

Was mache ich falsch?

Probier's mal ganz ohne "--raw" und ohne "--fullraw". Mit "--raw" schreibt mkvextract den Inhalt aus der Matroska-Datei 1:1 in die Ausgabedatei. In Matroska (und auch nicht in MP4-Dateien) wird h264 aber nicht als ES (elementary stream) gespeichert (in AVIs hingegen schon).

Wenn du "--raw" weglässt, so wird mkvextract einen gültigen h264 ES schreiben, der z.B. von mp4box oder meinen neuen mkvmerge-Versionen einlesbar sein sollte.

[akapuma]

Probier's mal ganz ohne "--raw" und ohne "--fullraw".Danke, Mosu, das war die Lösung.

Ich habe eine über 300MB große mkv-Datei einmal mit haalis m2r und einmal mit mkvextract in eine raw gewandelt und über beide h264_parse laufen lassen. fc zeigt folgende Unterschiede:
***** tante.mkvextract.txt
c:\pb35\h264_parse - mpeg4ip version 1.5.11
Nal length 28 start code 4 bytes
ref 3 type 7 Sequence parameter set
***** TANTE.HAALI.TXT
c:\pb35\h264_parse - mpeg4ip version 1.5.11
Nal length 33 start code 4 bytes
ref 3 type 7 Sequence parameter set
*****

***** tante.mkvextract.txt
vui_parameters_present_flag: 1
aspect_ratio_info_present_flag: 0
overscan_info_present_flag: 0
***** TANTE.HAALI.TXT
vui_parameters_present_flag: 1
aspect_ratio_info_present_flag: 1
aspect_ratio_idc:255
sar_width: 563
sar_height: 336
overscan_info_present_flag: 0
*****Bezüglich des SAR's hat allerdings haalis raw recht. Das stört mich allerdings nicht weiter, trotzdem zur Info.

Gruß

akapuma

[Mosu]

Bezüglich des SAR's hat allerdings haalis raw recht.

mkvmerge entfernt die AR-Informationen beim muxen. mkvextract fügt keine hinzu. Haalis Muxer fügt beim Muxen die AR-Informationen hinzu, wenn sie nicht existieren. Ich kann mir vorstellen, dass Haalis m2r die AR-Informationen beim Extrahieren ebenfalls hinzufügt, wenn sie nicht existieren.

[akapuma]

mkvmerge entfernt die AR-Informationen beim muxen. mkvextract fügt keine hinzu. Haalis Muxer fügt beim Muxen die AR-Informationen hinzu, wenn sie nicht existieren. Ich kann mir vorstellen, dass Haalis m2r die AR-Informationen beim Extrahieren ebenfalls hinzufügt, wenn sie nicht existieren.Das war's schon wieder. Im Stream waren gar keine AR-Info's drin, sondern nur im mkv-Container. mkvextract hat richtigerweise deshalb keine AR-Info verwendet, während Haalis m2r die AR-Info aus dem Container dem Stream zugeordnet hat.

Vielen Dank für die Info's.

Gruß

akapuma

[akapuma]

Hallo,

es gibt eine neue Version von h264ex:

Der RAW-Stream wird nun von h264ex mittels mkvextract selbst erzeugt. Der umständliche Weg über graphedit entfällt.
Es gibt noch mehr Info's.
Es gibt eine Beschreibung.Nützlich für alle, die die Wirkung von x264-Parametern testen wollen, die die Häufigkeit von Frames beeinflussen.

Gruß

akapuma

[LessThanJake]

mkvmerge entfernt die AR-Informationen beim muxen. mkvextract fügt keine hinzu.

Hallo,
getrieben von der Frage ob --sar das AR-Flag wirklich im Bit-Stream verankert oder vielleicht doch nur direkt bei Streamausgabe als DAR in den Container schreibt, verwirrt mich dabei obige Aussage.

Ein mit mkvextrakt erstellter Elementary-Stream hat bei mir immer noch das korrekte AR-Flag gespeichert, wie
a) erneutes muxxen mittels mkvmerge zeigt

mkvmerge v2.0.0 ('After The Rain Has Fallen') built on Jan 13 2007 19:58:31
'D:\AR-Flag-Test\1_Track1.h264': Using the AVC/h.264 ES demultiplexer.
Track 0 of 'D:\AR-Flag-Test\1_Track1.h264': Extracted the aspect ratio information from the MPEG-4 layer 10 (AVC) video data and set the display dimensions to 1489/576.


b) die Mplayer-Ausgabe ebenfalls korrekt erkennt (gleicher RAW-Stream)


Starting playback...
VDec: vo config request - 1024 x 576 (preferred colorspace: Planar YV12)
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is 2.59:1 - prescaling to correct movie aspect.

SwScaler: BICUBIC scaler, from Planar YV12 to BGR 24-bit using MMX2
VO: [directx] 1024x576 => 1490x576 Planar YV12


(Das Seitenverhältnis ist richtig, habe willkürlich --sar 16:11 auf eine 1024er Quelle angewandt).

Um das selber nochmals zu überprüfen drängt sich auch die Frage auf wie ich aus einem RAW-Stream nun das Flag auch wieder auslesen kann.

mkv-Info kanns nicht und h264_parse aus den mpeg4iptools aus dem Beitrag vorher listet es nicht.
Wer gibt nen Tipp?

(Sorry falls zu sehr offtopic.)
greets
LTJ

[Mosu]

Hallo,
getrieben von der Frage ob --sar das AR-Flag wirklich im Bit-Stream verankert oder vielleicht doch nur direkt bei Streamausgabe als DAR in den Container schreibt, verwirrt mich dabei obige Aussage.

Aaaaalso. Wenn mkvmerge AVC/h.264 aus einem h.264 ES oder einem MP4 liest (bin mir gerade nicht sicher, ob das auch für "Quelle ist Matroska" gilt), dann entfernt mkvmerge die AR-Informationen aus dem h.264 bitstream, sprich aus dem SPS (sequence parameter set).

mkvextract verändert das SPS beim Schreiben einer h.264 ES nicht.

Ein mit mkvextrakt erstellter Elementary-Stream hat bei mir immer noch das korrekte AR-Flag gespeichert, wie
a) erneutes muxxen mittels mkvmerge zeigt

Hmm, wurde die Datei vorher mit mkvmerge erstellt? mkvmerge kennt übrigens einen Parameter "--engage keep_bitstream_ar_info", bei dem die AR-Informationen nicht entfernt werden.

mkv-Info kanns nicht und h264_parse aus den mpeg4iptools aus dem Beitrag vorher listet es nicht.

mkvinfo liest wirklich nur Matroska-Dateien.

[LessThanJake]

...(bin mir gerade nicht sicher, ob das auch für "Quelle ist Matroska" gilt)...
gilt da auch, gerade eben nochmal probiert


Hmm, wurde die Datei vorher mit mkvmerge erstellt?

x264.exe kann den Video-Stream eigenständig in MKV ausgeben. Dies war auch die Quelle für mkvextract um den RAW-Stream zu erstellen und zugleich mein Denkfehler.
Als MeGUI-Benutzer bin ich bisher davon ausgegeangen, dass x264.exe grundsätzlich immer erst einen RAW-Stream erstellt und am Ende mkvmerge dazu benutzt um die Video-MKV zu erstellen, wenn für das Outputformat MKV gewählt ist.

Ich hab das von x264 geschriebene MKV also fälschlicherweise schon als "produced by mkvmerge" angesehen, wodurch meine Testergebnisse dann mit deiner, von mir zitierten, Aussage kollidiert ist.

Nun, die Welt ist wieder rund und alles ist gut, vielen Dank. :)
greets
LTJ

[akapuma]

Hallo,

siehe auch hier (http://forum.gleitz.info/showthread.php?t=32853).

1: mit x264 ein mkv mit der Option --sar 1:5 erstellt
2: ffshow zeigt beim Abspielen "SAR: 1/5 DAR: 1/4" an.
3: Stream aus 1 mit ogg und mkvmerke und der Option --aspect-ratio 1:11 gemuxt
4: Beim Abspielen zeigt ffdshow "SAR: 44/5 DAR 11/1" an.
5: Gemuxte Datei durch mkvinfo laufen lassen:
+ Video track
| + Pixel width: 320
| + Pixel height: 256
| + Interlaced: 0
| + Display width: 2816
| + Display height: 256
2816/256 => 11
6: h264_parse auf mit mkvextract extrahierte raw angewendet: "aspect_ratio_info_present_flag: 0"

Habe ich in Post #6 in obigem Link Blödsinn geschrieben? Bin etwas verwirrt.

Gruß

akapuma

[Mosu]

1: mit x264 ein mkv mit der Option --sar 1:5 erstellt

AR-Information im Bitstream vorhanden.

3: Stream aus 1 mit ogg und mkvmerke und der Option --aspect-ratio 1:11 gemuxt

mkvmerge entfernt beim Muxen die Bistream-AR-Informationen und traegt "11:1" bei "display width/display height" ein.

4: Beim Abspielen zeigt ffdshow "SAR: 44/5 DAR 11/1" an.

ffdshow wertet dabei hoechstwahrscheinlich die AR-Informationen des Containers aus -- sprich "display width/height" der Matroska-Datei.

6: h264_parse auf mit mkvextract extrahierte raw angewendet: "aspect_ratio_info_present_flag: 0"

Das ist richtig so. In Schritt 3 ist die Bitstream-AR-Information entfernt worden & mkvextract schreibt sie nicht wieder rein.

Alle Klarheiten beseitigt? ;)

[Brother John]

mkvmerge entfernt beim Muxen die Bistream-AR-Informationen
Warum entfernt mkvmerge eigentlich das AR-Flag? Mir will nämlich so recht kein Grund einfallen, warum man das Flag unbedingt ausschließlich im Container haben möchte. Bitte nicht als Kritik auffassen, schließlich gibt's ja einen Umschalter für das Verhalten. Mich interessiert nur der Grund.

[Mosu]

Warum entfernt mkvmerge eigentlich das AR-Flag? Mir will nämlich so recht kein Grund einfallen, warum man das Flag unbedingt ausschließlich im Container haben möchte. Bitte nicht als Kritik auffassen, schließlich gibt's ja einen Umschalter für das Verhalten. Mich interessiert nur der Grund.

Weil verschiedene Demuxer/Decoder sehr unterschiedlich auf AR-Informationen im Bitstream reagieren. Ich erzwinge damit das für Matroska richtige Verhalten. Bei Matroska gilt (und das sollte meiner Meinung nach IMMER gelten), dass die Container-Informationen die maßgeblichen Informationen sind. Damit das Playbacksystem gar nicht erst auf die Idee kommen kann, die AR-Informationen des Containers zu übersehen, entferne ich die des Bitstreams.

BTW: Container sind dafür da, um unabhängig vom verwendeten Inhalt generische Informationen zur Verfügung zu stellen: Timing, Videoauflösung, und auch die AR-Informationen. Es muss mit einem generischen Tool, das zwar mit dem Containerformat umgehen kann, aber nicht zwangsläufig das Bitstreamformat des Inhalts versteht, möglich sein, diese Informationen zu ändern. Deshalb: Container-Informationen wichtiger als Bitstream-Informationen.

[akapuma]

Hallo,

h264ex wird zur Zeit umfangreich überarbeitet. Ich habe festgestellt, daß sich mit x264 selbstgemachte Filme im Aufbau erheblich von elephants dream (Quicktime H.264) unterscheiden. Daher suche ich noch ein paar H.264 Testclips, erstellt mit unterschiedlichen Encodern. Kann mir jemand Quellen nennen? Es müßte doch auch Nero-H.264-Files geben? Was gibt es noch?

Gruß

akapuma

[Selur]

Files mit Quicktime Pro erstellt kann ich Dir erzeugen.

Ansonsten gibts da noch einige andere Encoder:
http://forum.doom9.org/showthread.php?t=95939
Nero, VSS, Elecard, Mainconcept, Quicktime, Sorenson und x264 sind aber vermutlich die verbreitetsten.

Cu Selur

[ac-chan]

Bei testclips empfielt es sich immer einen Blick auf den Samples Ordner von MPlayer zu werfen. Unter http://www.mplayerhq.hu/MPlayer/samples/ gibt es sowohl einen MPEG-4 als auch V-Codec Ordner. Was da nun genau für Codecs unter MPEG-4 zu finden ist kann ich nicht sagen. Unter V-Codec sind nochmal unterordner mit den entsprehenden FourCC als Ordnername.

[akapuma]

Hallo,

erstmal Danke für die Antworten. Ein Nero-Stück habe ich jetzt bereits zum Testen. Die geparste Datei sieht wieder anders aus. h264ex scheint noch reichlich Arbeit zu machen.

@Selur:
An einem Quicktime-Pro encodierten Stück wäre ich interessiert. Es sollte so lang sein, daß es aus mehreren GOP's besteht.
Zu Deinem Link: In der Liste stand auch AVIVO drin, das kann ich selber machen. Siehe Abspielprobleme (http://forum.gleitz.info/showthread.php?t=33822).

@ac-chan:
Danke, werd mal reingucken.

Gruß

akapuma

[Selur]

@akapuma: Encode dir heute abend ein paar Minuten.

mp4box sagt zu deinem File: [iso file] Box "avcC" size 48 invalid (read 49)

mkvtoolnix hat sogar dafür mal nen Fix eingebaut "MP4/QuickTime files which contain another atom before the 'avcC' atom in the video track headers weren't correctly remuxed."