Hybrid (Windows/Linux/Mac): Input -> x264/x265/Xvid/VP8/VP9

  • warum denn warten? mir reicht es, wenn die einmal geschrieben sind. danach müssen sie doch nie mehr geändert werden.

    Dass sich niemand drüber freuen würde, dass man ca. 30 % weniger Bitrate für dieselbe Qualität benötigt, wage ich ernsthaft zu bezweifeln.

    Es weiß nur aller Wahrscheinlichkeit kaum jemand von der möglichen Einsparung an Bitrate, da die 16-bit Präzision zu keiner Zeitpunkt in irgendwelchen mir bekannten kostenlosen und kommerziellen Programmen angeboten wurde und seit inzwischen 7 Jahren überhaupt nicht mehr unterstützt wird.


    Wie gesagt: für den einmaligen Zeitaufwand, den Code aus der vorhin genannten 2015er Version unter einem anderen Namen in die neue Hybrid Version zu implementieren, zahle ich sehr gerne. daran soll es nicht scheitern.

  • Hi Selur,


    ich wäre auch sehr stark daran interessiert das du das doch bitte mal integrierst, ich würde da auch einen kleinen Obolus dazu geben, es gibt halt einfach keine Programme die alles in einem so gut können wie deins, no way.


    Man könnte noch mit FFMPEG rumspielen, aber das ist viiiieeel zu umständlich und teilweise unübersichtlich für Windows User.


    Am besten ein Drop down Menu mit dem alten x265 mit 16 Bit Präzision zum auswählen, in dem dann die alte registerkarte aus dem 2015er Hybrid angezeigt wird anstatt dem des neuen x265 zbs.


    Das wäre schon toll.


    Grüße

    Karthauzi

  • irrelevant. Auch dieses tool nutzt meines Wissens nach die aktuelle x265 version und bietet damit keine 16 bit Präzision.

    Es gibt also aktuell leider keine Alternative zu Hybrid Version 2015.04.25.1, wenn man mit maximaler Effizienz komprimieren möchte.


    Nochmal zu meiner Frage:

    Ist es mit moderatem Aufwand möglich, den Code aus der Hybrid Version 2015.04.25.1 unter einem anderen Namen in die neue Hybrid Version zu implementieren? Eine Wartung dieses Codes ist meines Verständnisses nach nicht notwendig. Ich bin seit 7 Jahren extrem zufrieden und daran wird sich bis X266 auch nichts mehr ändern.


    Den dafür nötigen Arbeitsaufwand zahle ich sehr gerne in Form eine Paypal Spende oder auf andere von dir bevorzugte Weise.

    Sicherlich werden sich auch einige weitere Nutzer über die Option, den alten Encoder mit 16 bit Präzision verwenden zu können, freuen, sollten sie auf irgendeine Weise den damit verbunden Vorteil erfahren.


    Was meinst du?

    Welche Bedenken gibt es und von wieviel Arbeitsaufwand reden wir hier?

  • vielen Dank fürs Nachsehen. Eine volle Woche Arbeit klingt ja schon heftig. Damit verstehe ich jetzt deine Zurückhaltung :)

    Ich verstehe nur nicht ganz, warum da etwas angepasst werden muss.

    Verzeih bitte die naive Frage, aber ich hatte mir das so vorgestellt, dass einfach in Hybrid eine kleine Codeerweiterung zum Laden der x265-16bit.exe von damals eingefügt wird und das Ding dann einfach genauso aussieht und funktioniert wie in der alten Hybrid Version.

    Klappt das so nicht, weil sich die Fenster/Oberflächen in Hybrid verändert haben oder warum musst du daran derart viel ändern?

    Bedeutet das dann, dass du diesen Code auch jedes Mal, wenn du Änderungen an der Hybrid Oberfläche vornimmst, anpassen müsstest?


    Vielen Grüße

    Augur89

  • Der eigentliche Oberflächen Code kann von Früher (mit kleinen Anpassungen) einfach kopiert werden.


    Das Problem ist, dass sich:

    a. in den letzten 6 Jahren einiges geändert hat wie Modelle intern gespeichert und verarbeitet werden.

    b. das Framework (Qt) sich um einiges geändert hat.

    c. ein Großtel des Aufwands ist zu schauen wo überall Effekte des Codecs berücksichtig werden. (Ändert sich der output color space muss auch Avisynth, Vapoursynth, etc. Code aktualisiert werden) Die Jobgenerierung sieht auch indern ziemlich anders aus, da kann man sich teilweise an dem orientieren wie x265 aktuell gehandelt wird, aber dann doch nicht wirklich weil sich da doch einiges geändert hat.


    Man bedenke, dass Hybrid aktuell aus einer 1/4 Millionen Zeilen geschriebenen Code bestehen.

    Das ist ohne UI Darstellungscode oder generiertem Code und der Code ist über 10+ Jahre gewachsen und hat zig Stellen die man Refactoren (= sauberer, strukturierter schreiben) könnte, wenn man die Zeit hätte.

    Geschrieben hab ich für Hybrid natürlich wesentlich mehr Code, aber wenn ich Zeit&Nerv finde zum Refactoren, dann fliegen auch mal ein paar 1000 Zeilencode raus. Das Problem bei wachsendem Code ist immer, dass man am Anfang einfach nicht an alles denken kann, besonders wenn immer mal wieder Sachen hinzukommen.


    ---


    Die Änderungen die ich i.d.R. mache sind recht überschaubar und nicht so groß, das Problem ist nur das sich über die Jahre halt einiges ansammelt. ;)


    Cu Selur


    Ps.: Wäre hilfreich wenn Du die 16bit x265.exe irgendwo hochladen und mir nen Link schicken kannst.

  • vielen Dank für die ausführliche Beschreibung und die damit verbundenen Einblicke.

    Die x265-16bit.exe habe ich dir in einer pm verlinkt.


    Ich mache mir auch nochmal ein paar Gedanken dazu und wünsche erstmal eine gute Nacht.

  • Entschuldigt das ich herein platze. Aber wäre ein Lösungsansatz nicht der, es möglich zu machen gleichzeitig 2 verschiedene Hybrid Versionen installieren zu können, die man parallel nutzen kann? Aus meiner naiven Sicht wäre Augur89 ja damit schon geholfen.... Bin wieder weg ;)

  • Mifsud:

    Zitat

    Entschuldigt das ich herein platze. Aber wäre ein Lösungsansatz nicht der, es möglich zu machen gleichzeitig 2 verschiedene Hybrid Versionen installieren zu können, die man parallel nutzen kann? Aus meiner naiven Sicht wäre Augur89 ja damit schon geholfen.... Bin wieder weg

    Hatte es eigentlich so verstanden, dass Augur89 schon mehrere Hybrid Versionen verwendet,..

    Man kann ohne Probleme mehrere Hybrid Versionen haben man muss nur damit sie nicht kollidieren über die misc.ini die settings Pfade so setzen, dass sie sich nicht überschneiden, oder halt portable Versionen erstellen und nutzen.


    @Augur89:

    Wenn ich:

    erst:

    Code
    1. ffmpeg -y -loglevel fatal -noautorotate -nostdin -threads 8 -i "G:\TestClips&Co\test.avi" -map 0:0 -an -sn -vf zscale=rangein=tv:range=tv -pix_fmt yuv420p16le -strict -1 -vsync 0 -f yuv4mpegpipe - | 16bit-x265 --pmode --pme --input - --input-depth 16 --y4m --no-high-tier --no-open-gop --pass 1 --bitrate 1500 --psy-rd 1.00 --no-rdoq-level --no-psy-rdoq --aq-strength 1.00 --cu-lossless --range full --colormatrix bt470bg --stats "C:\Users\Selur\AppData\Local\Temp\test_2021-07-24@14_01_49_2610_01.stats" --output NUL

    läuft das ohne Probleme durch:

    wenn ich dann:

    Code
    1. ffmpeg -y -loglevel fatal -noautorotate -nostdin -threads 8 -i "G:\TestClips&Co\test.avi" -map 0:0 -an -sn -vf zscale=rangein=tv:range=tv -pix_fmt yuv420p16le -strict -1 -vsync 0 -f yuv4mpegpipe - | 16bit-x265 --pmode --pme --input - --input-depth 16 --y4m --no-high-tier --no-open-gop --pass 2 --bitrate 1500 --psy-rd 1.00 --no-rdoq-level --no-psy-rdoq --aq-strength 1.00 --cu-lossless --range full --colormatrix bt470bg --stats "C:\Users\Selur\AppData\Local\Temp\test_2021-07-24@14_01_49_2610_01.stats" --output "C:\Users\Selur\AppData\Local\Temp\2021-07-24@14_01_49_2610_02.265"

    aufrufe kriege ich abe rimmer:


    1pass encoding scheint ohne Probleme zu gehen.

    Hast Du zufällig ne Idee wo das Problem sein könnte?


    Dachte erst es liegt eventuell am Temp-Pfad aber den ändern bringt auch nix. :/

    • explizites Festlegen der Framezahl mit "--frames xy"
    • threads mit '--pools 1' einschränken
    • '--cu-lossless' rauswerfen

    hilft alles nicht.

  • Main 444 finde ich extrem schlecht, Farben, Nebel, Wasser etc. sind farblich deutlich verfälscht in Serien und Filmen und nicht mehr natürlich.

    Es gibt bestimmt Szenarien wo das verwendet wird, diese erkenne ich aber nicht. Dazu kenne ich mich nicht gut genau aus, was das angeht.

    Main 422 habe ich nicht getestet, aber ich vermute mal, das es ein ähnliches Ergebnis produziert.

  • Zitat von Selur

    Hört sich an als ob:

    a. da was mit dem Encoding nicht simmt

    oder

    b. es Probleme beim Dekodieren

    gibt. Farbunterschiede sollte da keine sein, eventuell luma range (pc vs tv) oder color matrix Problem.


    War aber im Hybrid 2015, ich kann es ja später nochmal im neuen probieren, hab momentan aber noch viele Jobs, vielleicht zum Wochenende, ja war ja bei 2015 so das es diesen Color Range Bug gab, den ich des öfteren mal beobachtet habe, wohlmöglich liegt es daran. Ich teste das bei Gelegenheit nochmal.