Alternative HQ Codec Konfiguration für die HQ Avis

[monarc99]

Einen schönen Tag an alle,


die HQ Avis werden ja bekanntlich mit x264 komprimiert. Ich habe mir in letzter Zeit einige HQs angesehen und die Qualität ist so auch ganz in Ordnung. Nur sehe ich bei allen HQs immer das gleiche Problem.

Bei Videokomprimierung besteht die Kunst darin, Informationen aus einem Bild zu entfernen, die für das menschliche Auge nicht, oder fast nicht, sichtbar sind und die übriggebliebenen Informationen um so besser darzustellen. Das gilt sowohl für jedes einzelne Bild oder auch über einen ganzen Film. So wird bei Szenen, die für das menschliche Auge zu schnell sind, gespart und diese an anderer Stelle wieder reinvestiert.

Momentan werden die HQ im Bitratenmodus mit einer festen Bitrate von 1100 und einem festem max. Quantizer von 26 komprimiert. Die Bitrate steuert wie groß die Avis werden sollen und der sehr niedrige max. Quantizer soll wohl verhindern, dass die Qualität des Films zu schlecht wird. (Quantizer sind die „Qualtitätsstufen“ mit denen ein Bild eines Video komprimiert wird, je höher desto schlechter schaut ein Bild aus)

Bei den momentanen Einstellungen ist es so, dass der Codec ständig versucht die vorgegebene Bitrate von 1100 einzuhalten. Dafür bräuchte er aber Quantizer die höher sind als 26. Er ist also ständig im „Sparmodus“. Man hört ihn praktisch ständig rufen „ich muss sparen, ich muss sparen“ … und produziert in den meisten HQ s fast nur Bilder mit Quant 26. Das Video wird also sehr gleichmäßig komprimiert. Von der oben beschriebenen Kunst der Videokomrimierung ist da leider nix mehr übrig.


Deshalb mein alternativer Vorschlag:

Probiert mal eine andere Konfiguration des x264, welche dem Codec mehr Freiheiten geben würde. Erstmal natürlich nur zu Testzwecken.

Ein mögliches Beispiel:

cfr Modus (Wert 22) und max. Quantizer 42
Wechsel vom Bitratenmodus in den crf (constant quality mode)-Modus. Auch ein 1pass, nur gibt man keine Bitrate vor, sondern seine Qualitätswünsche mittels einer Zahl. In diesem Modus berücksichtigt x264 mehr die Qualität des Film und „klebt“ nicht nur an der Bitrate. Brauchbare crf-Werte für otr dürften so zwischen 22-27 liegen. Würde mit 22 anfangen. Gleichzeitig den max. Quantizer höher auf 42 setzen, damit der Codec arbeiten kann. Die Avis sollten bei geeigneten Wert gar nicht mal so sehr in ihrer Größe von den normalen HQs abweichen.

Gibt noch andere Optionen von x264, die wohl nicht aktiviert sind und Qualität bringen würden:

8x8dct aktivieren (nicht aktiv)
partitions=all (nur minimal auswahl aktiv)
direct_pred=auto (steht auf temporal, was gerne in 2pass Verwendung findet, für 1pass besser spatial oder auto)
bime (gibt es in neueren x264 nicht mehr, ist bei subq=5(?) und höher nun automatisch an, vielleicht klappt dann das schneiden mit neueren ffdshow in VD wieder)
weight_b (bringt auch Quali)
b_pyramid (verbessert Quali gut, vielleicht Probleme beim Schneiden)
fast_pskip, nopsnr und nossim (verbessert zwar nicht die Quali, aber dafür die Geschwindigkeit)

Einige der Optionen brauchen allerdings ein High Profile. Aber Testen wird keinen wehtun.

Also ich würde mich über die Meinungen der otr Benutzer und Moderatoren freuen. Vielleicht ist otr ja gewillt, die eine oder andere HQ Avi zum Testzwecken zu erstellen.


Mit freundlichen Grüßen
Monarc

[r4z0r]

Hallo,

freut mich, dass du dich so ausgiebig mit diesem Thema beschäftigt hast, denn die HQ-Aufnahmen machen den Großteil meiner Decodings aus.
Auch mir liegt ein großer Wert an der Bildqualität und war auch schon von der letzten Qualitätssteigerung bei OTR erfreut.

Jedoch fällt mir bei den HQs die starke Verwischung von Details unangenehm auf.
Die von dir angeschriebenen Punkte mögen da sicher auch dazu beitragen.


Momentan werden die HQ im Bitratenmodus mit einer festen Bitrate von 1100 und einem festem max. Quantizer von 26 komprimiert.
Du hast dies sicherlich aus einem Analyse-Programm, wenn ich jedoch die Statistik bei VLC aufrufe zeigt er schon stark schwankende Bitraten an (aktuelles Beispiel: Deep_Blue_09.01.16_21-00_phoenix_85_TVOON_DE.mpg.HQ - welches sich mit seinen Bitratenfordernden Wasserszenen sehr gut zur Qualitätskontrolle eigent).

Zu den Codeceinstellungen kann ich mich mangels Fachwissen nicht äußern, jedoch würde ich gerne von dir wissen, ob du von einer Reduzierung der Auflösung (z.b. auf 640x480) etwas versprechen würdest?
Die PAL-Auflösung wird mangels Bitrate sowieso nicht ausgereizt.

Ich würde die Einstellungen aber auch gerne an Testaufnahmen erleben. Deswegen würde ich hier eine weitere Qualitätsinitiative seitens OTR begrüßen.

grüße r4z0r

[mchawk]

Divx7 ist im Grunde der alte divx Codec ohne nennenswerte Veränderung. Zusätzlich hat Divx den Mainconcept h.264 Codec einkauft und ihn jetzt als Divx7 auf dem Markt gebracht. Aber da gibts genug Vergleiche zw. x264 und dem Mainconzept. x264 ist eindeutig besser. Auch kann man mit divx7 im h.264 Modus nur Matroska Dateien erzeugen, dafür gibts aber keine guten Schneideprogramme, um z.B. die Werbung rauszuschneiden.

Das habe ich leider auch festgestellt.
Zumal man anscheinend h.264 bei DivX7 nur mit den DivX-Converter codieren kann.
Ich denke, es lohnt sich einen Blick darauf zu behalten, wie sich die h.264-Handhabung bei DivX entwickelt - denn die Möglichkeit zukünftig DivX7-h.264-Dateien auf BluRay-Playern abzuspielen ist schon ein verlockender Gedanke.

