AviSynth und CUDA / oder: Optimale Komprimierbarkeit für YouTube

GelberDrache

Einen schönen gut Abend...
Ich wollte mal fragen ob es Möglichkeit gibt wenn man Avisynth nutzt, für das Rendern CUDA zu nutzen und dann über die CPU das encoding laufen zu lassen...

Da ich Skripte verwende wo doch ein großer Anteil an Bildberechnung vorhanden...
Und gerade hier sollte ja dann eigentlich die Stärke vom CUDA zum tragen kommen...

LigH

Kurz: Bisher praktisch keine.

Es gibt wenige Plugins, die spezielle Videodecoder-Funktionen von Grafikkarten (DGDecNV: Nvidia PureVideo oder DGDecIM: intel QuickSync als Decoder, FFT3DGPU als Shader-Filter) oder OpenCL (NLMeansCL2) zur Filterung verwenden können. Aber den kompletten Kern von AviSynth auf GPU-Verarbeitung umbauen wird wohl kaum so leicht passieren: Erstens ist die nichtlineare Filterung in der Grafikkarte nicht so leicht ebenso flexibel möglich (die Befehlssätze sind stark eingeschränkt), zweitens dauert auch der Transfer von Videoframes zwischen Hauptspeicher und Grafikkartenspeicher seine Zeit. Und wenn, würde man sich mit CUDA auch ausschließlich auf Nvidia beschränken; bei OpenCL hätte man wenigstens eine breite Auswahl durch den gemeinsamen Standard.

Hinweis: Bitte nicht y und i vertauschen...

GelberDrache

OK...
Gibt es die Möglichkeit Motion Blur und Spline Resizer (100,16,32,64) über die Grafikkarte laufen zu lassen?
Da gerade die beiden am meistens Leistung fressen..

LigH

Wenn schon Skalierungen am meisten Zeit beanspruchen, kannst du ja glücklich sein... Oft sind die Resultate mit weniger Taps schon hinreichend angenehm und auch deutlich schneller als die Varianten mit vielen Taps, die auch gern zum Überschärfen neigen (Gibbssches Phänomen). Also lieber mal nur Spline16 statt Spline64 versuchen.

Und was Motion Blur angeht ... weiß ja nicht, zu welchem Zweck du sowas verwendest. Oft erkennt man Beschleunigungsmöglichkeiten, wenn man den Zweck mal genauer analysiert und vielleicht feststellt, dass man eigentlich was anderes will.

GelberDrache

Ok ich glaube ich hole mal ganz genau aus
Also ich komme aus dem Lets Play Bereich...
Wir haben halt nicht nur denn Faktor des normalen Encodes, sondern auch noch denn von Youtube...

Der sieht wie folgt aus:
Standard CRF von 30, pro Auflösungsstufe kriegen wir unterschiedliche maximale Durchschnittliche Bitraten
720p : 2.000 Kbit/s
1080p : 4.000 Kbit/s
1440p : 10.000 Kbit/s (minimale Auflösung 1170p)
2160p : 22.000 Kbit/s (minimale Auflösung 1800p)

Dementsprechend wird im Normalfall Spline 100 genutzt, damit es nachher von Youtube besser Komprimiert werden kann.
Hierzu kommt dann noch der Motion Blur im in der Bewegung die Komplexität weiter zu reduzieren.
Spline 16,36,64 werden eher selten genutzt da man das an das Videomaterial anpassen muss damit die maximale Bitrate nicht überschrieben wird.

Das heißt im schlimmsten Fall muss man mit einer Skalierung von 720p auf 1800p rechnen...
Wobei bei einem I7-3930K @4.2 Ghz bereits die Fps des Encodes von 34,44 auf 6,43 fällt beim einem Preset von Medium und einem CRF von 23 und das noch ohne Motion Blur und 10 Bit Encod...
Deswegen interessiere ich mich halt dafür, ob es eine Möglichkeit gibt...

GelberDrache

