Multithreaded Videofilterung für H.264-Encodierung

  • Sagt mal gibt es ein h264 Tool das vernüftig Multithreading kann. Avisynth kann es ja nicht und Avisynth MT taugt nix.

    Gibt es kein Tool das 2 oder mehr Files paraleel kann?

    Staxrip muss man wohl auch 2 mal starten. Und auch eher eine Frickellösung.

    Edited once, last by trecordings (April 12, 2012 at 12:03 AM).

  • Deine Aussage über Avisynth macht schon allein deshalb keinen Sinn, weil Avisynth kein H.264 Encoder ist, sondern ein Frameserver.

    Avisynth kann also höchstens einen H.264 Encoder, wie z.B. x264, mit Eingabedaten beliefern. Avisynth selbst erzeugt aber keine H.264 Streams. Dafür ist der Encoder zuständig.

    Multi-threading kann dabei sowohl auf Ebene von Avisynth als auch auf der Ebene des H.264 Encoders erfolgen. x264 unterstützt schon sehr lange Multi-Threading und skaliert problemlos auf mindestens 16 Prozessoren!

    Das Multi-Threading von x264 nützt natürlich herzlich wenig, wenn der Flaschenhals dein Avisynth-Skript ist. x264 kann die Frames nun mal nicht schneller verarbeiten, als sie von Avisynth angeliefert werden ;)

    Avisynth-Skripte können wiederum auf zwei Arten von Multi-Threading profitieren: Entweder durch Avisynth-Plugins, die selbst Multi-Threading unterstützen, oder durch Avisynth MT. Geht natürlich auch beides zur selben Zeit.

    (BTW: Avisynth MT kann sehr wohl vernünftig funktionieren, wenn man es denn richtig einsetzt. Für weitere Details wäre es natürlich hilfreich zu wissen, was genau du vor hast und wie dein Avisynth-Skript aussieht...)

  • Mein Problem ist halt das Avisynth nicht hinterherkommt. Und die CPU nicht auf Bohne ausnutzt. War vielleicht nicht klar genug ausgedrückt.

    Und das ist mit Avisynth MT nicht zu ändern. Ich habe das x mal versucht. Ist Zeitverschwendung. Also bitte dazu keine Diskussion, weil die hilft nicht weiter. Habe damit genug Zeit verschwendet. Das MT ist simpel abgegessen für mich.;)

    Also suche ich nun was, das mehrere Files über Avisynth auf einmal macht. Staxrip zb kann man nur 2 mal starten. Aber das ist auch sehr unbequem. Batch ist damit nicht wirklich möglich.

    Und Script sind nix dolles.
    LanczosResize(%target_width%,%target_height%)
    hqdn3d(3,2.6,4)

    HD zu SD Material.

    Der Punkt ist das kommt dann bei Present Medium auf 33 Minuten für 45 Minuten Material. Bei Veryfast wird es nicht schneller weil eben Avisynth nicht hinterherkommt. Dann Chillt die CPU rum.

    Ach ja über sinn von Verayfast will ich nun nicht reden.;)

    Hätte ich ein komplexeres Script wäre die Dicke CPU für den hintern wenn Avisynth nicht hinterherkommt. Auf Deutsch gesagt. Also suche ich was für parallel.

  • >> Dann nenne mal welche.

    Schnarch. Est ist ja nicht mal klar was eigentlich das Problem ist. Wenn ich schon lese "Avisynth MT taugt nix", dann ist doch eh' schon alles klar. (Avisynth-MT benutze ich quasi täglich, und zwar ohne Probleme ... andererseits, das beste Auto der Welt hilft nix, wenn der Fahrer in der Kurve geradeaus fährt, das ist auch klar.)

    Mit den OneKlick-GUIs kenn ich mich bekanntlich nicht aus, nutze ich nie ... Hybrid, jedenfalls, kann mehrere Jobs des Queues parallel abarbeiten.

  • (Nachtrag) - Ach Gottchen, ausgerechnet HQDN3D.:rolleyes_: - Ja, mit dem is' natürlich Essig mit MT. Der Filter ist selbst-rekursiv, das KANN mit temporalem Multithreading (SetMTmode) gar nicht funktionieren. Wenn überhaupt, dann spatial über MT() ... und dann ist noch nicht klar ob der Filter das zulässt. Der ist von 2004 oder 2005, da wurde wohl noch gar nicht an Multithreading gedacht. Wenn der Filter womöglich intern globale Variablen verwendet, dann war's das mit MT.

    So. Haddu also einen uralt-Filter gefunden der nicht MT-tauglich ist. Und deswegen "taugt Avisynth MT nichts."

    Wünsche angenehme Nachtruhe.

  • Quote

    (Avisynth-MT benutze ich quasi täglich, und zwar ohne Probleme ... andererseits, das beste Auto der Welt hilft nix, wenn der Fahrer in der Kurve geradeaus fährt, das ist auch klar.)

    Nicht sonderlich hilfreich.

    Quote

    So. Haddu also einen uralt-Filter gefunden der nicht MT-tauglich ist. Und deswegen "taugt Avisynth MT nichts."

    Falsch und ebenfalls nicht hilfreich.

    Hybrid hm, müsste ich mal gucken. Ne weile her wo ich das probiert habe.

  • Ist schon interessant, dass ausgerechnet Didée, der von uns allen hier vielleicht die meiste praktische Erfahrung mit AviSynth hat und Funktionen wie TempGaussMC entwickelt hat, mal eben so ein "Falsch" an den Kopf geknallt wird. :nein:

    Im Gegensatz dazu sehe ich schon im Ansatz deines Skriptes grundlegende Probleme: Rauschfilter nach einem Resize zu verwenden kann deren Effizienz verschlechtern, da sie dann nicht das originale Rauschen filtern, sondern Mittelwerte aus dem Rauschen. Andererseits wird das Filtern von HD-Videoquellen aufgrund der größeren Bildfläche schon erheblich länger dauern als das Filtern nach der Verkleinerung auf SD. Da wäre funktionierende Parallelisierung besonders nützlich.

    Mit etwas höflicher Zurückhaltung hat Didée vielleicht sogar Lust, dir bei der Optimierung deines Problems zu helfen. Ich wüsste hier keinen, der das besser könnte. Allerdings wird ein wirklich optimales Ergebnis sicher für jeden einzelnen Film etwas anders aussehen.

    Das parallele Encodieren von mehreren Skripten, die HD-Videoquellen verarbeiten, kann allerdings auch noch aus anderen Gründen problematisch werden: In einer 32-bit-Verarbeitungskette stehen pro Aufruf maximal 2 GB RAM zur Verfügung. Und wenn mehrere Verarbeitungsketten jeweils die für sich allein optimale Anzahl an Threads ausführen wollen, dann wird die doppelte Anzahl dafür sorgen, dass sie sich andauernd gegenseitig behindern. Dann also besser immer nur je einen Film, den dafür aber optimal parallelisiert.

    Auf gute Zusammenarbeit:

    REGELN befolgen | SUCHE benutzen | FAQ lesen | STICKIES beachten

    Edited once, last by LigH (April 12, 2012 at 9:18 AM).

  • Wenn man nur LanczosResize und hqdn3d verwendet, könnte man sich auch einfach eine Batch schreiben, in der Batch mencoder mit den gewünschten Parametern aufrufen und für jedes File was man encoden will die Batch aufrufen,...
    (sollte aber auch einige Tools geben, die Mencoder parallel ausführen können,..)

    Cu Selur

  • Vermutlich ist HQDN3D gar nicht so sehr das Problem. Zumindest scheint er "sauber" programmiert zu sein - er profitiert zwar nicht von SetMTmode (wird sogar minimal langsamer, weil wegen der Selbstrekursion jeder Thread auf alle anderen warten muss), aber zumindest scheint es keine Fehler zu geben. Und über die spatiale MT("""...""") - Variante lässt er sich sogar tatsächlich beschleunigen... zumindest etwas. (Der Filter ist von Haus aus schon wacker schnell, da erreicht man auch mit Multithreading keine gewaltigen Durchbrüche mehr.)

    Geschwindigkeits- und/oder Auslastungstechnisch liegt das Problem also eher woanders.

    a) Bei den schnellen x264-Presets wird die Luft sowieso langsam immer dünner.

    b) die Art der Quelle spielt eine große Rolle:
    b1) ist es 24/25fps Film, oder 50/60fps Vollbildvideo? Vom einen zum anderen macht das einen Geschwindigkeitsunterschied von 200% bis 250% ! -- man~weiß~es~nicht

    b2) von 2000kbps Spar-720p (ohne CABAC) bis zu 30000kbps HiQ-FullHD (mit CABAC) ist ein groooßer Unterschied alleine beim Dekodieren -- man~weiß~es~nicht

    c) 2-Kern, oder 4-Kern, oder 6Kern-CPU, mit oder ohne Hyperthreading -- man~weiß~es~nicht, aber es macht halt schon einen gewissen Unterschied ...


    Ein paar "Geschwindigkeiten":
    (Input 1080p24 Film @ 12Mbps, Resized zu 720x576, auf i7-860/HT)

    Zuallererst mal dieses:

    --preset veryfast (Lanczosresize): 78.74 fps
    --preset veryfast (BicubicResize): 96.01 fps

    Hoppla. Dass alleine der popelige Resizer so einen Unterschied macht, also nein, wer sollte das denn auch ahnen ... :D
    (Und nein, beim 'runterskalieren ist bicubic nicht schlechter als lanczos...)


    --preset medium, +bicubicresize, -HQDN3D, 1thread: 76.67
    --preset veryfast, +bicubicresize, -HQDN3D, 1thread: 96.01

    (ohne HQDN3D ist 'veryfast' schneller als 'medium')


    --preset medium, +bicubicresize, +HQDN3D, 1thread: 56.96
    --preset veryfast, +bicubicresize, +HQDN3D, 1thread: 67.55

    (mit HQDN3D ist 'veryfast' AUCH schneller als 'medium')


    --preset medium, +bicubicresize, +HQDN3D, MT(4,4): 67.98
    --preset veryfast, +bicubicresize, +HQDN3D, MT(4,4): 81.54

    (MT()-Multithreading sorgt sogar hier durchaus noch für eine Beschleunigung, sowohl bei 'medium' als auch bei 'veryfast'.)


    Also, von wegen "taugt nix, bringt nix", das ist alles Käse. Es taugt, und es bringt.

    Ganz falsch ist auch die Meinung

    Quote

    Hätte ich ein komplexeres Script wäre die Dicke CPU für den hintern wenn Avisynth nicht hinterherkommt.


    weil es nämlich genau andersrum ist. Wenn das Script "sehr einfach und sehr schnell" ist (so wie hier), dann lässt sich über Multithreading meistens auch nimmer so arg viel rausholen. Da liegen die "Flaschenhälse" einfach ganz woanders.
    Aber gerade bei "komplexen", rechenaufwändigen Scripten, GERADE DA hat man die Vorteile durch Multithreading. Bei 4 Kernen kann das im Idealfall durchaus wirklich bis knapp 400% 'raufgehen.

  • Quote

    Im Gegensatz dazu sehe ich schon im Ansatz deines Skriptes grundlegende Probleme: Rauschfilter nach einem Resize zu verwenden kann deren Effizienz verschlechtern, da sie dann nicht das originale Rauschen filtern, sondern Mittelwerte aus dem Rauschen. Andererseits wird das Filtern von HD-Videoquellen aufgrund der größeren Bildfläche schon erheblich länger dauern als das Filtern nach der Verkleinerung auf SD.

    Eben. Das ist um Faktor 3. Also durch das Verschieben der Anordnung wird der Rauschfilter um den Faktor 3 langsamer. Wobei das eben nicht an der CPU I7 Core liegt.

    Hier muss ich wohl einen Kompromiss machen wenn es keinen Multicore denoiser gibt. Sonst werden Moderne CPUs zum Videobearbeiten irgendwann sinnfrei, wenn immer mehr Power ungenutzt bleibt, weil die Software veraltet ist.

    Quote

    Das parallele Encodieren von mehreren Skripten, die HD-Videoquellen verarbeiten, kann allerdings auch noch aus anderen Gründen problematisch werden: In einer 32-bit-Verarbeitungskette stehen pro Aufruf maximal 2 GB RAM zur Verfügung. Und wenn mehrere Verarbeitungsketten jeweils die für sich allein optimale Anzahl an Threads ausführen wollen, dann wird die doppelte Anzahl dafür sorgen, dass sie sich andauernd gegenseitig behindern. Dann also besser immer nur je einen Film, den dafür aber optimal parallelisiert.

    Hm würde da Avisynth 64 Bit was helfen?
    Ram hätte ich mit 8 Gig ja.

    Goldwingfahrer
    Aber wirklich gut ist die Last auf einem Foto auch nicht oder irre ich mich da?
    Wobei ich nie ein Freund von Eidus war. Weil ich nie zu den Ergebnissen gekommen bin.
    Hatte da auch schon 2-4 mal viel Zeit für nix geopfert.

    Selur
    Ich gucke mir noch mal dein Hybrid an. Meine Probleme mit dem asynchronen Ton war ja nur bei DVD. Diesmal geht es um HD Quellen. Außerdem habe ich mitbekommen, dass Du einiges geändert hattest.

    fft3dgpu schau ich auch mal.Sagt mir auf anhiebt nix.:)

    Didée

    Quote

    Also, von wegen "taugt nix, bringt nix", das ist alles Käse. Es taugt, und es bringt.

    Das ist schön für dich.

    Zu Pampig?
    Sorry aber welchen Teil von „ich will darüber keine Diskussion führen“ wurde nicht verstanden?

    Ich habe MT x mal getestet in den Jahren. Nicht nur mit dennoisern und es bringt nix. Gibt hier auch Threads dazu, wo ich das in allen Einzelheiten dargelegt hatte. Da kann es bei anderen 2000 mal was bringen, das bringt mir nix. Und ich lege das nicht noch mal bis in kleinste dar. Wenn Du also nicht willst, dass es hier unfreundlich wird, dann respektiere doch meine Aussage. Das MT bei mir wirkungslos ist und immer war. Weil selbst wenn ich dazu zu doof wäre, ändert das nix. Der Spruch ist auch wirklungslos.

    Wenn Du merkst, Du reitest ein totes Pferd steig ab.:ja:

    Zur Sache

    Quote

    Zuallererst mal dieses:

    --preset veryfast (Lanczosresize): 78.74 fps
    --preset veryfast (BicubicResize): 96.01 fps

    Das teste ich mal. Danke.

  • Zu Pampig?

    Ja, durchaus.

    Das tote Pferd reitest du dann allerdings ebenso bei der Wahl deiner Mittel. Bei den Verhältnissen zwischen Filterungs- und Encodier-Rechenaufwand sowie anderen Hardware-Faktoren (Festplatten-/RAM-/Bus-Datendurchsatz) ist nicht weiter verwunderlich, dass ein Multithreading der Filterung alleine noch keine spürbaren Auswirkungen hat – weil die Filterung eben gerade nicht der Flaschenhals ist. Wie der Kleinwagenfahrer, der V-Power tankt und einen Spoiler ans Heck montiert; trotzdem hat sein Motor immer noch weniger als 100 PS.

  • Quote

    Goldwingfahrer
    Aber wirklich gut ist die Last auf einem Foto auch nicht oder irre ich mich da?
    Wobei ich nie ein Freund von Eidus war. Weil ich nie zu den Ergebnissen gekommen bin.

    War ja nur ein Beispieltool das ich hier nebst Hybrid von Selur einsetze,klar ist da sicher noch mehr rauszuholen.
    Mir reichts so aus.Avisynth brauche ich für andere Filterungen und da komme ich,wenn ich will,auf Auslastung von über 95 % auf allen 8 Kernen.
    Alle PCs hier sind nun i7 2600K und haben je 8 GB Ram.
    Wechselsystem XP und W7. [Ultimate und Prof.]
    Avisynth 32 Bit aber hauptsächlich nur unter XP.

    Datenrettungen Normwandlungen Restaurierungen Digitalisierungen

  • Selur
    fft3dgpu bringt nix. Da ist die CPU Only schneller. Meine Karte Nvidia Geforce GT 555M.

    Wobei ich mir das dachte. GPU brachte in meinen vielen Test auch nie was. Wobei ich auch immer deutlich bessere CPUs hatte als GPU.

  • Oh, a propos FFT3dFilter. Nehmen wir den doch einfach mal als Beispiel für einen LANGSAMEN Filter. :)


    Single threaded:

    Code
    DGSource("1080p.dgi")bicubicresize(1280,536,-.4,.3)fft3dfilter(sigma=2,bw=24,bh=24,ow=12,oh=12,bt=5,plane=4)trim(30000,32000)return(last)
    Code
    x264 --preset veryfast -o "speedtest.mkv" "script.avs"encoded 2001 frames, [b]4.40 fps[/b], 1000.58 kb/s     #  { ~16% CPU }


    Multithreaded #1:

    Code
    setmtmode(5,6)SetMemoryMax(666)DGSource("1080p.dgi")removegrain(0)changefps(last,last,true)setmtmode(2)bicubicresize(1280,536,-.4,.3)fft3dfilter(sigma=2,bw=24,bh=24,ow=12,oh=12,bt=5,plane=4)trim(30000,32000)return(last)
    Code
    x264 --preset veryfast -o "speedtest.mkv" "script.avs"encoded 2001 frames, [b]9.25 fps[/b], 1000.58 kb/s     #  { 80~85% CPU }


    Multithreaded #2:

    Code
    setmtmode(5,8)SetMemoryMax(666)DGSource("1080p.dgi")removegrain(0)changefps(last,last,true)setmtmode(2)bicubicresize(1280,536,-.4,.3)fft3dfilter(sigma=2,bw=24,bh=24,ow=12,oh=12,bt=5,plane=4)trim(30000,32000)return(last)
    Code
    x264 --preset veryfast --threads 8 -o "speedtest.mkv" "script.avs"
    
    
    encoded 2001 frames, [b]10.13 fps[/b], 1001.01 kb/s     #  { 99~100% CPU }

    Na, schau mal an. Von 4.4fps auf 10.1 fps. - Wie verträgt sich das nun mit Deiner "es bringt aber nix" Aussage?


    Falls es also noch nicht angekommen sein sollte, hier nochmal in Kürze:

    - Wenn (Script=langsam), dann (Multithreading=schnell).

    - Wenn (Script=schnell), dann (Multithreading=überflüssig), weil nämlich (Problem=woanders).

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!