Leider sind zumindest aus meiner Sicht noch zu viele Variablen offen um jetzt schon konkrete Änderungen diesbezüglich an den HQ-Dateien durchzuführen - sofern diese überhaupt notwendig sind.

[RanTanPlan]

Freut mich sehr zu hören :D

Aber weil du gerade sagst, dass die HQ immer so lange brauchen, fällt mir was ein, über das ich mich gewundert habe. In den h264 Flags steht, dass threads auf 1 steht. Ich denke, dass bedeutet, dass bei einem MultiCore CPU nur 1 Core verwendet wird.

Kann sein, dass das so beabsichtig ist, also 1 Core pro Film. Oder die Angabe einfach falsch ist oder ich sie falsch verstehe. Aber wenn mehrere CPU Cores zur Verfügung stehen, würde ich auf alle Fälle mal auto ausprobieren und schauen, wie es sich auswirkt ;)

mfg,
Monarc99

Wenn ich mich recht entsinne, bedeutet threads=1 lediglich, dass NICHT nur ein core sondern mehrere benutzt werden. Alternativ gibt es nur threads=0, der besagt, dass eben nur einer benutzt werden soll. Kann aber sein, dass ich das mit einem anderen Programm verwechsle...

Gruß, RanTanPlan

[monarc99]

Wenn ich mich recht entsinne, bedeutet threads=1 lediglich, dass NICHT nur ein core sondern mehrere benutzt werden. Alternativ gibt es nur threads=0, der besagt, dass eben nur einer benutzt werden soll. Kann aber sein, dass ich das mit einem anderen Programm verwechsle...
Gruß, RanTanPlan

Also bei dem Rechner hier (Duo CPU) steht bei auto Einstellung als Flag threads=3 in der Datei. Das würde zu dem passen, was in den Foren steht. Nämlich dass x264 3 Threads verwendet, um die 2 Cores immer gut füttern zu können.

Sollte eh nur ein Hinweis sein, ich denke nicht, dass man das (überhaupt) einstellt.
Sollte es aber nicht passen, also mehr Cores vorhanden sein. Dann ist irgendwo noch ne alte Einstellung drin oder x264 ohne Thread Support kompiliert. Da könnte man deutlich Geschwindigkeit rausholen ;)

mfg,
Monarc

[RanTanPlan]

Also bei dem Rechner hier (Duo CPU) steht bei auto Einstellung als Flag threads=3 in der Datei. Das würde zu dem passen, was in den Foren steht. Nämlich dass x264 3 Threads verwendet, um die 2 Cores immer gut füttern zu können.

Sollte eh nur ein Hinweis sein, ich denke nicht, dass man das (überhaupt) einstellt.
Sollte es aber nicht passen, also mehr Cores vorhanden sein. Dann ist irgendwo noch ne alte Einstellung drin oder x264 ohne Thread Support kompiliert. Da könnte man deutlich Geschwindigkeit rausholen ;)

mfg,
Monarc

OK, dann hab' ich das wohl verwechselt. Weiß bloß nicht genau, womit! :confused:

Gruß RanTanPlan

[monarc99]

Das habe ich leider auch festgestellt.
denn die Möglichkeit zukünftig DivX7-h.264-Dateien auf BluRay-Playern abzuspielen ist schon ein verlockender Gedanke. Leider sind zumindest aus meiner Sicht noch zu viele Variablen offen um jetzt schon konkrete Änderungen diesbezüglich an den HQ-Dateien durchzuführen - sofern diese überhaupt notwendig sind.

Also zu BluRay findet man immer wieder:

AVC/H264 - MPEG-4 AVC: HP@4.1/4.0 and MP@4.1/4.0/3.2/3.1/3.0

Wobei HP wohl für High Profile und MP für Main Profile steht. Das legt fest, was der Decoder können muss, um es zu decodieren.

Und der Level 4.1 und 4.0. Das legt die maximale Bitrate fest. Der Prozessor des Geräts muss schnell genug sein, um die Datenmenge verarbeiten zu können.

Gibt ein paar Threads, die sich mit dem Thema beschäftigen.
z.B. hier http://forum.gleitz.info/showthread.php?t=37177
und http://forum.doom9.org/showthread.php?t=137569

Im Grunde muss x264 gepatchet werden, um die Bluray Header erzeugen zu können. Dann gibts einige kleine Einschränkungen, aber so im Allgemeinen kann man alles aktivieren, was x264 zu bieten hat. Also auch die deaktivierten Optionen, die ich im ersten Post angeführt habe.

mfg,
Monarc

[monarc99]

Interessant wären 2 Fälle. Angenommen du kodierst zweimal. Einmal die alten HQ Einstellungen und einmal CRF=22 mit den neuen Einstellungen

dann wäre ein Zeichentrick-Film interessant:

Die lassen sich sehr gut komprimieren, d.h. mit den alten Einstellungen wird der Film sehr gut aussehen. Wahrscheinlich so um die quant 18 im Durchschnitt. (je kleiner der Quant, desto besser, 18 ist so ziemlich das Beste)

CRF mit nominellen Wert 22 heißt jetzt, lass den Film so aussehen, als ob er durchgängig mit quant 22 gemacht worden wäre. Also wird der Zeichentrick mit dem CRF schlechter aussehen. Hier stellt sich die Frage, um wieviel wird er schlechter aussehen, als mit der alten Kodierung.
Von der Dateigröße wird der CRF wesentlich kleiner werden, aber das wird niemanden stören.

und ein anderer Film z.b. Fluch der Karibik

Hier ist es genau andersrum. (ich nehme jetzt mal Fluch der Karibik 1 als Vergleich) Mit der alten Kodierung wird der Quant so bei 26 liegen. Also wird der CRF mit 22 besser aussehen, aber dafür größer werden. Hier stellt sich jetzt die Frage, um wieviel größer?

Helfen werden CRF zwei Dinge. Erstens macht CRF die Dateien von sich aus kleiner. Zweitens muss CRF auf die anderen neuen Einstellungen hoffen. Diese verbessern die Kompression, dadurch wird die Datei kleiner. Die Frage ist nur, ob es reichen wird, oder ob die Dateien riesig wirden.

mfg,
Monarc

[sw2005]