Moin
Ich bin es nochmal
Hab jetzt ein bisschen mit Sagaras ausprobiert was uns die Verwendung der GPU bringt...
DGDecNV: Nvidia PureVideo und DGDecIM: intel QuickSync fällt leider raus da sie kostenpflichtig sind.
FFT3DGPU fällt leider auch raus da es nur ein Shader ist.

NLMeansCL2 wurde getestet, aber hier sind die Ergebnis der Geschwindigkeit leider zu schlecht...
Vielleicht hast du ja noch eine Idee wie man das verbessern kann.
Also Skript hatten wir:

LoadPlugin("C:\Program Files (x86)\SagaraS Scriptmaker\Plugins\SplineResize.dll")
LoadPlugin("C:\Users\Stefan\Desktop\NLMeansCL2.dll")

SetMTMode(5,5)
AVISource("A:\Tutorial\Vergleiche\Aufnahme\SamHD_2015_01_08_21_27_03_621.avi", audio=false).AssumeFPS(60,1).Spline100Resize(3200,1800).ConvertToYV24()
NLMeansCL2(last, 4, 4, 2, 2, 1, 1, 1.0, 1.8, true, "GPU", 3, 2, 2, false, false, true)

LigH

DLLs gehören nicht auf den Desktop. Allerhöchstens Verknüpfungen zu Programmen, Dokumenten und Verzeichnissen.

Ich hoffe, du weißt, was die beiden Parameter hier bedeutet: SetMTMode(5,5) kann vernünftig sein. Muss aber nicht...

Definitiv würde ich empfehlen, Befehle nicht allzu sehr mit Punkt zu verketten, wenn man mit MT arbeitet, denn so fällt es schwer, zwischen Befehlssequenzen mal den MT-Modus zu wechseln. Insbesondere sollten Source-Funktionen und Filter mit Hardwarezugriff immer einzeln stehen, weil die am ehesten das Risiko tragen, nicht im optimalen Modus 2 (wenn nicht gar 1) zu funktionieren.

Was auch noch merkwürdig ist, ist das ConvertToYV24(); erstens mal überhaupt der Nutzen, und dann auch erst nach dem Skalieren? Welcher Farbraum war denn vor der Konvertierung, gleich nach AviSource, vorhanden?

Für AviSource() kann Modus 5 sinnvoll sein, außerdem sollte man Prefetch() für linearisierte Frame-Abfrage verwenden. AssumeFPS() und ConvertTo...() werden von Multithreading nicht beschleunigt. Aber Skalierungsfunktionen sollten im Modus 2 schneller laufen. Ob dann aber NLMeansCL2() im Modus 2 noch fehlerfrei funktioniert, müsste getestet werden.

Selur

Code

AVISource("A:\Tutorial\Vergleiche\Aufnahme\SamHD_2015_01_08_21_27_03_621.avi", audio=false).AssumeFPS(60,1).Spline100Resize(3200,1800).ConvertToYV24()
NLMeansCL2(last, 4, 4, 2, 2, 1, 1, 1.0, 1.8, true, "GPU", 3, 2, 2, false, false, true)

Mal drüber nach gedacht, erst zu filtern und dann zu resizen?
Warum YV24? (Denke das soll später zu YouTube hochgeladen werden, da wird dann doch am Ende eh wieder nach Yv12 gewandelt.)

GelberDrache

Sollte eigentlich gemacht werden...
Wie muss es denn angeordnet werden damit erst der Filter angeht und dann der Resizer...

Ja Youtube nutzt am Ende YV12, aber da Youtube ja selber bei Encod noch Resizer nutzt profitieren diese dann vom höheren Farbraum

LigH

Zitat von GelberDrache

Wie muss es denn angeordnet werden damit erst der Filter angeht und dann der Resizer...

Man schreibt die Filter in der Reihenfolge, in der sie abgearbeitet werden sollen.

PHP

