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

  • In einem einzelnen Screenshot wird man aber das mögliche Aliasing dann nicht bemerken (also das Flackern, wenn hier und da mal aus einem Original-Pixel nach der Vergrößerung zwei nebeneinander werden, aber nicht überall flächendeckend gleich...); gezackte Kanten und links oben die bröseligen Zahlen merkt man aber schon direkt.

    Ich habe das PointResize nur für den Fall erwähnt, dass jemand so was niedriges wie VGA-Auflösung mit limitierter Farbpalette erst mal auf ganzzahlige Vielfache vergrößern möchte. Das passt bei DOS-Games, aber bei HD-Action würde es mich überraschen. Nun ja. Hier überrascht mich schon einiges... ;)

  • Der Point wahr halt schon vorher bei uns auf der Liste :D

    Deswegen meine ich ja auch das wird auf denn Testvideos warten müssen, da einfach auf Youtube der Wichtigste Faktor die Komprimierbarkeit ist...
    Und das ist hier sogar besser gegeben als bei Spline100 o.o

    Wenn es gut läuft ist das Video des Nearest Neightbour um 21 Uhr auf Youtube

  • Ok alles zurück, kann vergessen werden...
    Der Nearest Neightbour war nur durch denn qp=0 kleiner...
    Sobald aber Kompression in Spiel kommt ist Spline100 deutlich kleiner fast 50% bei crf 18...

    Schade :(

  • Klar: Dadurch, dass PointResize beim Upscaling Pixel teilweise exakt vervielfacht, können verlustlose Verfahren eine Differenz von 0 zu manchen Nachbarpixeln leichter komprimieren als größere Differenzen.

    Verlustbehaftete Verfahren dagegen wandeln meist in Frequenzspektren um, und die verzweifeln an den harten Kanten, die sich daraus ergeben.

  • Tja das heißt dann wohl keine Chance für ein schnelleres Skript...
    Und leider auch keine Chance für einen besseren Resizer...

    Schade...

    Und ich persönlich warte noch auf eine Erklärung zu diesem Satz ;)

    Ich glaube, so langsam fange ich an zu erahnen, das ihr da vorhabt. Und je länger ich mir das vorstelle, umso weniger gefällt es mir...

  • ^ So was wie "Simplify" in DAP: Objekte radikal abstrahieren, dabei auch Details rausfiltern.

    Und was die Chancen angeht: Doch, schon; Beispiele hab ich noch nicht, aber es wurde ja schon darauf hingewiesen, dass MFlowFPS um Größenordnungen langsamer als jeder Skalierer sein wird. Die eigentliche Bremse ist also ein anderer Filter, nicht der Resizer.

  • Und was die Chancen angeht: Doch, schon; Beispiele hab ich noch nicht, aber es wurde ja schon darauf hingewiesen, dass MFlowFPS um Größenordnungen langsamer als jeder Skalierer sein wird. Die eigentliche Bremse ist also ein anderer Filter, nicht der Resizer.

    1. MFlowFPS wird aber deutlich weniger verwendet als der Resizer, zudem wird MFlowFPS nur dann verwendet wenn man schon auf 1800p ist.
    2. Von 720p auf 1800p gehe ich von 25.22 Fps auf 4.87 Fps, aber wenn ich von 720p auf 1800p + MFlowFPS gehe habe ich noch 3,54 Fps...
    - Das heißt alleine durch denn Resizer verliere ich 80,7% Leistung, aber durch MFlowFPS verliere ich gerade mal weiter 27,31% Leistung (vergleich 1800p und 1800p + MB)
    --Aber es ist klar je höher die Grundauflösung ist umso weniger verliere ich durch denn Resizer...

    Edit:
    Bei 720p + MB = 21,55 Fps

    Einmal editiert, zuletzt von GelberDrache (14. Januar 2015 um 03:38)

  • Wenn ich einen Filter im Skript sehe, wird der verwendet (sofern die Skript-Struktur nicht den "execution path" drum herum führt).

    Woher soll ich wissen, dass die GUI auch andere Skripte generieren könnte, die ich hier aber nicht im Quelltext vor mir sehe? Ich sehe in dem einen Skript, dass MFlowFPS verwendet wird, also wird es ausgeführt und ist höchstwahrscheinlich langsamer als der Skalierer.

    Wenn du jetzt wieder über ein anderes "meistverwendetes" Skript reden willst, dann zeig mir das.

    Und außerdem hast du einen grundlegenden Denkfehler: Dass es 5x langsamer wird, liegt nicht daran, dass der Skalierer 80% der Rechenleistung verbrät, sondern dass du 6,25 Mal so viele Pixel hast, die encodiert werden müssen. Egal welchen Skalierer du verwendest. Dessen Rechenaufwand ist verschwindend gering im Vergleich zum Encoder. Benchmarks des Skriptes alleine macht man mit avsmeter, nicht mit x264.

    1280×720 = 912.600
    3200×1800 = 5.760.000

  • So sieht das Grundskript aus...
    Jetzt kann über die GUI entschieden werden was noch alles in das Skript rein soll...
    In jedem Bereich der GUI kann man dann wieder einiges Einstellen, was ins Skript Hinzugefügt wird...
    Im Ordner vom SSM lassen sich dann auch noch solche Sachen finden:
    http://www.mediafire.com/download/gwudkd016wi3vao/Blend.avsi

    Video:
    Verwendete Videos, Crop, Fps ändern, Pixel Type, Fadein, Fadeout, Cut, Übergänge, FFMS2, L-Smahs, Assume FPS...

    Auflösung:
    Einstellung der Auflösung (Pixel genau), Seitenverhältnis beibehalten, Hintergrundbild verwenden, Resizer (Spline 16, 36, 64, 100, 144, Nearest Neightbour, Lanczos 2 + 4), Resizer Plugins (ResampleHQ + nnedi3 (rpow2)

    Farben:
    Farbraum Konvertierung, Farbmatrix (wenn ResampleHQ genutzt wird), Chroma (UV) - Resample, Tweak (only YUV), Levels, ColorMatrix (only YUY2, YV12)

    Sonstiges:
    Multithreading, Blockbuster (only YUV), Motion Blur (only YUV), Speicher Zufallsbilder, Video Info, VFR -> CFR, Untertitel, Wasserzeichen

    Und das ist das was schon alleine in der GUI vorhanden ist...

  • Für die Funktionen würde ich glatt noch das Auslagern in eine *.avsi für den Import() empfehlen. So kann man vielleicht mehrere Funktionen mit dem gleichen Namen in verschiedenen Import-Skripten vorgeben und je nach GUI-Auswahl das dazu passende Importskript einbinden, so dass im Hauptskript immer eine Funktion mit dem gleichen Namen aufgerufen wird, aber je nach importiertem Skript was anderes tut.

    Und die Übergabe der hier globalen Konstanten an Resize als Parameter, anstatt sie als Globals zu verwenden. Aber das ist vielleicht Ansichtssache, nicht zwingend.

    Ansonsten, zusammengefasst: Hauptgrund für die Verlangsamung ist, dass der Encoder für mehr Bildfläche mehr Zeit braucht. Mit welcher Funktion die größere Bildfläche erzeugt wird, hat im Vergleich zum Encodier-Aufwand so gut wie keinen Einfluss.

  • Das heißt unsere Hauptproblem ist nicht das Skript an sich, sondern die Auflösung die wir wegen Youtube brauchen...
    Da geht einen Youtube ja noch mehr aufen Zeiger xD
    Also gibt es momentan keine wirkliche Chance mehr Geschwindigkeit raus zu bekommen, außer der x264 sollte auf einmal deutlich schneller arbeiten xD
    Das heißt dann aber auch wieder das weitere Filter genutzt werden können, um die Komprimierbarkeit zu verbessern, ohne das die Fps drastisch in denn Keller gehen...
    Das ist doch schon mal was feines ;)

  • Nun ja, es ist sicher nicht so, dass Filter vergleichsweise keine Zeit brauchen; je größer die Bildfläche, umso mehr Zeit brauchen auch die Filter. Aber wie stark der Einfluss ist ... wie geschrieben, solche Verhältnisse bestimmt man zuverlässiger mit avsmeter, weil das mit der Videoquelle des Skriptes nichts mehr macht.

    Und den Encoder x264 kann man bei dem Ziel, besser hohe Qualität als kleinen Upload zu erzeugen, auch mal mit schnellerem Preset laufen lassen.

  • Und den Encoder x264 kann man bei dem Ziel, besser hohe Qualität als kleinen Upload zu erzeugen, auch mal mit schnellerem Preset laufen lassen.

    Da brauchte ich dann mal eine genau Erklärung, weil bisher heißt es das das Preset auch Einfluss auf die Qualität des Videos hat.
    Also nicht nur auf Dateingröße und Zeit...

  • Ich hab hier mal was gefunden...
    Ist zwar wieder dann eher einen Sonderfall, aber hei schon mal etwas ;)

    nnedi3 - OpenCl
    http://forum.doom9.org/showthread.php?t=169766

    Skript bisher:

    So das müsste man jetzt noch verbessern...
    Also mit MT...
    Wenn man ihm jetzt noch sagen könnte welche GPU er nutzen soll...
    Oh man das wäre das Teil genial...
    Gegenüber denn normalen nnedi3 hatte ich fast die 3 fache Fps

    4 Mal editiert, zuletzt von LigH (14. Januar 2015 um 11:47)

  • ^ Du hast da ein paar Zeilenumbrüche vergessen, die hab ich mal eingefügt.

    Was ich bei deiner Herumkonvertiererei recht bedenklich finde, ist das hin-und-her zwischen RGB24 und YV24: Kostet einerseits Rechenzeit und verschlechtert andererseits auch noch die Qualität durch Rundungsfehler (allerdings nur in der Größenordnung "lsb").

    Wenn Spline100Resize in YV24 fehlerhaft arbeitet, sollte das wohl mal mit den Entwicklern besprochen werden; vorher sollte man aber noch mal überlegen, ob es vielleicht nur dann korrekt arbeitet, wenn der Ausgangsclip bestimmte Voraussetzungen erfüllt (z.B. Höhe/Breite min. teilbar durch...).

  • Ich frag mich nur gerade warum ich nicht auf die Geschwindigkeit komme wenn ich nur Spline 100 nutze...
    Der komplette Resize läuft über die GPU... nnedi3 hatte ja noch Spline 16 drin und somit konnte ich dann noch denn Rest von 1440p auf 1800p machen...
    Die GPU läuft nicht auf 100%, sondern die CPU...

    Mh... irgendwie gibt es noch Dinge von denen ich keine Ahnung habe xD

    De-M-oN
    Schon in YV24 aufgenommen?

  • Ich frag mich nur gerade warum ich nicht auf die Geschwindigkeit komme wenn ich nur Spline 100 nutze...
    Der komplette Resize läuft über die GPU... nnedi3 hatte ja noch Spline 16 drin und somit konnte ich dann noch denn Rest von 1440p auf 1800p machen...
    Die GPU läuft nicht auf 100%, sondern die CPU...


    Mh... irgendwie gibt es noch Dinge von denen ich keine Ahnung habe xD


    Da brauchte ich dann mal eine genau Erklärung, weil bisher heißt es das das Preset auch Einfluss auf die Qualität des Videos hat.
    Also nicht nur auf Dateingröße und Zeit...

    Dazu bräuchte ich mal eine Erklärung noch ;D

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!