was spricht denn dagegen, eine 5-Minuten-Sequenz aus einer der Aufnahmen herauszuschneiden, und diese Sequenz dann mit verschiedenen Optionen zu kodieren und zur Verfügung zu stellen?

[r4z0r]

was spricht denn dagegen, eine 5-Minuten-Sequenz aus einer der Aufnahmen herauszuschneiden, und diese Sequenz dann mit verschiedenen Optionen zu kodieren und zur Verfügung zu stellen?

stimme dir zu, als Test eignet sich wohl auch ein kleiner Ausschnitt. Der Vergleich würde so vereinfacht.

[OTR.TH]

Hallo,
stimme dir zu, als Test eignet sich wohl auch ein kleiner Ausschnitt. Der Vergleich würde so vereinfacht.
machen wir dann für die Feineinstellungen, aber erst mal prinzipiell testen, ob es was bringt bei welcher Veränderung der Dateigröße, und da ist bei 5 Minuten-Ausschnitten immer die Frage, was da grade läuft...
Würde also erstmal vorschlagen, Clone Wars und (Karibik2|Departed) als ersten Test, ob überhaupt jemand einen Qualitätsunterschied bemerkt und wie die Dateigrößen sich ändern. Eigentlich würde ich Karibik2 Departed vorziehen, ich schätze, da ist mehr Bitrate gefordert (Wasser ist immer recht komplex zu kodieren, und da kommt glaub ich einiges vor :D).

[monarc99]

Wasser in Fluch der Piraten .. glaube ich nicht ;)

Eine Frage: muss man was anderes programmieren, für die Testaufnahmen? Premium User wirds egal sein, aber sponsor nicht. Da SW-Clone Wars es nicht in die HQ Listen geschafft ist, ist die Testaufnahme für sie sicher interessant.

mfg,
Monarc

[qwert667]

Ich kann die neuen Formate mit meinem Hardware-Player (Popcornhour A100) nicht abspielen :(
Die normalen HQs muss ich immer in mkv umwandeln, dann gehts.

normales HQ als avi: Bild geht erst, aber Ton kommt abgehakt, irgendwann bleibt Wiedergabe stehen.
normales HQ als mkv: alles OK (ausser zurückspulen, aber damit kann ich leben).

plus als avi: Bild geht erst, aber kein Ton, irgendwann bleibt Bild stehen.
plus als mkv: Ton geht erst, aber Bild steht, irgendwann bleibt Ton stehen.

CRF als avi: wie plus ohne Umwandeln
CRF als mkv: wie plus mit Umwandeln, nur bleibt der Ton schon früher stehen

[OTR.TH]

Hallo,

ok, vielen Dank für den Test. Rest s.u. (gleich)


Ich kann die neuen Formate mit meinem Hardware-Player (Popcornhour A100) nicht abspielen :(

[TVjunker]

Hallo,

könntet Ihr im Dateinamen deutlich machen, dass es sich um einen Kodierungs-Test handelt? Ich dachte zuerst CRF steht für corrupt file oder so was.
Pirates_of_the_Caribbean_Fluch_der_Karibik_2__CRF_ 09.03.29_20-15_pro7_165_TVOON_DE.mpg.HQ.avi.otrkey

Auf jeden Fall schon mal Danke für die Weiterentwicklung der HQ-Formate!

[kuechenfee]

Hallo zusammen,

ich habe mir gerade die CFR-Variante von Departed (CRF_Departed_Unter_Feinden_09.03.30_22-15_zdf_140_TVOON_DE.mpg.HQ.avi) angeschaut und mein (rein subjektiver) Eindruck ist, dass das Bild im Vergleich zur normalen HQ-Variante DEUTLICH besser ist, trotz der verringerten Dateigröße.

Zwei Probleme hatte ich jedoch beim Abspielen auf meinem Mac:

1. Quicktime verzerrt das Bild, so das es deutlich höher als breit ist.
2. Mit VLC erscheint vor allem bei Bewegungen die Aufnahme etwas rucklig. Es macht den Eindruck, als würden für den Bruchteil einer Sekunde ältere, schon abgespielte Frames wieder auftauchen. Besser kann ich es leider nicht beschreiben.

mfg kuechenfee

[monarc99]

Hallo an alle :)



könntet Ihr im Dateinamen deutlich machen, dass es sich um einen Kodierungs-Test handelt? I
Wäre vielleicht sinnvoll :) Die Departed CRF ist sogar kleiner als die divx und wird standardmäßig ausgewählt :p Vielleicht die weiteren Tests mit CRF22, damit die Dateien groß sind und sich hinten einreihen. Ich würde erstmal alle anderen Optionen richtig einstellen. Den endgültigen CRF Wert würde ich dann ganz am Ende machen.

Hab die Testdateien noch nicht sehen können, langsames DSL ^^ Mein Kommentar kommt bestimmt später noch ;)



Zwei Probleme hatte ich jedoch beim Abspielen auf meinem Mac:
1. Quicktime verzerrt das Bild, so das es deutlich höher als breit ist.

Also die Testenfiles, die ich bisher gesehen habe, hatten alle ein falsches Seitenverhältnis. Also statt 4:3 ein 3:4 oder 16:9 ein 9:16. Da erkennt das Script vielleicht was falsches oder übergibt an den Codec falsche Werte. Ich stell dann immer manuell um.



2. Mit VLC erscheint vor allem bei Bewegungen die Aufnahme etwas rucklig. Es macht den Eindruck, als würden für den Bruchteil einer Sekunde ältere, schon abgespielte Frames wieder auftauchen. Besser kann ich es leider nicht beschreiben.

Wie alt ist dein VLC und wie schnell dein Mac?
Bei den Encodes ist bpyramid an, da kann es vorkommen, dass Bilder wegen der besseren Komprimierbarkeit ein wenig umsortiert werden. Der Player sollte das aber wieder richtig ordnen. Neueren VLC testen, wenn es einen gibt. Vielleicht hilft auch das umwandeln in mkv, avi ist bei sowas dem Player keine große Hilfe.

MfG,
Monarc

[kuechenfee]

Wie alt ist dein VLC und wie schnell dein Mac?


Ich habe einen CoreDuo mit 1,83 GHz und 2GB Ram. Prozessorlast ist bei etwa 40% (von 200%), das sollte also nicht das Problem sein. Ich benutze die aktuelle VLC-Version (0.9.8). Ähnliche Probleme hatte ich bisher mit anderen HQ-Files noch nicht.