SetMTMode(5,5) # bedeutet: MT-Modus 5, maximal 5 Threads
AVISource("A:\Tutorial\Vergleiche\Aufnahme\SamHD_2015_01_08_21_27_03_621.avi", audio=false)
Preroll() # ein paar Frames gleich beim Einlesen cachen
AssumeFPS(60,1)
ConvertToYV24()
# ob wohl MT-Modus 5 für NLMeansCL2 das Optimum ist? Vielleicht geht es schneller in einem anderen Modus. Vielleicht stürzt er damit aber auch ab...
NLMeansCL2(last, 4, 4, 2, 2, 1, 1, 1.0, 1.8, true, "GPU", 3, 2, 2, false, false, true)
SetMTMode(2) # für den Resizer wechseln wir mal den Modus
Spline100Resize(3200,1800)

Zitat von GelberDrache

Ja Youtube nutzt am Ende YV12, aber da Youtube ja selber bei Encod noch Resizer nutzt profitieren diese dann vom höheren Farbraum

Ob das auffällt, bezweifle ich. Aber ich vergleiche gern.

Selur

Zitat

da Youtube ja selber bei Encod noch Resizer nutzt profitieren diese dann vom höheren Farbraum

Wer behauptet den das?
Das letzte mal als ich mich damit beschäftigt habe, hat YouTube ffmpeg zum Encoden verwendet.
-> Die Umwandlung macht meiner Ansicht nach 0-Sinn.
(und wenn man wie LigH es gezeigt hat erst am Ende resized sollte auch der Avisynth-Teil wesentlich flotter laufen)

GelberDrache

Oh man LigH
Sorry deine Antwort hatte ich total übersehen o.o
Vergleichen tue ich auch sehr gerne deswegen bin ich gerade über 400 GB am hochladen auf Youtube um mal genau vergleichen zu können was wie sich genau auf die Qualität auswirkt xD

Selur
Die Aufnahme liegt ja schon in RGB24 vor.
Zudem nutzt Youtube auch schon lange denn x264 als Encoder.

Das ConvertToYV24 ist wegen dem NLMeansCL2, da es kein RGB24 kann.
Dann habe ich noch vor dem Spline 100 einen ConvertToRGB24(), da es ansonsten zu Farbfehler kommt.
Hier wäre eine direkte Aufnahme mit MagicYUV in YV24 besser, da der Farbraum dann eigentlich auch von Spline 100 richtig erkannt werden sollte.

Zudem würde mich mal interessieren was genau der NLMeansCL2, da sind wir nicht so genau bisher hinter gekommen.

PHP

LoadPlugin("C:\Program Files (x86)\SagaraS Scriptmaker\Plugins\SplineResize.dll")
LoadPlugin("C:\Windows\System32\NLMeansCL2.dll")
SetMTMode(5,5) # bedeutet: MT-Modus 5, maximal 5 Threads
AVISource("A:\Tutorial\Vergleiche\Aufnahme\SamHD_2015_01_08_21_27_03_621.avi", audio=false)AssumeFPS(60,1)
ConvertToYV24() # weil NLMeansCL2 kein RGB24 kann
NLMeansCL2(last, 4, 4, 2, 2, 1, 1, 1.0, 1.8, true, "GPU", 3, 2, 2, false, false, true)
ConvertToRGB24() # Spline100 hat bei YV24 Farbfehler
SetMTMode(2) # für den Resizer wechseln wir mal den Modus
Spline100Resize(3200,1800)

LigH

Du konvertierst also von RGB24 nach YV24 (Rundungsfehler + Breichsbegrenzung) und wieder zurück nach RGB24 (Rundungsfehler), und x264 konvertiert dann beim Encodieren nach YV12 (außer du hast in der x264-Kommandozeile mit speziellen Parametern angegeben, dass feineres Chroma-Subsampling verwendet werden soll). YouTube konvertiert dann das hochgeladene Video noch mal in verschiedene Formate, jeweils meist auf Basis von YV12 (Chroma-Subsampling YUV 4:2:0).

Was hast du nun erreicht, gegenüber einer kompletten Verarbeitung in YV12?

