x264 '--fake-interlaced ' Option?

Hängt wohl damit zusammen, dass die BR-Spec's nur 1080p24 erlauben. Für die Wiederholraten 25/30 fps erlaubt BR nur 1080i.

(Ein weiteres Beispiel, warum Dark Shikari im Zusammenhang mit den BR-Spezifikationen so oft den Begriff "braindead" verwendet...)

"fake-interlaced" bedeutet imho nur, dass progessives Material im PAFF-Modus (also frame_mbs_only_flag: 0 und field_pic_flag: 0 im SPS) encodet wird (siehe u.a. auch hier und folgende Beiträge sowie hier). Dementsprechend sollte der Decoder auch keine Probleme mit dem progessiven Material bekommen.

Zitat von Selur

Code

--fake-interlaced       Flag stream as interlaced but encode progressive.
                              Makes it possible to encode 25p and 30p Blu-Ray
                              streams. Ignored in interlaced mode.

Frage: Fressen Blu-ray Player so was dann auch?

H.264 sieht zwei ja bekanntlich zwei "interlaced" Modi vor: MBAFF und PBAFF. Während bei MBAFF auf Makroblock-Ebene entschieden wird, ob ein Block interlaced oder progressive kodiert wird, wird bei PBAFF auf Frame-Ebene entschieden, ob das aktuelle Bild als ein Frame (progressive) oder als zwei Felder (interlaced) gespeichert wird. Dementsprechend müsste es zum Beispiel erlaubt sein, einen PBAFF "interlaced" Stream zu erzeugen, bei dem einfach sämtliche Bilder als progressive Frames kodiert sind. Und natürlich muss ein BluRay-Player einen solchen "gültigen" interlaced Stream dann auch akzeptieren. Der einzige Grund für die "Fake Interlaced" Option ist ja gerade die BluRay-Wiedergabe, bei der laut Standard bestimmte Auflösungen eben nur "interlaced" erlaubt sind.

Zitat von Selur

Bringt es Qualitätseinbußen beim Playback?
(Gedanke: Unnötiges Deinterlacen kann ja durchaus Probleme machen,...)

Das Deinterlacing ist ja normalerweise Aufgabe des Bildschirms, oder? Hängt dann vom jeweiligen Deinterlacer ab, würde ich sagen.

Heute sollte aber wohl jeder halbwegs vernünftige Hardware-Deinterlacer progressives Material als solches erkennen. Ansonsten sollte man den Schrott dem Händler um die Ohren hauen...

Zitat von Selur

Standardkonform ist es ja hoffentlich nicht progressives Material mit einem Interlaced Flag zu speichern.

Was sollte dagegen sprechen in einem MBAFF Stream alle Blöcke "progressive" oder in eine PBAFF Stream alle Bilder als "progressive" Frames zu speichern?

(Wenn in einem PBAFF Stream nicht mindestens "interlaced" Bild vor kam, kommt nach der Wiedergabe dann eine Fehlermeldung, oder wie ??? ^^)

Ist nicht beliebig, ist wie Bond hier schon schreibt, genau festgelegt:

"how to detect the interlacing used on an existing stream:

- progressive is signalled by setting frame_mbs_only_flag: 1 in the SPS
- interlaced is signalled by setting frame_mbs_only_flag: 0 in the SPS and field_pic_flag: 1 on all frames
- paff is signalled by setting frame_mbs_only_flag: 0 in the SPS and field_pic_flag: 1 on all frames that get interlaced and field_pic_flag: 0 on all frames that get progressive
- mbaff is signalled by setting frame_mbs_only_flag: 0 and mb_adaptive_frame_field_flag: 1 in the SPS and field_pic_flag: 0 on the frames (field_pic_flag: 1 would indicate a normal interlaced frame)

the mode of interlacing can be changed between the different SPSs"

Ist bei TV-Sendern ja auch schon lange Usus, auf diese Weise progressive Streams in einem interlaced-Modus zu verpacken. Dazu hier (Katarn12; erstellt: 21. Jan 2008, 17:13) noch ein Beitrag von vielen dazu, den ich grad fix noch hervorgekramt habe.

Zitat von Selur

Danke für die Infos, aber Sorry progressiven Content als Interlaced zu markieren halte ich für ne doofe Idee.

Das passiert ja auch gar nicht. Es gibt ein "frame_mbs_only" Flag, welches besagt, dass alle Bilder ausschließlich (progressive) Frames sind bzw. dass alle Blöcke in allen Frames progressive kodiert sind. Wenn dieses Flag nicht gesetzt ist, dann heißt das, es können sowohl (progressive) Frames als auch (interlaced) Felder in dem Stream vorkommen. Nicht mehr und nicht weniger. Wenn dann doch nur (progressive) Frames auftreten, dann ist das ja kein Widerspruch. Sinn macht das Flag trotzdem, z.B. weil es H.264 Profile gibt, in denen "interlaced" nicht erlaubt ist.

Zitat von Selur

So wie Du es darstellst könnte man sich die interlaced/progressive-Kennzeichnung auch einfach sparen und es einfach immer dem Deinterlacer des Fernsehers (hätte eigentlich vermutet, dass dies der Blu-ray Player übernimmt, aber egal) überlassen, dass der schon das richtige macht.

Nein, das kann man nicht machen. Wenn ein Stream (potentiell) interlaced Felder enthält, dann muss man das dem Decoder auch über das entsprechende Flag mitteilen. Ansonsten wäre der Stream schlicht und einfach ungültig. Ob nun der Player oder der Bildschirm das Deinterlacing durchführt und wie der verwendete Deinterlacer arbeitet ist eine ganz andere Frage. Aber das wird ganz einfach vom H.264 Standard nicht abgedeckt, da es mit dem Video an sich ja nichts zu tun hat. Sicher, ein adaptiver Deinterlacer könnte den H.264 Bistream auswerten. Aber da reicht es offensichtlich nicht, nur das "frame_mbs_only" Flag anzusehen! Man müsste im Fall "frame_mbs_only_flag == 0" dann schon für jedes einzelne Bild zwischen interlaced/progressive unterscheiden...

(Nicht zu vergessen, das selbst dann, wenn alle Bilder tatsächlich als "interlaced" Fields kodiert wurden, der eigentliche Inhalt immer noch "progressiver" Natur sein kann!)