In VLC wird das Seitenverhältnis aber korrekt dargestellt.

[monarc99]

Hi :-)


Ich habe einen CoreDuo mit 1,83 GHz und 2GB Ram. Prozessorlast ist bei etwa 40% (von 200%), das sollte also nicht das Problem sein. Ich benutze die aktuelle VLC-Version (0.9.8). Ähnliche Probleme hatte ich bisher mit anderen HQ-Files noch nicht.

In VLC wird das Seitenverhältnis aber korrekt dargestellt.

Also in der AVI steht folgendes:

Display aspect ratio 16:9 = 1.777777
Vprp aspect ratio 9:16 = 0.5625

Das letzte (vprp aspect ratio) wird wohl nur von MPlayer und Quicktime ausgelesen und verwendet. Der VLC nimmt den Display aspect ratio aus dem Stream, deshalb stimmts beim VLC :) Ich glaub, der vprp wird im AVI Header gespeichert, bin mir aber nicht sicher. Muss otr etwas ändern, dass das entweder richtig oder gar nicht geschrieben wird.

Zum Springen im Bild. Ja, das kann ich bestätigen. Schuld ist hier, dass der VLC zusammen mit dem AVI Container hier an seine Grenzen stösst. AVI wurde erfunden, als es nur konstante Bitraten gab. Aber einen variablen Videostream wie h264 und einen variablen MP3 Stream in AVI zu packen, ist nur noch reiner Hack. Wenn dann im h264 noch Bilder vertauscht werden, wirds hart für den Player.

MPlayer kann das noch abspielen. Ich habe mal den MP3 auf konstante Bitrate umgerechnet. VLC spielt dann die departed AVI problemlos ab, weil er sich an der konstanten Datenrate des MP3 orientieren kann. Auch wenn ich die AVI einfach in MKV umwandle (Dauer 43sek), spielt VLC es bei mir ohne Probleme.

h264 Streams sollten einfach in entsprechende Container. Unterstützt werden MP4 und MKV.
Ich hoffe, das hilft weiter?

mfg,
Monarc

[qwert667]

strange.. Fluch der Karibik (CRF) lässt sich nach Umpacken auf der Popcornhour abspielen..
Was war an dem jetzt anders?

Bei Departed hab ich das gleiche Problem wie mit den Star Wars-Teilen.

[Neuling]

Ergebnis: alle MKVs liefen problemlos. Sogar ein Profile, dass weit drüber war, lief ohne Probleme. Da war auch p4x4 aktiv. (also partitions=all)


Hi :-)Zum Springen im Bild. Ja, das kann ich bestätigen. Schuld ist hier, dass der VLC zusammen mit dem AVI Container hier an seine Grenzen stösst. AVI wurde erfunden, als es nur konstante Bitraten gab. Aber einen variablen Videostream wie h264 und einen variablen MP3 Stream in AVI zu packen, ist nur noch reiner Hack. Wenn dann im h264 noch Bilder vertauscht werden, wirds hart für den Player.

Hallo,ich als leihe frage mich ob jetzt vieleicht die Zeit für Aufnahmen in:
h264 in mkv mit mp2(oder AAC) in 16:9 ist?

[qwert667]

Hallo,ich als leihe frage mich ob jetzt vieleicht die Zeit für Aufnahmen in:
h264 in mkv mit mp2(oder AAC) in 16:9 ist?
Ich persönlich fänd das auch besser, weil ich die Werbung immer überspringe, aber Leute, die die rausschneiden wollen haben dann meines Wissens nach ein Problem, weil die gängigen Schneid-Programme kein mkv können. (Korrigiert mich, wenn ich falsch liege!)

[Artemis1121]

Ich persönlich fänd das auch besser, weil ich die Werbung immer überspringe, aber Leute, die die rausschneiden wollen haben dann meines Wissens nach ein Problem, weil die gängigen Schneid-Programme kein mkv können. (Korrigiert mich, wenn ich falsch liege!)

ich war und bin auch fan von mkv.. allerdings sind die dinger zum schneiden unbrauchbar und somit bei otr nutzlos.. das schnittergebnis kann man ja dann schnell nach mkv umpacken, wenn mans möchte :)

wieder auf direct-stream-mp2 wechseln wäre schön! das ist problemlos, qualitativ perfekt und kostet weder rechenzeit(spart sogar welche) noch führt es zu größeren dateien!

[Artemis1121]

hmm.. ich dachte das zumindest bisher immer, hab aber gerade mal einen test gemacht..
folgende gibt der mplayer aus.. videoinspector sagt dazu 112kbit.. gspot 192kbit..

kannst du mir nen tool empfehlen, das die informationen vernünftig anzeigt?


rtl2:
================================================== ========================
Opening audio decoder: [mp3lib] MPEG layer-2, layer-3
AUDIO: 48000 Hz, 2 ch, s16le, 192.0 kbit/12.50% (ratio: 24000->192000)
Selected audio codec: [mp3] afm: mp3lib (mp3lib MPEG layer-2, layer-3)
================================================== ========================

ard:
================================================== ========================
Opening audio decoder: [mp3lib] MPEG layer-2, layer-3
AUDIO: 48000 Hz, 2 ch, s16le, 256.0 kbit/16.67% (ratio: 32000->192000)
Selected audio codec: [mp3] afm: mp3lib (mp3lib MPEG layer-2, layer-3)
================================================== ========================

hr:
================================================== ========================
Opening audio decoder: [mp3lib] MPEG layer-2, layer-3
AUDIO: 48000 Hz, 2 ch, s16le, 192.0 kbit/12.50% (ratio: 24000->192000)
Selected audio codec: [mp3] afm: mp3lib (mp3lib MPEG layer-2, layer-3)
================================================== ========================

kika:
================================================== ========================
Opening audio decoder: [mp3lib] MPEG layer-2, layer-3
AUDIO: 48000 Hz, 2 ch, s16le, 256.0 kbit/16.67% (ratio: 32000->192000)
Selected audio codec: [mp3] afm: mp3lib (mp3lib MPEG layer-2, layer-3)
================================================== ========================

[monarc99]

kannst du mir nen tool empfehlen, das die informationen vernünftig anzeigt?


nicht wirklich, aber probier mal mediainfo oder avinaptic. Vielleicht können die es besser.

Mfg,
Monarc

[Artemis1121]