GelberDrache

Was hast du nun erreicht, gegenüber einer kompletten Verarbeitung in YV12?
Das die Resizer und Filter mit einem höheren Farbraum arbeiten können.
Da die Ausgabe von MeGui auch noch --output-csp "i444" ist, wird das Video auch noch in YV24 auf Youtube hochgeladen und da profitieren dann die Resizer von Youtube auch noch mal von.

Zudem ist das hier jetzt eher ein Testlauf um zu gucken ob sich der Weg über die GPU für die Geschwindigkeit lohnt.
Was er bisher leider noch nicht tut.

Als normales Skript wird das verwendet.
Dieses Skript wird über das Programm SagaraS Scriptmaker erzeugt:
http://www.letsplayforum.de/index.php/Thre…criptmaker-GUI/

PHP

### SagaraS Scriptmaker - Version 5.6 ###
### Lade Plugins und setze die globalen Variablen ###
LoadPlugin("C:\Program Files (x86)\SagaraS Scriptmaker\Plugins\SplineResize.dll")
LoadPlugin("C:\Program Files (x86)\SagaraS Scriptmaker\Plugins\blockbuster.dll") # wird in selten Fällen genutzt um die Komplexität weiter zu reduzieren, wenn Motion Blur nicht ausgereicht hat
LoadPlugin("C:\Program Files (x86)\SagaraS Scriptmaker\Plugins\mvtools2.dll")
Global breite = 3200
Global hoehe = 1800
Global AR = 0
### Lade Videoquellen ###
SetMTMode(6,4) # 6,4 wird genutzte wenn Motion Blur und Motion Blur + Blockbuster genutzt werden. Sollte nur der Resizer arbeiten haben wir hier eine 3,4
AVIload("A:\Tutorial\Vergleiche\Aufnahme\SamHD_2015_01_08_21_27_03_621.avi", 0, 0, 0, -0, -0, "Auto", "Auto", 0, 0)
### Filter Verarbeitungszone ###
SetMTMode(2)
sum = MSuper(pel = 2)
MFlowBlur(sum, MAnalyse(sum, isb = true), MAnalyse(sum, isb = false), blur = 5.0)


Blockbuster("Blur", Block_size=4, Detail_min=75, Detail_max=100, Luma_offset=0, Luma_threshold=25, Strength=5)


### Funktion für Video-Laderoutine ###
Function AVIload (String file, int loading, int cl, int co, int cr, int cu, string pixtype, string afps, int fpsn, int fpsd) {
    (loading == 1) ? FFIndex(file) : nop()
    clip0 = (loading == 3) ? LWLibavVideoSource(file) : (loading == 2) ? Import(file).KillAudio() : (loading == 1) ? FFVideoSource(file, threads=1) : (pixtype == "Auto") ? AVISource(file, false).KillAudio() : AVISource(file, false, pixel_type=pixtype).KillAudio()
    clip1 = clip0.AutoFPS(afps, fpsn, fpsd).Cropping(cl, co, cr, cu)    
Return (clip1.width == breite && clip1.height == hoehe) ? clip1.ConvertToYV24(matrix = "Rec709", ChromaResample = "Spline16") :  Clip1.Resize()
}


Function AutoFPS (Clip clip0, string afps, int fpsn, int fpsd) {
    rate1 = (afps == "Auto") ? (Round(Float(clip0.framerate * 1000)) / 1000) / 2 : nop()
   rate2 = (afps == "Auto") ? Round(clip0.framerate) / 2 : nop()
    rate = (afps == "Auto") ? (rate1 == rate2) ? 1 : 1001 : (afps == "Igno.") ? clip0.frameratedenominator : fpsd
    ratefaktor = (afps == "Auto") ? (rate == 1001) ? 1000 : 1 : nop()
    clip0 = (afps == "Auto") ? (rate == 1001) ? clip0.AssumeFPS(Round(clip0.Framerate) * 1000, rate) : clip0.AssumeFPS(round(clip0.framerate), rate) : (afps == "Igno.") ? clip0.AssumeFPS(clip0.frameratenumerator, rate) : clip0.AssumeFPS(fpsn, rate)
    Return clip0.ChangeFPS(30, 1)
}


