x264 Frameanalyse (B-Frame-Häufigkeit)

bond

Zitat von akapuma

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

Zitat von bond

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

Mit -r 6 lasse ich aber 6 reference frames zu.

Gruß

akapuma

Selur

:p

akapuma

Zitat von Selur

:p

????

Gruß

akapuma

Selur

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

Zitat von akapuma

der Tip von Kopernikus mit h264_parse war gut. Auch wenn ich per graphedit erst eine RAW-Datei draus machen 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

Zitat von Selur

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

Zitat von 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

Alles anzeigen

vermutlich erstellt mkvextract keinen 100% korrekten raw stream

akapuma

Zitat von bond

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

Zitat von akapuma

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

Zitat von Mosu

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:

Code

***** 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
*****

Alles anzeigen

Bezüglich des SAR's hat allerdings haalis raw recht. Das stört mich allerdings nicht weiter, trotzdem zur Info.

Gruß

akapuma

Jetzt mitmachen!