rtl2:
[ Generic infos ]
File type: MPEG-1 Layer II
MPEG frames: 40862
Play duration: 00:16:21 (980.688 s)
Bitrate: 192 kbps CBR
Sample rate: 48000 Hz
Emphasis: none
Mode: stereo
Padding: No


ard:
[ Generic infos ]
File type: MPEG-1 Layer II
MPEG frames: 2177
Play duration: 00:00:52 (52.248 s)
Bitrate: 256 kbps CBR
Sample rate: 48000 Hz
Emphasis: none
Mode: stereo
Padding: No


hr:
[ Generic infos ]
File type: MPEG-1 Layer II
MPEG frames: 658037
Play duration: 04:23:13 (15792.888 s)
Bitrate: 192 kbps CBR
Sample rate: 48000 Hz
Emphasis: none
Mode: stereo
Padding: No


kika:
[ Generic infos ]
File type: MPEG-1 Layer II
MPEG frames: 1199937
Play duration: 07:59:58 (28798.488 s)
Bitrate: 256 kbps CBR
Sample rate: 48000 Hz
Emphasis: none
Mode: stereo
Padding: No


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~
8 hq aufnahmen pro tag
ich nehm mal im schnitt 90min inkl overlap an(gibt ja auch viele serien hqs)

das wären 720min(43200sekunden) hq pro tag

unabhängig vom codec wäre dann der platzbedarf bei verschiedenen bitraten für den audioanteil aller hqsinsgesamt:
64kbit: 337,50 MB
96kbit: 506,25 MB
128kbit: 675,00 MB
192kbit: 1012,50 MB (wird zur zeit genutzt (MP3))
256kbit: 1350,00 MB
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~

ist es sinnvoll diese baustelle zu vertiefen bevor die videocodecconfig fertig ist?

[qwert667]

CRF23-Clone Wars lässt sich auf der Popcornhour abspielen :)

...nach Umpacken in mkv.

[OTR.TH]

Hallo,
otr wird ja vermutlich die HQs nicht mit x264vfw erzeugen können.
da das w am Ende für Windows steht, eher ungern ;)

Mal eine grundsätzliche Frage, wie ist den der Qualitätsunterschied bei vergleichbarer Dateigröße? (ok, Clone Wars war mit 30% mehr Bytes besser, aber das war ja zu erwarten.)
z.B.
Star_Wars_The_Clone_Wars_09.04.05_17-30_pro7_30_TVOON_DE.mpg.HQ.avi.otrkey
478632010 Byte
CRF23_Star_Wars_The_Clone_Wars_09.04.05_17-30_pro7_30_TVOON_DE.mpg.HQ.avi.otrkey
444232314 Byte

[aeiou2@gmx.at]

Hallo, ich bin mit diesen Codec-Geschichten nicht so vertraut.
Aber was ich festgestellt habe, mein TV spielt die CRF-Dateien nicht ab (Departed) und ich habe mir grade einen neuen TV gekauft, bei dem ich ganz begeistert war, das endlich mal alles abgespielt werden kann.
Ich denke ich spreche für viele wenn ich sage: zu viele Varianten schaden nur als das sie nützen.

Vielleicht liege ich ja auch falsch, aber wer hat schon lust lange im Internet nach Lösungen zu suchen, wenn man doch nur einen Film sehen will.....

(Wollte ich nur mal gesagt haben.)

[monarc99]

Aber was ich festgestellt habe, mein TV spielt die CRF-Dateien nicht ab (Departed) und ich habe mir grade einen neuen TV gekauft, bei dem ich ganz begeistert war, das endlich mal alles abgespielt werden kann.


Ein TV, der h264 abspielen kann? Was für einen Fernseher hast du denn da?

mfg
Monarc

[monarc99]

Wir haben jetzt nur kurz getestet, scheint wohl beim Samsung genauso wie bei der Popcorn Hour zu sein. Dateien von mir laufen alle ohne Probleme. (mit einer aktuellen x264.exe erzeugt)

[Spirou00]

Hi,

hab mit meiner Icy Box MP309 genau das gleiche Problem wie die Popcorn Hour. Die meisten HQ Files laufen von Beginn an nicht synchron in Bezug auf Bild und Ton.

Geht mir grad schon ein wenig auf den Zeiger, wollt ich doch endlich mal ne gescheite Lösung zum Anschauen der OTR-Files auf dem TV haben. Und nachdem die HD-Player mit wohl (fast!) jedem Material zurecht kommen hab ich zugegriffen, in der Hoffnung, nun alles mit super Bild und ohne Brummschleife anschauen zu können. Aber naja, irgendwie scheint das nicht zu klappen...
http://www.otrforum.com/images/smilies/sad.png


Aber um's kurz zu machen:
Weiß jemand ne vernünftige Lösung, wie ich die existierenden HQ Files (ich hab ne Menge davon!) mit nem vertretbaren Aufwand auf der Plattform zum Laufen bringe?

Ich nutze avidemux auf Linux und das multicut-light Script zum Schneiden.
Im Idealfall kann man das kombinieren, damit man die Files nicht 10 Mal anfassen muss.

Gruß Spirou

[monarc99]

Hi,
hab mit meiner Icy Box MP309 genau das gleiche Problem wie die Popcorn Hour. Die meisten HQ Files laufen von Beginn an nicht synchron in Bezug auf Bild und Ton.

Was passiert, wenn du die Datei einfach mal in MKV umwandelst und dann abspielst?

mfg,
Monarc

[Spirou00]

Hi Qwert, Monarc

danke für den Tip, werde es mal ausprobieren.

Hatte es schonmal mit Avidemux in ein MKV umgewandelt, das wollte die Box aber nicht abspielen. Viel Zeit hatte ich aber noch nicht, muss das nächste Woche dann mal testen.


thnx

[monarc99]

Also die Popcornhour und Icy Box haben wohl den gleichen Chip: Sigma Designs SMP8635. Also dürfte es bei ihnen sehr ähnlich sein.

Die WD TV hat einen Sigma SMP8635LF. Also fast überall ähnliche Chips verbaut.

mfg,
Monarc

[Spirou00]

Hi,

so, kurzes Feedback.
Auf der ICY Box läuft's nach der Verwendung von MKVMerge einwandfrei. Muss ich halt meinen PC mal ein wenig stressen für die Umwandlung... :p

