Quicktime/iTunes und ffdshow h264

@ Goldwingfahrer:

Auf DVD waren maximal 2 direkt aufeinander folgende B-Frames üblich. Das nächste P-Frame kam also spätestens nach 1 I/P-Frame + 2 B-Frames = nach 3 Frames, also M=3.

Auf BD sind heute maximal 3 direkt aufeinander folgende B-Frames üblich. Das nächste P-Frame kommt also spätestens nach 1 I/P-Frame + 3 B-Frames = nach 4 Frames, also M=4.

Es sei denn, der H.264 Encoder soll/will nur maximal je 2 aufeinander folgende B-Frames verwenden, wodurch dann auch keine B-Frame-Pyramide notwendig und sinnvoll wäre. Dann bleibt M=3.
__

@ Lupurus:

Was machst du eigentlich mit ffdshow? Willst du den VfW-Codec als H.264-Encoder benutzen?!

Du meine Güte, wie sie alle immer noch dieses tote Pferd "H.264 in AVI" reiten... :nein:

Und gerade in ffdshow wird der x264-Encoder nun wirklich nicht mehr gepflegt. Wenn es unbedingt nötig wäre, dann gäbe es mindestens zwei aktuellere x264vfw-Varianten ... ist es aber nicht. AVC gehört in MP4, zur Not in MKV. Und damit sollte mittlerweile eigentlich (trotz des völlig veralteten Namens) Avidemux umgehen können.

Zitat

Auf DVD waren maximal 2 direkt aufeinander folgende B-Frames üblich. Das nächste P-Frame kam also spätestens nach 1 I/P-Frame + 2 B-Frames = nach 3 Frames, also M=3.

Habe ich doch geschrieben.
GOP M=3

Andrerseits habe ich auch schon 3 "B" hintereinander gesehen.

[Blockierte Grafik: http://img23.imageshack.us/img23/156/gopmpeg2.png]

Musste nur noch suchen wo ich das damals gelesen hatte.
...ah..hier
http://www.radonmaster.de/robernd/tMPEG.html

Zitat

Avidemux kann meines Erachtens zumindest in der aktuellen Version immer noch nicht vernünftig mit h264 umgehen.

Lupurus
Darum bat ich Dich doch ein File im Netz hochzuladen.
Ich fange dann schon beim günstigsten Hilfstool an zu probieren.........

MediaInfo schreibt automatisch die x264-Optionen bei der Analyse in den Report (zumindest im vollständigen Modus), wenn diese im Kopf der Videospur als Text hinterlegt sind.

Wenn der Kopf weggeschnitten wurde, wird MediaInfo im Rest des Videos wohl diesen Text nicht mehr finden.

Ausschnitte von wenigen Sekunden können als Zitat gelten. Und einen Link zu einem Filehoster kann man auch per privater Nachricht zustellen, dann wird er nicht "öffentlich".

Hallo
Hab das File geladen und nur mal kurz reingeschaut.
Mein Videobearb.Programm spielts ohne Probleme ab und meckert erstaunlicherweise nicht mal.

VDub akzeptiert das File nicht da ich da nicht vorgesehen habe damit AVC und MP3 zu bearbeiten [es fehlt der vfw für x264]
http://frupic.frubar.net/fullsize/28535
Auch auf den Lav Splitter greife ich nur auf Bedarf zurück.

Ich werd schauen ob ich den gleichen Film hier mit meinem Digicorder ISIO-C empfangen kann.
Werde aber H.264 und wenns denn schon mp3 ist das Ganze sicher nicht in einen AVI-Kontainer schmeissen.

Zitat

Funktioniert es bei h264 überhaupt, dass ich eine GOP herausschneide und dann wieder einfüge?

Ja, es gibt keine Referenzen über GOP Grenzen hinweg.

Nur ist bei H.264 die "GOP-Grenze" ein IDR-Frame. Es kann auch weitere I-Frames geben, über die hinweg referenziert werden kann. Also nicht jedes I-Frame ist bei H.264 eine GOP-Grenze; und nicht jedes Schnittprogramm versteht den Unterschied zwischen I und IDR korrekt.

Ja, genau. Je nach dem, wie man nun "GOP" definieren möchte, ist Selurs Antwort falsch oder richtig. Keine Ahnung, ob es in den H.264-Spezifikationen eine offizielle Definition gibt. Auch kann ein I-Frame natürlich selbst auch von vorhergehenden (Display Order) bzw. nachfolgenden (Coding Order) B-Frames referenziert werden.

Mkvmerge ist übrigens ein Beispiel für ein Programm, welches nicht IDR- von Nicht-IDR-I-Frames unterscheiden kann.

Zitat

A GOP is an encoding of a sequence of frames that contain all the information that can be completely decoded within that GOP.

Quelle: IPTV Industry Dictionary
-> Wäre eher die Frage wie man Key-Frames definiert.

Ja, da geht es weiter. Diese ganzen Begrifflichkeiten, die sich immer noch aus alten MPEG-Versionen mitgezogen werden und die überall anders definiert werden. Letztendlich ist die Sache mit I-, P- und B-Frames selbst auch schon eine starke Vereinfachung - H.264 ist noch wesentlich komplizierter. Siehe z.B. periodic intra refresh.

Habe gerade die Spec durchsucht und weder "GOP" noch "Group of Pictures" tauchen dort ein einziges mal auf.

soweit ich mich entsinne musst wenn nach "group of video" bzw. gov suchen

Nein, beides ebenfalls nicht vorhanden. Am nächsten scheint noch "coded video sequence" zu kommen. Deckt sich dann mehr mit LigHs vom erstem IDR-Frame bis zum letztem Frame vor dem nächsten IDR-Frame.

Richtig. Die "eingestreuten" I-Frames sind dann nur für Fälle, in denen der Encoder nur drum herum, aber nicht für dieses eine Frame, ausreichenden Bezug zu anderen Frames finden kann, und die Codierung als P- oder B-Frame unvorteilhaft wäre (z.B. ein Frame, in dem das Bild komplett durch einen Blitz aufgehellt wurde).

Ein I-Frame ist ein Frame, der ohne Informationen aus anderen Frames decodiert werden kann. Also praktisch wie ein jpeg-Bild.
Ein IDR-Frame ist eine spezielle Art von I-Frame, über den keinerlei Referenzen führen. D.h. kein Frame nach dem IDR-Frame darf Frames vor dem IDR-Frame referenzieren und umgekehrt. (Frames vor dem IDR-Frame dürfen auch den IDR-Frame selbst nicht referenzieren.)
"Keyframe" ist nicht soo eindeutig definiert:
1.) alle I-Frames
2.) alle I-Frames, deren nachfolgende Frames (Display Order) nichts aus der Vergangenheit vor dem I-Frame referenzieren ("Recovery Points")
3.) nur IDR-Frames
Wenn's um Smart Renderung geht ist meistens 3.) gemeint.

Da VirtualDub noch aus der Zeit vor H.264 stammt, bin ich mir nicht mal sicher, ob man damit überhaupt jemals vernünftiges H.264-Smart Rendering hinbekommen wird. Würde mich evtl. nach anderen Produkten, wie z.B. SolveigMM Video Splitter umschauen.

Boilsoft Video Splitter wäre noch eine Idee. Hab den lang nicht mehr verwendet, war aber "früher" damit recht zufrieden.

snap027.gif