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

  • Du hast mich missverstanden. Ich habe zb. 20 Dateien. Ich lade nach und nach jede davon ein und speichere sie unter dem selben Namen ab, wie sie die Originaldateien haben. Nur muss ich das 20 Mal machen bis ich die To-Do Liste abgearbeitet habe. Kann ich auch alle 20 gleichzeitig einlesen, die dann unter dem jeweiligen Namen gespeichert werden?

  • Hybrid rev 2022.03.19.1:

    *fixed*

    • Analysis: FFmpeg color matrix detection
    • Input: make sure fps&frame count in encoders get updated on loading a source
    • aomenc: noise settings for 2pass constrained quality
    • Vapoursynth: split view 'diff' for RGB content
    • Preview: do not use MPlayer for Preview when Avisynth 64bit is used
    • Avisynth: profile: all Misc settings should now be saved in the Avisynth-profile
    • Avisynth: YUY2 needs to converted to YV16 for output.
    • Vapoursynth: mClean handling
    • Vapoursynth: fallback downsizer selection
    • Vapoursynth: missing PlaceboDebandThreshold
    • Vapoursynth: missing AviSource library loading
    • Vapoursynth: vsSMDegrain NNedi3 subpixel selection
    • Vapoursynth: stepped resizing
    • Vapoursynth: fixed vsRIFE missing miscfilters import when sceneChangeDetection was used.
    • Vapoursynth: adds mod4 for vsMCTemporalDenoise&avsTTempSmooth
    • Vapoursynth: clean up model combis
    • Vapoursynth: allow to set ColorMatrix flag when using timeCube
    • NVEncC: Level<>Bitrate mixup
    • FFMpeg: added -bsf:v h264_mp4toannexb for H.264 .avi muxing
    • UTVideo: use yuv44p for ULRG


    *added*

    • Vapoursynth: support filter masking (max and edge mask)
    • Vapoursynth: FillDrops, CCD, parameterized GLSResizer
    • Vapoursynth: 12bit color handling
    • Vapoursynth: parameterized GLSL: adaptive-sharpen, LumaSharpen, ThinLine, A4K Darken
    • Vapoursynth: option to limit Libav threads in VapoursynthTab
    • Avisynth: support Histogram "RGBLevels", "CMYLevels", "RGBParade"
    • Avisynth: use avsInfo/avsInfo64 selection depending on whether Avisynth 32bit or 64bit selection
    • NVEncC: -vpp-colorspace lut3d=".." support


    *changed*

    • Avisynth: Updated TemporalDegrain2 to 2.4.2
    • Vapoursynth: Adjusted to VSGAN 1.6.4
    • Avisynth Script input: force FFmpeg autoCrop detection
    • Vapoursynth: moved aaf and TemporalDegrain to 'rescued.py'
    • Vapoursynth: MCTemporalDenoise nCPU
    • Vapoursynth: save misc in profiles
    • FFMpeg now using matrix instead of out_color_matrix
    • GUI: fullscreen, font size adjustment,...
    • FFMpeg: explicitly call YUV->RGB conversion with matrix on PNG creation and PNG encoder call
    • Vapoursynth: KillerSpots and RemoveDirt disabled since RemoveDirt is broken for Vapoursynth
    • Vapoursynth: '# require colorformat XXX' for custom sections
    • Vapoursynth: changed default behaviour regarding loading libraries and added vsLoadLibrariesOnNonWindows to misc.ini on non-Windows OSs
    • Vapoursynth: use KNLMeansCL-Wrapper from havsfunc for speedUp on YUV content when all channels are filtered
    • Output: allow Hevc for mov container

    *removed*

    • misc.ini: fontSize and toolTipFontSize options


    -> downloads: http://www.selur.de/downloads


    Cu Selur

  • Eigentlich hätte ich diesen Bug-Report/Kommentar auf selur.de gepostet, aber mein user ist aus dem Forum geflogen (war wohl zu lange inaktiv).

    Da (vermutlich) die Fehler schnell gefunden sind und keine ausführliche Spurensuche mit Debug posten etc. nötig ist, poste ich es deshalb hier:

    1.

    Wenn man RemoveGrain mit Vapoursynth nutzt können mode 25-27 nicht ausgewählt werden. War früher auch schonmal bei AviSynth so, und ich meine es war nicht technisch bedingt, sondern irgendwann wurde alter Quellcode kopiert/verwendet, der sich auf eine ältere RemoveGrain Version bezog.


    2.

    AviSynth->Misc->Miscellaneous->Resize before filtering ist schon länger ohne Funktion, ich meine seit es die custom filter order gibt.

    Unter VapourSynth gibt es die Checkbox gar nicht (mehr).


    Imho wäre die Funktion künftig am besten in der Crop/Resize section aufgehoben, damit sie schnell und intuitiv gefunden werden kann.


    Oder sie sollte automatisch aktiv sein, wenn man downsized und die Custom Filter Order deaktiviert ist. Der Profi, der bewusst ein u.U. Vielfaches an Rechenzeit investieren will, weiß was er tut und wird das in der custom filter order ändern.


    Warum? Es geht um die mäßig erfahrenen User, die z.B. einfach nur 4K Unsinn platzsparender aber qualitätsorientiert aufbewahren wollen, und deswegen downsizen und vielleicht noch einen Noise od. Grain Filter verwenden wollen um ohne viel Qualiät zu verlieren die Komprimierbarkeit zu verbessern. Die werden sich vermutlich nämlich häufiger einfach nur über x-fach höhere Encodingzeiten ärgern und der Umwelt und Stromrechnung zuliebe künftig vom Filtern ablassen, da sie nicht tief genug in AviSynth/VapourSynth usw. einsteigen und der ein oder andere wird auch so Dinge, wie dass seine CPU nur zu 30% ausgelastet ist, erst gar nicht bemerken.


    Gruß, mogobime

  • zu 1.: Gerade bei https://github.com/vapoursynth…c/removegrainvs.cpp#L1447 geschaut, sieht nicht so aus, als ob die Vapoursynth Variante Modes > 24 hat.

    => Wenn https://github.com/vapoursynth/vs-removegrain die Modes unterstützt kann ich sie auch in Vaporusynth unterstützen.


    zu 2.: Die Checkbox und auch 'Denoise before Restore' hab ich vergessen zu entfernen. -> werde ich rauswerfen


    Zitat

    Imho wäre die Funktion künftig am besten in der Crop/Resize section aufgehoben, damit sie schnell und intuitiv gefunden werden kann.

    Wird nicht passieren, da sie immer nur in Avisynth existiert hatte.

    Soweit möglich will ich Avisynth/FFmpeg/Vapoursynth getrennt halten.

    Gibt aber noch einiges was ich wohl noch ändern werde über kurz oder lang,... (würde gerne FFmpeg, AviSynth und Vapoursynth noch mehr trennen, vielleicht fliegt 'Filtering' raus und wird zu drei separaten Rabs, aber da weiß ich noch nicht genau wie ich es umsetzen will)

    Cu Selur


    Ps.: RemoveDirt gibt es nicht unter Vapoursynth, sie existierende Version (https://forum.doom9.org/showthread.php?t=169771) ist schon einige Zeit als kaputt bekannt.

  • zu 2.: Die Checkbox und auch 'Denoise before Restore' hab ich vergessen zu entfernen. -> werde ich rauswerfen


    Wird nicht passieren, da sie immer nur in Avisynth existiert hatte.

    Soweit möglich will ich Avisynth/FFmpeg/Vapoursynth getrennt halten.

    Leuchtet mir ein.

    Darüber einen Algorithmus so zu stricken, dass bei deaktivierter Custom Filter Order das Resizing automatisch im Script an die Stelle gesetzt wird, wo die höchste Encoding Performance entsteht (je nachdem ob man upscaled oder downscaled), würde ich nochmal in Ruhe nachdenken, auch im Sinne der Energieeffiezienz.

    Hab jetzt auch keinen wehementen Wiederspruch rausgehört :)

    Wie gesagt, der Profi, der das letzte Quentchen Qualität rausquetschen will und dafür u.U. die vielfache Rechenzeit in Kauf nimmt, wird das imho dann entsprechend in der Filter order anpassen.

  • Ja klar, der Experte wird da wohl bei genauem hingucken Unterschiede feststellen, besonders wenn ein Resizer, der smoothed eingesetzt wird (wie bicubic spline).

    Wird dagegen z.B. lanczos eingesetzt dürften die Unterschiede in der Qualität des denoisings eher gering sein. Subjektiv hatte ich bei 1. denoise und 2. lanczos downscale sogar den Eindruck, dass dadurch tendenziell eher Blockartefakte / Banding sichtbar werden können (und ich Rede jetzt nicht von heftigem denoising, FFT3DGPU z.B. verwende ich bei Sigma eher 20% unter Standardeinstellung). Ob sich da noch die u.U. bis zu 3-4 fache Rechenzeit lohnt?!?

    Gerade bei GPU basierten Filtern wie FFT3DGPU und KNLMeansCL dümpelt die CPU Auslastung da oft bei 30-40% rum (obwohl die GPU laut GPU-Z sogar noch etwas Luft hätte). Eigentlich verwendet man GPU Filter ja, um den Rechenprozess zu beschleunigen...


    Vielleicht wäre eine Möglichkeit da einen möglichst optimalen Kompromiss hinzubekommen, eine per default aktive "Auto" Checkbox bei der Resize Method (mit entsprechender Erklärung im Hilfetext), die z.B. beim upscaling bicubic spline wählt, beim downscaling lanczos, und wenn Filter eingesetzt werden (bzw. bestimmte Filter) immer lanczos.

    Nur so ne Idee um so einen Spagat bestmöglich hinzubekommen, vielleicht fällt dir da noch was besseres ein...

  • Ob das die "besten" Methoden sind wag ich gar nicht zu behaupten, das weißt du wahrscheinlich besser wie ich.

    Nur wenn halt generell immer dieselbe Methode voreingestellt ist, ist es vermutlich nicht die für den Verwendungszweck tendenziell beste (ich glaube bicubic spline ist ja immer default).


    Mir hat halt immer eingeleuchtet, dass beim downscaling eher einen resizer der schärfere Kanten erzeugt, verwendet werden kann, da aus mehr Bildinformation aufs kleinere Bild runtergerechnet werden kann und dann tendenziell weniger Gefahr für Artefakte bestehen sollte, sondern einfach ein schärferes Bild. Was verwendest du beim downscaling?


    Zum Upscaling kann ich, da ich das kaum mache, gar nicht so viel sagen, außer der Annahme, dass ein resizer, der an Kanten zu wenig interpoliert logischerweise eher ein "blockiges" Bild in der Vergrößerung erzeugen wird. Das kenne ich aber eher aus der Vergrößerung statischer Bilder. Hinter welcher Methode steckt überhaupt NNEDI3?


    Vielleicht ist es ja beim reinen up/downscalen ja wirklich nicht so bedeutend bzw. subjektiv, aber wenn noise/grain beim downscaling bestmöglich erhalten werden soll (damit man danach effektiv denoisen kann), was hälst du da für die beste Methode? Bei dem riesigen Zeitgewinn den man bei "denoise/degrain after resize" hat, lohnt es sich ja schon drüber nachzudenken, die tendenziell beste / eine der besten Methoden zu verwenden?!?

  • Zitat

    Was verwendest du beim downscaling?

    Kommt stark auf das Material an.

    Teilweise DPID bei wirkliche großen Unterschieden (8/4K->SD), gerne aber auch SSIMD.

    Bei HD -> SD meist eine Splinevariante oder Gaussresizer.

    Lanczos benutze ich ziemlich selten, da man danach meist noch Artefakte durch das Resizing entfernen sollte.


    Zitat

    Hinter welcher Methode steckt überhaupt NNEDI3?

    NNEDI3 ist ein auf Neural Networking basierendes resizing. Für allgemeine Presets wäre das meine Empfehlung weil er sich sowohl bei Animes&Co also auch bei natürlicherem Material und auch CG Material gut verhält.


    Zitat

    Vielleicht ist es ja beim reinen up/downscalen ja wirklich nicht so bedeutend bzw. subjektiv, aber wenn noise/grain beim downscaling bestmöglich erhalten werden soll (damit man danach effektiv denoisen kann), was hälst du da für die beste Methode? Bei dem riesigen Zeitgewinn den man bei "denoise/degrain after resize" hat, lohnt es sich ja schon drüber nachzudenken, die tendenziell beste / eine der besten Methoden zu verwenden?!?

    Prinzipiell würde ich davon abraten zu resizen und dann zu denoisen.

    Gefahren durch Upscaling sind:

    a. Rauschen und echte Details sind schwerer zu unterscheiden weil durch das Resizen i.d.R. neue Artifakte entstehen

    b. besonders Methoden die sich an Makroblockgrößen orientieren arbeiten gegebenenfalls nicht mehr so effizient da

    Gefahren beim Downscaling sind:

    a. besonders Methoden die sich an Makroblockgrößen orientieren arbeiten gegebenenfalls nicht mehr so effizient da

    b. Rauschen und echte Details sind schwerer zu unterscheiden weil sie je nach Resizer vermatscht werden.


    Bei direkten Aufnahmen/Scans von Filmen oder bei Restaurationen, wenn u.a. Kompressionsartifakte entfernt werden sollen kann das wirklich einen wichtigen Unterschied machen.


    Zitat

    Gerade bei GPU basierten Filtern wie FFT3DGPU und KNLMeansCL dümpelt die CPU Auslastung da oft bei 30-40% rum

    Frage ist halt was da der Bottleneck ist. Ein Filter? Der Encoder (gerade bei x265 wird bei SD nicht so 'gut' multithreaded) ? Wenn der Bottleneck wirklich das Filtering ist, kann es manchmal auch hilfreich sein die Avisynth/Vapoursynth Threads zu limitieren. (Teilweise kann es sogar Sinn machen multithreading zu deaktivieren.)


    Nebenbei: Wenn es um Geschwindigkeit geht würde ich auch empfehlen mal ein paar GLSL Filter anzutesten wie sie z.B. im MPV verwendet werden. Kombination die ich gerne mal verwende ist CAS+GLSL für anti aliasing +GLSL für anti ringing. (Schnell aber weist gut.) Gibt aber auch ein paar hilfreiche Denoiser.


    Cu Selur

  • Zitat

    NNEDI3 ist ein auf Neural Networking basierendes resizing. Für allgemeine Presets wäre das meine Empfehlung weil er sich sowohl bei Animes&Co also auch bei natürlicherem Material und auch CG Material gut verhält.

    Jetzt müsste man halt noch wissen, welche der 10 Hybrid resizer Methoden das verwendet :)


    Zitat

    Gefahren beim Downscaling sind:

    a. besonders Methoden die sich an Makroblockgrößen orientieren arbeiten gegebenenfalls nicht mehr so effizient da

    b. Rauschen und echte Details sind schwerer zu unterscheiden weil sie je nach Resizer vermatscht werden.

    Punkt a) lässt mich jetzt schon darüber nachdenken, beim downscaling mal anstatt z.B. dem wohl makroblockorientierten fft3dgpu auch anderen Methoden eine Chance zu geben. Den Eindruck, dass hohe Sigma Werte bei 1. downscaling 2. filtern weniger Gewinn bei der Komprimierbarkeit bringen, als beim reencoding bei gleicher Auflösung hatte ich auch schon (allerdings verwende ich normalerweise eh niedrigere sigma werte als default).


    Eine (am besten GPU basierte) Methode, die auch bei 1. filtern, 2. resizen schnell ist und ähnlich gute Gewinne bei der Komprimierbarkeit bringt wie fft3dgpu wäre natürlich ne eierlegende wollmichsau :) Z.B. So ein performanter GLSL temporal noise Filter in Hybrid wäre schon cool.

    Fft3dgpu ist halt bei mir bei 1. resizen 2. filtern praktisch gleich schnell wie ohne filtern (andersrum lahm) und spart schonmal 20% bitrate. KNLMeansCL ist nur unwesentlich langsamer. Ich komm allerdings ins Grübeln ob ich das künftig noch so machen soll...


    Punkt b) würde ja schon tendenziell für einen resizer wie Lanczos sprechen, da eher weniger vermatschen


    Zitat

    Frage ist halt was da der Bottleneck ist. Ein Filter? Der Encoder (gerade bei x265 wird bei SD nicht so 'gut' multithreaded) ? Wenn der Bottleneck wirklich das Filtering ist, kann es manchmal auch hilfreich sein die Avisynth/Vapoursynth Threads zu limitieren. (Teilweise kann es sogar Sinn machen multithreading zu deaktivieren.)

    Genau x265 versuche ich zu vermeiden, da es imho viel zu viel Rechenleistung frisst. Da komme ich mit x264 10bit + z.B. nem vernünftigen denoise filter, der (je nach Quellmaterial) nicht zu stark eingestellt ist für meine Geschmack besser ans Ziel.

    Mit 10bit kommt es zu weniger banding (was ich als einen der nervigsten Artefakte empfinde) und blocking, imho selbst wenn man beim CRF 1-2 Stufen höher geht (also bei mir 19-20 statt 18 bei 8bit) und nen denoiser verwendet. Auch bei 8bit Quellmaterial.


    An den AVS/VPS threads spiele ich normal immer rum, da gibt's i.d.R. nix mehr zu heben. FFT3DGPU beispielsweise läuft bei mir seit V. 0.8.6 bei 1080p nur noch mit einem AVS thread vernünftig, mehr ist immer langsamer. KNLMeansCL braucht mind. CPU cores*1,5 statt *1,0.


    Scheinbar spielen bei 4K input meine GPU Limitierungen schon auch mit rein (oder der VRAM). U.a deswegen (neben der Energieeffizienz) hab ich es seither meist gemieden 4K mit aufwändigen Filtern zu bearbeiten und erst downgescaled.

    Hab spaßeshalber die precision bei fft3dGPU mal von 2 auf 0 gesenkt, da war 4K input bei 3-4 MT threads schon gut 50% schneller, aber die CPU Auslastung trotzdem erst bei rund 66%. Außerdem war die Bitrate rund 6% höher -> alles in allem nicht zufriendenstellend und zu lahm.


    4K input hab ich wenn dann seither i.d.R. eher mit nem simplen spatial Filter wie z.B. GemoveGrain im mode 27 gefiltert, das bringt schon ne gewisse Verbesserung in der Komprimierbarkeit, ohne die qualität zu stark zu beeinträchtigen. Bringt aber natürlich nicht so viel wie ein gescheiter temporal noise Filter.


    Zitat

    Nebenbei: Wenn es um Geschwindigkeit geht würde ich auch empfehlen mal ein paar GLSL Filter anzutesten wie sie z.B. im MPV verwendet werden. Kombination die ich gerne mal verwende ist CAS+GLSL für anti aliasing +GLSL für anti ringing. (Schnell aber weist gut.) Gibt aber auch ein paar hilfreiche Denoiser.

    Was ist MPV?

    Nen GLSL Filter habe ich bei Vapoursynth nur unter deringing gefunden, einen CAS nirgendwo.

    GLSL Denoiser/Degrainer sind mir auch keine in Hybrid aufgefallen.

  • Zitat

    Jetzt müsste man halt noch wissen, welche der 10 Hybrid resizer Methoden das verwendet

    Keine. NNEDI ist ja eigentlich ein Deinterlacer bei dem ein Frame in Hablbilder getrennt wird und dann aus den Halbbildern Vollbilder mit doppelter Größe erzeugt werden. (Darum ist das Resizing mit NNEDI3 immer in 2er Potenzen.


    Zitat

    Was ist MPV?

    mpv -> https://mpv.io/


    Zitat

    Nen GLSL Filter habe ich bei Vapoursynth nur unter deringing gefunden, einen CAS nirgendwo.

    GLSL Denoiser/Degrainer sind mir auch keine in Hybrid aufgefallen.

    CAS ist ein normaler Sharpener.

    Hybrid erlaubt es beliebige GLSL filter zu verwenden die von placebo.Shader unterstützt werden.


    Cu Selur


    Ps.: gerade keine Zeit den rest zu lesen.

  • hier mal was zum Rumspielen:

    (Pfade musste anpassen)

    -> Bei den normalen Resizern sieht man sehr wenig unterschiede wenn stärker resized und später wieder beim Playback upscaled wird. ;)



    Cu Selur

  • Weiß nicht ganz was mir das Skript zeigen soll.

    Die spezellen Resizer wie SSIMD / DPID / NNEDI hab ich mittlerweile in Hybrid unter Filtering->AviSynth/VapourSynth->Frame->Resize gefunden. Das ist mir bisher tatsächlich entgangen, dass man hier die normalen resizer im AVS/VS Skript "überschreiben" kann.

    Leider sind die auch ziemlich rechenintensiv. Werd mal bei Gelegenheit noch GLSL resizer probieren, oder ist der für downscaling nicht so gut?


    Um mich nochmal selbst zu zitieren: Der ein oder andere performante GLSL denoiser/degrainer Filter in Hybrid wär ne coole Sache, falls sowas existiert ;)

    Ersatzweise bin ich bei der Suche nach Denoisern/Degrainern die bei direktem 4K Input (und erst anschließendem resizen) einigermaßen flott und temporal sind auf FluxSmooth gestoßen, der ist "SpatioTemporal" und ich hab da bei 4K lediglich einen Speedverlust von nur ca 3%.

    Dafür sinkt die Bitrate um 10-13% wenn man die tresholds auf 80-100 anhebt. Großartige Qualitätsverluste sind mir dabei - jedenfalls auf den ersten Blick - nicht aufgefallen, jedenfalls kein auffälliges blurring.


    Den normalen Gauss resizer hab ich auch mal probiert, der ist einer der flottesten und hat krass Bitrate eingespart (um die 12% im Vergleich zu Spline16, um die 15% im Vergleich zu Lanczos). Allerdings war der erste Eindruck schon, dass der über der Wahrnehmungsschwelle blurred (hab allerdings noch keine ausführlichen Vergleiche gemacht). Das wäre dann wohl, wenn sich das bewahrheitet, eher nicht erste Wahl beim downscaling, eher beim upscaling. Schade...


    Zitat

    -> Bei den normalen Resizern sieht man sehr wenig unterschiede wenn stärker resized und später wieder beim Playback upscaled wird

    Mittlerweile downscale ich i.d.R. von 4K zu fhd/1080p, was dann der nativen Auflösung des TVs entspricht. Lieber bisschen filtern um Speicherplatz zu sparen, anstatt den Displays erneutes hochskalieren von irgendwelchen krummen Auflösungen wie 720p oder SD zuzumuten.

    4K Quatsch Displays kauf ich frühestens wenn die alten hinüber sind. Lohnt sich erst bei > 65" oder wenn man sich mit 1,5m Abstand davorsetzt, für sowas hab ich keinen Platz. Und der Hauptvorteil 10bit / HDR Kompatibilität kann derzeit mangels entsprechendem Quellmaterial traurigerweise nicht ausgeschöpft werden. Und für ein künftiges 4K Display sollte es easy sein von 1080p hochzuskalieren, die haben ja üblicherweise genau die 4fache Auflösung/Pixelzahl.

  • Zitat

    Werd mal bei Gelegenheit noch GLSL resizer probieren, oder ist der für downscaling nicht so gut?

    Erhlich gesagt: noch nie versucht, hatte bis dato immer nach Upscalern gesucht. :)

    Ist nicht ein Resizer, sondern da ist ein ganzer Sack von glsl-Filtern zur Auswahl die mit 'GLS Resizer' verwendet werden können. :)


    Zitat

    Der ein oder andere performante GLSL denoiser/degrainer Filter in Hybrid wär ne coole Sache, falls sowas existiert

    Wenn Du glsl Filter findest die in MPV funktionieren, gehen sie vermutlich auch in Hybrid über vs-placebo. :)

    Kannst Du unter Filtering->Vapoursynth->Others->GLSL einfach laden.



    Cu Selur


    Ps.: GLSL filtering in Vapoursynth, suche Empfehlungen? ist vielleicht noch interessant

    PPs.: Mal gesucht und keine DeNoiser, DeGrain filter gefunden die mit vs-placebo funktionieren.