Ideal wäre noch, wenn das beim Anwenden der Custlisten gleich in MKV gepackt würde. Multicut_light.sh hat zwar nen Schalter dafür, der hat aber bei mir nichts bewirkt. Muss ich mal noch weitersuchen (http://www.otrforum.com/showthread.php?t=38342&page=1).


Thxn
Spirou

[Tobi1711]

Tut sich hier noch was? :confused:

[OTR.TH]

Hallo,

ja... falls ich irgendwann mal Zeit dazu finden würde :( könnte man noch ein/zwei Tests machen.
(evtl. kann mir ja jemand eine Kurzzusammenfassung geben, was jetzt klappt und was nicht :D)
Evtl. hätte ich auch noch 2 Kodiereinheiten mit neueren x264-Versionen, aber die anderen wollte ich eigentlich nicht updaten deswegen, gab bei denen zwei schon genug Streß (falls sich jemand an die Aufnahmen ohne Ton gegen Ende erinnert)...

[monarc99]

hm, ne Kurzzusammenfassung und das bei meinem Gedächtnis :cool:

also soweit ich mich erinnere:

Die crf liefen nicht auf der popcorn hour. Wenn ich den Stream mit einer neueren Version kodiert hatte, schon. Das wollte man noch testen.

Das andere war das Schneiden. ffdshow kennt crf nicht (und wird es auch nie lernen, weil es bei ffdshow keinen Entwickler mehr gibt, der für den x264 Part zuständig ist) Geschnittene crf liefen in AVI und MKV. Aber die Umwandelten in MP4 waren problematisch. Avidemux 2.6 wird vielleicht solche Dateien framegenau schneiden können, dass wird aber nicht unter einem Jahr oder länger erscheinen.


Dazu noch: ich habe jetzt ne WD TV da, kann also alles selbst daran testen. Wenn du noch ein paar Tests machen willst, schaue ich, ob ich sie auf der WD TV zu laufen bekomme. Wenns mit crf nicht klappt, kann man immer noch schauen, ob man ein paar der anderen Einstellungen übernimmt.

mfg
Monarc

[monarc99]

Wie schaut es denn aus? Irgendwas in Planung in nächster Zeit?

Einige der h264 Filme sind ja ok, aber dann gibts wieder böse Ausrutscher, wo ich mir denke, ob ich ausversehen die divx Version geladen habe. ;)
Würde mich also freuen, wenn noch was passiert. :D

mfg,
Monarc

[monarc99]

hehe ... Biiittttrrraaatttteeee :p

Also mehr Bitrate ist natürlich immer gut ;) Aber die neuen Einstellungen (ohne crf) bringen auch etwas. Vielleicht so vergleichbar mit 5-10% mehr Bitrate. :cool:

Mach aber trotzdem eine crf Version mit allen neuen Einstellungen, damit man eine Datei hat, mit der man Testen kann. Vielleicht finde ich noch einen Weg.


mfg,
Monarc

[monarc99]

Nachtrag:

Mit der core 68 hat x264 nun ein Preset System bekommen. Das soll es einfacher machen geeignete Einstellungen zu finden. Also anstatt sich mit etlichen Parameter Einstellungen rumzuschlagen, gibts jetzt die --profile, --preset und --tune Parameter.



--profile Force H.264 profile [high]
Overrides all settings
- baseline,main,high
--preset Use a preset to select encoding settings [medium]
Overridden by user settings
- ultrafast,veryfast,fast,medium,slow,slower
--tune Tune the settings for a particular type of source
Overridden by user settings
- film,animation,grain,psnr,ssim


Ein Aufruf schaut dann z.B. so aus:

x264 --profile high --preset medium --tune film ...
Und man bekommt einen crf 23 Encode mit passenden Einstellungen, über die man sich nicht beschweren kann. Hinter der Presets verstecken sich dann die genauen Einstellungen, die die Entwickler vorgeben.

z.B. hinter --tune film versteckt sich z.B.: deblock -1:-1, psy-rd 1:0.15


Bisher ist es für otr noch nicht sehr interessant, aber interessant ist, welche Einstellungen die Entwickler für ihre Presets gewählt haben. Das Preset medium / tune film wäre z.B. eine gute Einstellung für otr. Die einzelnen Einstellungen kann man ja ohne Probleme auch bei nicht ganz so neuen Cores verwenden. Hab zuletzt eine 66 core bei otr laufen sehen.

Hinter x264 --profile high --preset medium --tune film ... versteckt sich:


x264 --profile high --crf 23 --level 4.1 --ref 3 --keyint 250 --min-keyint 25
--scenecut 40 --bframes 3 --b-bias 0 --direct auto --cplxblur 20 --qcomp 0.6
--qblur 0.5 --qpmin 10 --qpmax 51 --qpstep 4 --ipratio 1.4 --pbratio 1.3
--chroma-qp-offset 0 --partitions i4x4,i8x8,p8x8,b8x8 --me hex --merange 16
--subme 7 --trellis 1 --psy-rd 1:0.2 --aq-mode 1 --aq-strength 1 --threads auto
--filter -1,-1


oder bei Mediainfo Anzeige auch so:



Encoding settings: cabac=1 / ref=3 / deblock=1:-1:-1 / analyse=0x3:0x133 /
me=hex / subme=7 / psy_rd=1.0:0.2 / mixed_ref=1 / me_range=16 / chroma_me=1 /
trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / chroma_qp_offset=-3 /
threads=3 / nr=0 / decimate=1 / mbaff=0 / bframes=3 / b_pyramid=0 / b_adapt=1 /
b_bias=0 / direct=3 / wpredb=1 / keyint=250 / keyint_min=25 / scenecut=40 /
rc=crf / crf=23.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 /
ip_ratio=1.40 / pb_ratio=1.30 / aq=1:1.00


Im Unterschied zu den bisherigen otr Einstellungen wird an ein paar Einstellungen gedreht. Der Hauptunterschied dürfte sein, dass subme von 5->7 steigt. Das aktiviert psychovisual optimization. Im Gegenzug verwenden sie eine einfachere Suche (von umh -> hex) Sollte noch ein crf Encode zum Test anstehen, kann man die Einstellungen dort mal testen. Hab hier ein paar Tests gemacht und man kann sich nicht beschweren. Ein Vorteil ist natürlich, dass diese von den Entwicklern empfohlen werden, sollte also die Quali nicht stimmen, sind sie schuld :p

Aber hier gilt auch. Die Einstellungen wirken als Ganzes. Wenn dann es testen will, muss man jeden einzelnen Wert übernehmen ;)

mfg,
Monarc

