sx264 public alpha

Zitat

Keyframe Interval
Der hier festzulegende Wert gibt an, nach wie vielen Frames spätestens ein IDR-Frame gesetzt werden soll bzw. wie groß eine GOP maximal sein darf. Einerseits ist es aus kompressions-technischen Gründen sinnvoll, diese nur an Szenenwechseln zu setzen, andererseits kann man nur von einem zum nächsten IDR-Frame springen und bei diesem schneiden, da man sonst nicht sicher wüsste, dass man keine Frames entfernt, auf die vielleicht später noch referenziert wird. Man will also nicht zu viele, da man sonst nur in groben Sprüngen im Film umherspulen bzw. -springen oder nur sehr 'ungenau' schneiden kann. Als guter Richtwert erscheint mir ein Wert, der etwa dem Zehnfachen der Framerate entspricht. Für PAL-Filme wäre dies ein Wert von 250. (NTSC = 240 bzw. 300) Meist erhält man aber eine etwas bessere Verteilung der IDR-Frames, wenn man etwa das zwanzigfache der Framerate nimmt.

Das mit dem min 25 und max 250 ist ein Wert der sich bei MPEG-4 ASP eingebürgert hat und auch immer recht gut funktioniert hat.
Das Minimum soll verhindern, dass zu kleine Key-Frame intervalle gewählt werden, was aber bei x264 nur seltenst passieren sollte un spätestens wenn der Open-GOP Patch funktioniert und integriert wird auch kein Problem mehr sein sollte.

Wenn man BluRay oder sonstige Kompatibilität haben will wird die maximale Größe meist recht genau durch die erlaubten Datenraten/Buffer und Optionen eingeschränkt.
(Persönlich wählte ich wenn ich etwas irgendwie Kompatibles erstellen will i.d.R. das Maximum ein, was sx264 (bei aktivierter Kompatibilität) erlaubt und als Minimum 1 oder 5 ein.)

Cu Selur

Davon ausgegangen, es soll später auf einem PC laufen und muss nicht auf SAPs laufen:
- gucken das auch eine aktuelle x264 Version verwendet wird (revision 1214+)
- kleinerer crf Wert
- cpmin würde ich auf 1 setzen
- partitions auf all (d.h. p4x4 auch immer erlauben)
- filter auf 0,0 lassen
- mehr Referenzen und B-Frames erlauben
- merange auf 32 setzen
- min-keyint auf 1
falls es BluRay kompatible bleiben soll:
- gucken das auch eine aktuelle x264 Version verwendet wird (revision 1214+)
- kleinerer crf Wert
- min-keyint auf 1
- qpmin auf 1
- merange auf 32 setzen

Generell kann es je nach Material auch interessant sein das ipratio zu ändern oder qcomp etwas zu senken. Man kann natürlich auch immer noch me auf tesa setzen wenn man wirklich viel Zeit hat und man den Unterschied noch sehen kann.

Dachte der -rc-lookahead wäre an mbtree gebunden,.. (gibt ja intern noch einige andere LookAheads die genutzt werde nur nicht nach außen zugänglich sind,..)
-> Haste mal einen Link wo steht oder zu folgern ist, dass der rc-lookahead auch Sinn macht wenn mbtree deaktiviert ist? (Wenn ich da was übersehen habe, fixe ich das natürlich. :))

Cu Selr

hört sich zumindest etwas so an,...

Zitat

Use the large-scale lookahead capability introduced in MB-tree for ratecontrol purposes.

(Does not require MB-tree, however.)

-> werde ich ändern.

rev552

*fixed*
- (linux) multiaudio source + using nero

*added*
- ability to set nero mode/profile (auto/lc/he/hev2)
- BD 25 and BD 50 as possible target sizes

*changed*
- mbtree and subme 10 now both trigger aqmode 2
- rc-lookahead configuration independent of mbtree

Remember to delete you sx264Config file

-> updated links in 1st post

Wenn Du qcomp senkst wird die Datenrate weniger Schwanken, was je nach Quelle und sonstigen Einstellungen gut oder schlecht sein kann. Muss aber gestehen, dass ich nie wirklich viel an qcomp drehe und auch sonst keine diesbezüglichen Tests auf dem Rader habe. (kleiner Wert: es wird eher versucht die Datenrate gleich zu halten; großer Wert: es wird eher versucht die Qualität gleich zu halten)
Das Positionieren der anderen Fenster ist vermutlich auch möglich, aber tricky, ich guck nächste Woche mal drauf.

Cu Selur

Werde mal drüber nachdenken, ist aber nicht so einfach, da die unterschiedlichen Formate/Quellen die Sprachen anders reinkodieren, falls sie es denn überhaupt tun.

Cu Selur

Ich guck nächste Woche drauf, nur DVD sollte nicht so wird sein, aber erst mal draufgucken.

Cu Selur

Pittiplatsch: Wird es in sx264 sicher nicht geben, bin aber, wie ich schon hier und da schon angemerkt habe, an einer 'neuen Version' am Arbeiten, bei der das Ganze etwas anders geregelt ist und die auch einiges flexibler für Erweiterungen sein wird.
-----
mister_no: Hab mir das mal angeguckt, weiß wie ich an sich eine solche Option integrieren könnte, was aber Nachteile mit sich bringt.
Da sx264 nicht das komplette File analysiert, sondern nur immer den aktuellen Video-/Audiostream müsste man um dies 'schnell' in sx264 zu integrieren wie folgt vorgehen:
1. DVD normal analysieren wie aktuell auch
2. für die Anzahl der Audiostreams gucken ob der aktuelle Stream die gewünschte Sprache hat, falls Ja ist alles gut, falls Nein würde der nächste Audiostream analysiert. Dies hat den Nachteil, dass die DVD Analyse einiges länger dauern würde und falls kein Stream mit der Sprache vorhanden ist alle Tonspuren durchcheckt ohne das es etwas bringt.
Wenn man dies ordentlich integrieren würde, müsste man die DVD und alles ihre Streams direkt am Anfang analysieren um dann schneller auswählen zu können. (das werde ich in sx264 aber nicht integrieren)
Ein weiterer Punkt ist, dass sx264 am sinnigsten die Option nach dem die Audiospur gefunden hat, oder einmal alle Tonspuren gecheckt hat, wieder deaktivieren würde und man sie manuell wieder aktivieren müsste. Dies wäre nötig, damit die Audiospur nicht 'permanent' erzwungen wird so lange die Option aktiviert ist.
-> falls es Dir sehr am Herzen liegt kann ich das Implementieren, würde generell aber eher dazu raten mit der Option auf den Nachfolger zu warten.

Cu Selur

Ps.: Nein, es gibt keinen Termin oder sonst irgendwas wann der Nachfolger von sx264 das Licht der Öffentlichkeit sieht. Da er Softwaretechnisch wesentlich durchdachter ist braucht es so seine Zeit.

Das Problem wenn man allein nach der Sprache geht, ist dass sx264 selber die erste Tonspur der Sprache wählen wird aus die es trifft, was durchaus auf ein Kommentar Tonspur sein könnte.
-> manuelles checken ist sicherer

Cu Selur

Ps.: Hab meinen Post oben noch editiert, als Du am Schreiben warst.