Function Cropping (Clip clip0, int cl, int co, int cr, int cu) {
    clip0 = (clip0.IsRGB32() == True) ? clip0.ConvertToRGB24() : clip0
    Return (cl != 0 || co != 0 || cr != 0 || cu != 0) ? clip0.Crop(cl, co, cr, cu) : clip0
}


Function Resize (Clip clip1) {
    clip1 = (AR == 1) ? ((float(Clip1.height * breite) / clip1.width) / 2 == round((float(Clip1.height * breite) / clip1.width) / 2)) ? ((float(Clip1.width * hoehe) / clip1.height) / 2 == round((float(Clip1.width * hoehe) / clip1.height) / 2)) ? clip1 : clip1.ConvertToRGB24(matrix = "Rec709") : clip1.ConvertToRGB24(matrix = "Rec709") : clip1
    clip1 = (AR == 1) ? (((clip1.width * hoehe) / clip1.height > breite) ? Clip1.Spline100Resize(breite, ceil(float(Clip1.height * breite) / clip1.width)) : Clip1.Spline100Resize(ceil(float(clip1.width * hoehe) / clip1.height), hoehe)) : clip1.Spline100Resize(breite, hoehe).ConvertToYV24(matrix = "Rec709", ChromaResample = "Spline16")
    back = (AR == 1) ? (0 == 1) ? ImageReader("", 0, clip1.framecount - 1, clip1.framerate).ChangeFPS(Clip1.frameratenumerator, Clip1.frameratedenominator).Spline100Resize(breite, hoehe).ConvertToYV24(matrix = "Rec709", ChromaResample = "Spline16") : BlankClip(clip1, width = breite, height = hoehe, pixel_type = "YV24").KillAudio() : clip1
    Return (AR == 1) ? Overlay(back, clip1, (back.width - clip1.width) / 2, (back.height - clip1.height) / 2).ConvertToYV24(matrix = "Rec709", ChromaResample = "Spline16") : clip1
}

Alles anzeigen

Selur

Zitat

Zudem nutzt Youtube auch schon lange denn x264 als Encoder.

Mittels ffmpeg wird die libx264 Bibliothek verwendet.
+ Resizing&Co wird selbst im normalen x264 über libav gemacht.
-> Wenn du glaubst, dass das mit YV24 besser ist und damit glücklich bist ist das okay.
(Auch wenn ich der Ansicht bin, dass es verschwendeter Rechenaufwand ist, der qualitativ keinen Vorteil bringt. )

GelberDrache

Zitat von Selur

-> Wenn du glaubst, dass das mit YV24 besser ist und damit glücklich bist ist das okay.
(Auch wenn ich der Ansicht bin, dass es verschwendeter Rechenaufwand ist, der qualitativ keinen Vorteil bringt. )

[TABLE='width: 300']

[tr]

[TD='align: center']

BeforeResize

[/TD]
[TD='align: center']

AfterResize

[/TD]

[/tr][tr]

[TD='align: center']04. YV12.png[/TD]
[TD='align: center']04. YV12.png[/TD]

[/tr]

[/TABLE]

Es sind beide am Ende YV12...
Welches ist besser?

LigH

Gut, das ist bei Computergrafiken eben der Grenzfall, dass es auch extrem satte Farben mit harten Kanten gibt, anders als in der Natur. Hier kann eine Verarbeitung mit feinem Chroma-Subsampling schon interessant sein. Aber ... auch nur in Grenzen. Wenn dein ehemals auf 3200x1800 hochgezüchtetes Video wieder auf 640x360 herunterskaliert wird, um dann mit YUV 4:2:0 in H.263 komprimiert zu werden, ist der Vorteil im Eimer.

GelberDrache

Zitat von LigH