[OTR.TH]

Hallo,
Hab zuletzt eine 66 core bei otr laufen sehen.
ja, momentan aber nur auf einer Einheit.

PS: Hab´s nicht vergessen, komme aber momentan nicht dazu, mal ein Testfile zu machen... :( :o

[monarc99]

PS: Hab´s nicht vergessen, komme aber momentan nicht dazu, mal ein Testfile zu machen... :( :o
Nur keine Hetze ;)

Eines Tages wird es soweit sein ^^ Und vielleicht berichte ich noch meinen Enkeln noch davon ;)

[OTR.TH]

Hallo,

ich versuch heute (bzw. morgen nachmittag) mal ein Testfile zu machen, ca. diese Einstellungen?

Hinter x264 --profile high --preset medium --tune film ...

Navy_CIS_09.08.06_23-40_sat1_55_TVOON_DE

[monarc99]

:D prima ... dann bin ich mal gespannt :cool:

[monarc99]

ok, habs mir mal angesehen. Leider keine große Veränderung.

Mit Virtualdub schneiden und als AVI kein Problem. Auch wenn man in MKV umwandelt, ist noch alles ok. Spielt sowohl auf dem PC als auch auf meiner WDTV.

Anders in MP4. Nach dem Umwandeln mit FixOTR ist bei den ersten Schnitt Schluss. Bild bricht ab. Man kann auch in Avidemux in MP4 umwandeln, die MP4 spielt dann bei den meisten Playern problemlos. Also ich denke bei 99% würde es dann laufen, aber vermutlich gibt es dann trotzdem den einen oder anderen Player, der Probleme macht. Hab Quicktime z.b. nicht ausprobieren können, aber ich fürchte, der hat da so seine Probleme. (viele Mac User)

Ich würde dann vorerst doch beim Bitratenmodus bleiben, bis sich eine andere Möglichkeit ergibt, wie man die Filme schneiden könnte.

[Freddy K.]

ok, habs mir mal angesehen. Leider keine große Veränderung.

Jup, so gut wie gar keine, dafür ist die Datei größer. :)


Anders in MP4. Nach dem Umwandeln mit FixOTR ist bei den ersten Schnitt Schluss. Bild bricht ab. Man kann auch in Avidemux in MP4 umwandeln, die MP4 spielt dann bei den meisten Playern problemlos. Also ich denke bei 99% würde es dann laufen, aber vermutlich gibt es dann trotzdem den einen oder anderen Player, der Probleme macht. Hab Quicktime z.b. nicht ausprobieren können, aber ich fürchte, der hat da so seine Probleme. (viele Mac User)

Was wird denn bei FixOTR umgewandelt? Wenn das H.264-Video nur durchgereicht wird, ist klar dass das Probleme macht.
Ansonsten hab ich hier am Mac aber keine Probleme mit dem Video.


Ich würde dann vorerst doch beim Bitratenmodus bleiben, bis sich eine andere Möglichkeit ergibt, wie man die Filme schneiden könnte.

Wenn die MP4-Standards eingehalten würden sollte es keine Probleme mit dem schneiden geben. ;)

[monarc99]

Jup, so gut wie gar keine, dafür ist die Datei größer. :)
Du meinst die Qualität der Dateien? ;) Ich meinte nur das Schneiden :cool:
Die Qualität hab ich mir gar nicht so genau angesehen, weil von 20 Einstellungen vielleicht 11 nicht so sind, wie ich es vorgeschlagen hatte. Deshalb hab ich nur das Schneiden betrachtet. ;)




Was wird denn bei FixOTR umgewandelt? Wenn das H.264-Video nur durchgereicht wird, ist klar dass das Probleme macht.
Ansonsten hab ich hier am Mac aber keine Probleme mit dem Video.

Wenn die MP4-Standards eingehalten würden sollte es keine Probleme mit dem schneiden geben. ;)
Ja, FixOtr reicht den h264 des geschnittene AVI nach MP4 durch. Wandelt nur den Sound in AAC.
Wie schneidet man eigentlich die Filme auf Mac?

mfg,
Monarc

[Freddy K.]

Ja, da hab ich deinen Satz wohl falsch interpretiert. Ich dachte du hattest damit die Qualität im Auge und diese auch gemeint. ;)


Wie schneidet man eigentlich die Filme auf Mac?

Ich benutze dazu das Programm SuperOTR, dieses wiederum nutzt QuickTime. SuperOTR holt sich die Schnittliste von Cutlist.at und die geschnitten Dateien werden dann als MOV gesichert. Das ganze dauert, je nach Rechenleistung, zwei bis vier Minuten.
Irgendwie habe ich aber das Gefühl, dass das deine Frage nicht wirklich beantwortet. ;)
Im Prinzip ist es wie mit dem CutAssistant, nur das Smart-Rendering, die Suche von Frames und dergleichen nicht notwendig ist.

[monarc99]

Irgendwie habe ich aber das Gefühl, dass das deine Frage nicht wirklich beantwortet. ;)


Aber vielen Dank für den Hinweis :)
Ich hab selbst noch ein wenig nachgeforscht, hilft leider an dieser Stelle nicht weiter, weil Software benutzt wird, die es nur für Mac gibt.

Wie gesagt, vorerst (leider) beim Bitratenmodus bleiben. Aber zumindest die anderen Einstellungen würde ich auf vernünftige Werte stellen. Das bringt zwar keine Wunder, aber dann ist zumindest der Rest eingestellt. 10% der Bitrate waren ja auch schon versprochen ;)

Ausgehend von der momentanen otr Einstellungen wäre das:


8x8dct=1 aktivieren
Partitionen von i4x4,p8x8,b8x8 -> i4x4,i8x8,p8x8,b8x8
me=umh Suche auf me=hex runter
subme=5 dafür auf subme=7 hoch
dadurch wird psychovisual optimization aktiviert. Auf psy_rd=1.0:0.2 einstellen
Direct MV prediction mode von temporal(direct=2, schlechteste Einstellungen überhaupt ;)) auf auto(direct=3) stellen.
weighted prediction aktivieren (wpredb=0 -> wpredb=1)
qcomp auf einen guten Wert stellen (qcomp=0.80 -> qcomp=0.60)


schönen Tag noch :)

[OTR.TH]

Hallo,
8x8dct=1 aktivieren
Partitionen von i4x4,p8x8,b8x8 -> i4x4,i8x8,p8x8,b8x8gab´s da nicht Geräte, die mit High Profile (=8x8dct, i8x8) nicht zurechtkommen?

