x264, --min-keyint = auto?

Müsste man mal in den Sourcecode gucken, glaube nicht, dass auto pauschal = 10 ist, sondern eher, dass es auf 10 gesenkt wird, wenn keyint eine gewisse größe Unterschreitet. (vielleicht setzt auto auch einfach auf fps/10, was ich für einen sinnigen Wert erachten würde)

Cu Selur

Zitat

Glaub ich auch nicht. Bei 25fps wäre das ja gerade einmal 2,5!

meinte keyint

keyint*0.1 keyint sollte mittlerweile übrigens reichen, da sich seit dem ich das mit dem 0.4 geschrieben habe einiges gebessert hat. (Open GOP könnte noch interessant sein, aber vom OpenGOP-Patch hab ich - eine gefühlte Ewigkeit - nichts mehr gehört.

Dark_Shikari bestätigt im IRC: "--min-keyint auto" ist nur "keyint / 10".

Schön, dann kann ich mir ja sparen im Sourcecode nachzugucken.

Vielleicht will er's sogar mal ganz entfernen, es sei eigentlich nicht mehr wirklich notwendig. Würde bedeuten, dass eine vollautomatische Entscheidung, wann überhaupt ein I/IDR-Frame nötig sei, zuverlässig genug sei. Ausnahme wäre vielleicht der Zero-Latency-Modus ohne B-Frames.

Unterschied I und IDR Frames, bei keyint und min-keyint geht es um IDR Frames also Keyframes im eigentlichen Sinne.
Yup, bei Stroposkopszenen und dergleichen sind I-Frames sinniger als IDR Frames.

Wenn DS meint der Wert könnte wegfallen, wäre das sicher interessant, wobei ich hoffe, dass der Open GOP Patch vorher noch in den Git MainBranch wandert. Vorher sollte er aber noch so angepasst werden, dass man immer noch über das qpFile IDR-Frames erzwingen kann (damit man z.B. an Kapitelmarken IDR-Frames erzwingen kann).

Für mich ist 125 / 25 = 5.

Und bedenke auch: Je weiter Keyframes entfernt sind, umso länger halten sich Decodierfehler.

Zitat von Selur

Wenn DS meint der Wert könnte wegfallen, wäre das sicher interessant, wobei ich hoffe, dass der Open GOP Patch vorher noch in den Git MainBranch wandert. Vorher sollte er aber noch so angepasst werden, dass man immer noch über das qpFile IDR-Frames erzwingen kann (damit man z.B. an Kapitelmarken IDR-Frames erzwingen kann).

Das mit dem Erzwingen über qpfile ( "K" vs "I") ist definitiv geplant bzw. schon implementiert, aber wozu sollte man an einer Kapitelmarke IDR-Frames erzwingen? Das ist doch eigentlich nur nötig, wenn die erste GOP eines neuen Kapitels die vorhergehende (also letzte GOP des alten Kapitels) referenziert. Der OpenGOP-Patch verursacht aber nur, daß die vorhergehende GOP die neue referenziert, also nur in eine Richtung. Oder irre ich mich? (Bin selber etwas verwirrt durch das alles)

P.S.: Neuer OpenGOP-Patch und Binary sind im englischen Doom9 verfügbar.

Zitat

Das mit dem Erzwingen über qpfile ( "K" vs "I") ist definitiv geplant bzw. schon implementiert, ...

Ging an sich ohne Probleme, wurde nur durch den OpenGop-Patch gekillt. (siehe openGop Thread im englischen Forum)

Zitat

aber wozu sollte man an einer Kapitelmarke IDR-Frames erzwingen?

Um möglichst schnell dahin springen zu können (anders als I- sind IDR-Frames wirklich ohne andere Frames decodierbar), die Möglichkeit zu haben z.B. die Frames an den Kapitelstarts direkt zu dekodieren (wenn man z.B. ein Menü erstellt) und ohne Reencoden an Kapitelmarken schneiden zu können.

Zitat

daß die vorhergehende GOP die neue referenziert, also nur in eine Richtung. Oder irre ich mich?

I-Frames referenzieren soweit ich mich entsinne immer nur in die Vergangenheit und nie in die Zukunft. (orientiere mich dabei an der 'decoding order')
(GOPs gehen immer von einem zu nächsten IDR-Frame)

Zitat

Neuer OpenGOP-Patch und Binary sind im englischen Doom9 verfügbar.

IDR Frames erzwingen über ein qpFile geht leider aktuell noch nicht. (wollte eigentlich eine Hybrid Version herausbringen die openGop unterstützt, werde dies aber erst mal sein lassen bis das qpfile Problem gefixed ist)

Cu Selur

Zitat von Selur

Ging an sich ohne Probleme, wurde nur durch den OpenGop-Patch gekillt. (siehe openGop Thread im englischen Forum)

Sehe da im Moment nur jpsdr, der sich in der aktuellen Version noch über Abstürze beschwert. Habe es mal mit dem aktuellen Build von kierank getestet und hatte keine Probleme. Welche Probleme gibt es denn noch damit?

Zitat

Um möglichst schnell dahin springen zu können (anders als I- sind IDR-Frames wirklich ohne andere Frames decodierbar), die Möglichkeit zu haben z.B. die Frames an den Kapitelstarts direkt zu dekodieren (wenn man z.B. ein Menü erstellt) und ohne Reencoden an Kapitelmarken schneiden zu können.

Ein I-Frame ist immer ohne andere Frames dekodierbar, das ist doch gerade die Definition eines I-Frames. Das gilt auch für Nicht-IDR-I-Frames. Deshalb ist es meiner Meinung nach auch bei Kapiteln nicht vonnöten, einen IDR-Frame zu setzen, sondern es reicht ein recovery-point-I-Frame.
Beim Schneiden (zum Beispiel eine Staffel einer Serie in einem Stück enkodieren und erst danach in einzelne Folgen schneiden) braucht man aber tatsächlich IDR-Frames, da stimme ich Dir zu.

Zitat

I-Frames referenzieren soweit ich mich entsinne immer nur in die Vergangenheit und nie in die Zukunft. (orientiere mich dabei an der 'decoding order')

s.o.: I-Frames referenzieren gar nichts.

Zitat

IDR Frames erzwingen über ein qpFile geht leider aktuell noch nicht. (wollte eigentlich eine Hybrid Version herausbringen die openGop unterstützt, werde dies aber erst mal sein lassen bis das qpfile Problem gefixed ist)

Hatte keine Probleme, als ich es kurz getestet habe. Was geht denn nicht? Dann würde ich erstmal den Patch nicht mehr nutzen.

/edit:
Anscheinend definieren wir beide "referenzieren" entgegengesetzt?

Irgendwas ist da gestern in meinem Kopf wohl schief gelaufen. (dran denken: mehr schlafen ;))
Über I-Frames kann bei H.264 hinweg referenziert werden, über IDR-Frames aber nicht und Du hast recht, dass I-Frames als Recovery-Point reichen und sie können auch als ohne selbständig referenziert werden. (Als Schnittpunkte sind aber nur IDR-Frames ohne Reencoden möglich.)

Hatte den letzten Patch kurz angetestet und I-Frames ließen sich erzwingen, IDR-Frames aber nicht. (oder ich hab was übersehen)

Cu Selur

Soweit ich weiß sind "I" weiterhin IDR-Frames und "K" recovery-point-I-Frames (vorausgesetzt "--open-gop" ist aktiviert). Zumindest schluckt der aktuelle Patch das ohne zu meckern, habe den Stream allerdings nicht daraufhin untersucht, ob es tatsächlich die richtigen Frametypen gesetzt hat.

Ich guck morgen vielleicht noch mal drauf.