Gut, das ist bei Computergrafiken eben der Grenzfall, dass es auch extrem satte Farben mit harten Kanten gibt, anders als in der Natur. Hier kann eine Verarbeitung mit feinem Chroma-Subsampling schon interessant sein. Aber ... auch nur in Grenzen. Wenn dein ehemals auf 3200x1800 hochgezüchtetes Video wieder auf 640x360 herunterskaliert wird, um dann mit YUV 4:2:0 in H.263 komprimiert zu werden, ist der Vorteil im Eimer.

Naja man muss halt sagen das die 360p Stufe nicht wirklich interessiert xD
Wenn es um Qualität auf Youtube geht kann man selbst du 1080p Stufe in die Tonne treten...
Und wenn ich von 1800p auf 1440p runter gehe bleibt schon mal mehr über wenn es in YV24 hochgeladen ist.
Zudem ja von dem höheren Farbraum ja auch schon meine Resizer profitiert...

SagaraS

Wenn das Chroma-Subsampling bei Computergrafiken erst nach dem Resize passiert ist das Ergebnis damit besser, als wenn es davor passiert.
RGB Aufnahme -> Up Resize -> YV12 | Langsamer, aber besseres Bild
RGB Aufnahme -> YV12 -> Up Resize | Schneller, aber schlechteres Bild

So nach dem Beitrag #16 von GelberDrache.

Ich denke da es sich um Let's Play's handelt und sogut wie jedes Spiel eine RGB Quelle ist, spricht das Ergebnis für sich was das bessere Bild liefert.

Jedoch wird er MeGUI noch nutzen und somit den x264 und womöglich dazu noch den 10Bit Encoder davon.
Und soweit ich mich erinnere kann die Pipeline avsx264mod nur YV24, YV16 und YV12

Also müsste sein ganzer Ablauf so aussehen:
RGB Aufnahme -> Resize -> YV24 -> Pipeline -> x264 10Bit mit --output-csp i444 -> fertiges Video

Wenn jetzt YT auch zuerst skalieren sollte, statt zuerst ein Chroma-Subsampling durchzuführen, wäre das auch für alle unteren Auflösungsstufen ein reiner Vorteil für solche Computergrafiken.

Ich denke eindeutig sieht man sowas an einem Beispiel.

Hier hab ich mal als Beispiel mit RGB aufgenommen in 240x200. Dann hochskaliert und dann mit x264 8Bit in YV24 + RGB Matrix konvertiert und encodiert. Das ganze dann auf YT halt hochgeladen und das hier ist halt dann das Ergebnis:
https://www.youtube.com/watch?v=o4pYR90mtKM

Zuvor hatte ich es so das ich es in YV12 konvertiert hatte und dann hochskaliert habe. Allerdings war das Ergebnis unter aller Sau Aber so wie das Video da auf YT jetzt, sieht sogar die 1080p und 1440p Stufe schön sauber aus. Obwohl es sich um eine 240x200 Quelle gehandelt hatte.

LigH

Nachteil der ganzen Angelegenheit ist natürlich eine geradezu irrsinnige Verschwendung von Upload-Bandbreite. Aber wenn's schee macht...

Was mir irgendwie immer noch fehlt, ist eine klar definierte Ausgangslage. Bei welcher Auflösung beginnen wir denn hier? MS-DOS-Spiele in Standard-VGA-Auflösung?

Wenn ja, wäre PointResize() "das schärfste, was Ihre Majestät zu bieten hat" (entschuldigt den kleinen DiNozzo am frühen Morgen). ;D — aber woher käme dann das Rauschen, dass man mit NLMeans glätten wollte? Oder wofür sei das dann gut?

Wenn nicht, könnte man alternativ auch darüber nachdenken, mit NNEDI3_rpow2 die Bildfläche mit "Edge Directed Interpolation" aufzublasen, für schöne Kanten, und danach auf das gewünschte Ziel zu verkleinern.

Aber von GPU-Unterstützung führt das dann eher noch weiter weg.

Jetzt mitmachen!