me=umh Suche auf me=hex runter
subme=5 dafür auf subme=7 hoch
dadurch wird psychovisual optimization aktiviert. Auf psy_rd=1.0:0.2 einstellen
subme 7 braucht aber einiges mehr an CPU-Leistung, oder? Deswegen von umh auf hex bei me runter? psy_rd kann ich hier wohl (noch) nicht einstellen...

Direct MV prediction mode von temporal(direct=2, schlechteste Einstellungen überhaupt ;)) auf auto(direct=3) stellen.
weighted prediction aktivieren (wpredb=0 -> wpredb=1)
qcomp auf einen guten Wert stellen (qcomp=0.80 -> qcomp=0.60)

ok. (dachte direct=0 wäre noch schlechter? ;))

na da ist wohl noch ein Testfile fällig (muß ja auch die Zeit zum Kodieren abschätzen können). Ich meld mich dann, wenn ich was geeignetes gefunden hab (oder wenn´s zulange dauert, nehm ich irgendwas :cool:)

[monarc99]

Schönen Nachmittag,


Hallo,gab´s da nicht Geräte, die mit High Profile (=8x8dct, i8x8) nicht zurechtkommen?


Tja, das ist die Frage. ;) Bislang ist mir noch keins untergekommen. Wenn hier im Forum Hardware Player gepostet wurden, habe ich auch immer nachgesehen, was sie können. Und im Grunde war das immer gleich. High Profile bei Level 4.0 bzw. 4.1

Selbst die uralten xbox360 und ps3 können das. Das liegt vermutlich daran, dass das High Profile die Grundlage von Blueray und HD-DVD ist und dass Main Profile deshalb so in Vergessenheit geraten ist.




subme 7 braucht aber einiges mehr an CPU-Leistung, oder? Deswegen von umh auf hex bei me runter? psy_rd kann ich hier wohl (noch) nicht einstellen...


Irgendwann musst du mir mal verraten, was für eine Software ihr da verwendet. Ist die selbst gestrickt? ;) Das Einstellen der Variablen ist wohl irgendwie sehr schwer, kann mich kaum an ein Testfile erinnern, wo alle Werte gestimmt haben :p

Ja, subme wird mehr CPU verbraten, deshalb me runter. Das Default Wert von psy_rd wäre 1.0:0.0, der ginge auch. Empfohlen ist 1.0:0.15. Wir werden ja sehen, welcher Default Wert eingetragen ist, auch wenn ich das schlimmste befürchte :cool:



ok. (dachte direct=0 wäre noch schlechter? ;))


:D ja, hast recht ... aber wenn du auf auto stellst und der encoder selbst den besten Wert für jedes Bild bestimmen lässt, hat direct=1(spatial) so 99.9% und direct=2(temporal) so 0.1%. Weit liegt direct=0 und 2 also nicht auseinander ;)



na da ist wohl noch ein Testfile fällig (muß ja auch die Zeit zum Kodieren abschätzen können). Ich meld mich dann, wenn ich was geeignetes gefunden hab (oder wenn´s zulange dauert, nehm ich irgendwas :cool:)

Nimm das kürzeste, was du finden kannst. Geht erstmal nur darum, ob man das bei eurer Software auch alles anständig einstellen kann. Was nützt ein 2 h Film, wenn die Hälfte der Variablen wieder falsch ist und man über die Quali wieder nichts sagen kann. ;)

mfg
Monarc

[OTR.TH]

Hallo,

ich nehm heute mal alarm_fuer_cobra_11_die_autobahnpolizei_09.08.20_2 0-15_rtl_60_TVOON_DE (Platz 11 der HQ-Liste...)
Hab´s zwar nie gesehen, aber da allzuviel ruhige Szenen dürfte es da nicht geben, also sollte man evtl. Unterschiede in der Qualität auch sehen können...? Alternativ geht auch irgendwas anderes (nicht zu langes) aus der HQ-Liste heute...

[monarc99]

Ich denke cobra 11 ist gut geeignet. Habe es auch noch nie gesehen ;)

[monarc99]

So habe jetzt endlich Zeit gefunden, mir die Dateien anzusehen. :)
Danke nochmal fürs Bereitstellen. :D

Also der Gewinn ist meiner Meinung sehr gering. Man sieht zwar wie py-rd arbeitet, die Gesichter sind heller usw... aber einen Gewinn kann ich jetzt nicht groß sehen. Allerdings sind beide Dateien für otr Verhältnisse ganz gut, auch wenn sie wieder sehr unscharf sind.

Eine Frage, sind die originale Quellen auch derat unscharf, oder kommt das erst durch das Umrechnen?

Ich schaue mir morgen mal das Schneiden an, muss auch erstmal wieder die ffdshow Einstellungen zusammensuchen :rolleyes:

mfg,
Monarc

[DerTim]

Schneiden funktioniert mit den üblichen Einstellungen problemlos.

Qualität kann ich noch nicht beurteilen...

[monarc99]

Also Schneiden scheint zu klappen ... das ist die gute Nachricht ;)

Ich habe noch ein wenig mit py-rd getestet. Auswirkungen hat es je nach Quelle unterschiedlich. Von keiner bis zu einen leicht schärferen Bild. Ich denke, wenn es für otr nicht zu langsam ist, würde ich es anlassen.

Generell würde ich aber sagen, solange crf nicht geht, würde ich erstmal alles so lassen. Schneiden geht zwar, wer aber mit Fixotr arbeitet, muss mit anderen Einstellungen schneiden, damit es klappt. Wäre nach dem Decoder wieder Ärger für einige Leute. Momentan eher ungünstig.

Tut mir jetzt leid, dass ich soviel Arbeit gemacht habe und doch nichts rausgekommen ist ...

Diesen Sommer kommt Macroblock Tree Ratecontrol und Weighted P-frame Prediction neu in x264. Das Erste funtioniert wirklich gut, muss ich sagen. Bin überrascht, wie klein die Dateien jetzt werden :p
Ich denke, wenn man alles zusammen nimmt, also crf und die Einstellungsempfehlungen der Entwickler, würde es sich schon lohnen umzustellen. Muss man nur abwarten, wie sich das mit dem Schneiden entwickelt. Und ob otr irgendwann nochmal Lust hat es auszuprobieren ;)

mfg,
Monarc