Beiträge von De-M-oN

    @N3rdTim3: Deine Samplerate vom [lexicon]FRAPS[/lexicon] ist 48khz, deine vorbis 44,1khz. Kann da vllt der Wurm liegen? Sorge dafür das du in 44,1khz alles aufnimmst und encodierst. Dann solltes auch keine Seelsorgen hierbei geben.


    Zitat

    Viielleiicht holt YouTube ja doch wieder 1440p zurück, ich hoffe es, jedenfalls solange ich es nicht hinkriege :S :D


    Glaub ich nicht. Die 2048er und 2560er rutschen auf die 1080er. Gibt dann keine 1920x1080 version mehr, sondern hast eine 1080er qualistufe die aber dann 2048x1152 zb hat. Vllt auch mit der [lexicon]Bitrate[/lexicon] des "original" encodes. Kommt mir aber echt so vor, das es so ist, denn bei Honkis Turok 2 LP wo die 2048er videos ebenfalls auf die 1080 gerutscht sind, sieht es mir schon eher nach der "original" version aus.

    Nö. Besser nicht. Und auch ineffizienter, da man immer eine ganze Programmversion abwarten muss, bis [lexicon]x264[/lexicon] von denen aktualisiert wird und einige [lexicon]x264[/lexicon] einstellungen, wie zb die max [lexicon]GOP[/lexicon] Länge etc, lassen sich nicht ganz so freiläufig einstellen, wie es eig. möglich wäre. Qualität wird aber mit [lexicon]CRF[/lexicon] oder [lexicon]Bitrate[/lexicon] (je nach dem was man nimmt) festgelegt. Effizienz Quality vs Filesize ist die Differenz.


    @CoRoriLP: Vorerst poste ich es halt nicht öffentlich, ich kann hier einfach damit bissl trumpfen und würde es daher auch ganz gerne im Moment. Später vllt. Aber erstmal möchte ich es gerne für mich behalten bzw nicht jedem Hans öffentlich posten.
    Also das hat auch gar nichts gegen dich/euch zu tun, sondern ist einfach derzeit meine persönliche Entscheidung.

    Du musst nicht jeden Parameter angeben. Nur das was du brauchst. Und die matrix von 601 ist demnach auch total verkehrt.


    SoftCubic würd ich meiden.


    Mal sehen, vllt schreib ich dir gleich eine PN. Wie Sagaras schon schrieb, möchte ich vorerst nicht meine gesamte Methodik absolut jedem zugänglich machen. Das müsste ich dann aber abgesehen von den weiteren Filter aber.


    Jedenfalls so wie du es momentan hast, kann ich dich auch nicht loslaufen lassen, das ist so nicht wirklich toll gerad.


    Achja der erste teil:


    nicht so:
    (clip,width=3200,height=1800


    sondern reicht so:


    (3200,1800,dstcolorspace[..........]

    Die internen Resizer sind ebenso MTMode(1) fähig.


    Du benötigst dafür aber Avisynth 2.6 Alpha 5 und eine modifizierte Avisynth.dll ( http://forum.doom9.org/showthread.php?t=148782 )


    Dann kann mit SetMTMode(1) Multithreading für den Resize benutzt werden.


    Code
    SetMTMode(1)
    Spline64Resize(2048,1152)


    Als ein simples Beispiel.


    Nicht jeder Filter ist Mode 1 fähig.


    Code
    * Mode 1 is the fastest but only works with a few filter
    * Mode 2 should work with most filters but uses more memory
    * Mode 3 should work with some of the filters that don't work with mode 2 but is slower
    * Mode 4 is a combination of mode 2 and 3 and should work with even more filter but is both slower and uses more memory
    * Mode 5 is slowest (slower than not using SetMTMode) but should work with all filters that don't require linear frameserving (that is, the frames come in order (frame 0,1,2 ... last)).
    * Mode 6 is a modified mode 5 that might be slightly faster


    Zitat

    Useful MT modes:
    1 - one filter instance per call in script, no guarding from Avisynth, only for filters that are designed for this mode, like distributor().
    3 - one filter instance per call in script, Avisynth guards requests for output. The mode to use with source filters. (Mode 5 will do for them too, but is overkill and should be avoided.)
    2 - each call in script produces N (number of threads) instances of filter. Use for the rest.


    When using MT mode with filters that have ability to spawn several internal processing threads - be sure to set such filters to use only 1 thread. Otherwise for example with 8-thread system MT mode will spawn 8 threads with once instance of such filter per thread (in MT mode 2), each filter instance will spawn 8 threads. End result: 64 threads (ouch).


    Achso zur Frage: So um die 4 bis 6 fps in etwa bei einem Resize auf 3200x1800. Benutze aber noch weitere Filter.

    Update abwarten. Geht zurzeit noch nicht. Bis dahin die Spuren einzeln extracten und mit zb [lexicon]Audacity[/lexicon] mischen (beide importieren, als neue [lexicon]WAV[/lexicon] exportieren und in den Audio Input von MeGUI)

    YV12 nehmen. Performanter und später beim Encode fällt die YV12 Konvertierung weg. Spart Zeit und Qualität.


    Zitat

    Ne frage, wenn ich Antialising aktiviert habe, welchen Filter sollte ich dann fürs Resizen vom Quellmaterial benutzen.


    Gute Resizer sind die [lexicon]Spline[/lexicon] und [lexicon]Lanczos[/lexicon] Resizer. Letztendlich isses Geschmackssache, Lanczos4 zb sehr scharf, aber auch Ringing Bildung. Weniger Schärfe = weniger ringing.

    Wenn p4x4 partitionen auch aktiviert sind, werden auch p-frames in 4x4 blöcke aufgeteilt. Kann die Kompression um 0,5% verbessern (0,5% laut MeGUI).


    b-frames bestimmt wieviele b-frames maximal aufeinanderfolgend stehen dürfen.


    Frametypen -> http://encodingwissen.de/grund…deokompression/interframe


    Zitat

    1. 431MB -> Mit BlockBuster, mit Spline100 Original Resize (auf 2048x1152)


    Das dies mit kleinster Dateigröße auskommt ist nicht verwunderlich, da Spline100 unscharf skaliert, dafür aber keine Probleme mit Ringing hat. Dazu noch die weitere Unschärfe durch Blockbuster.
    Lanczos4 skaliert sehr scharf und neigt halt auch sehr schnell zu Ringing Artefakte. Die Schärfe als auch die Ringing Artefakte sind durchaus beides Faktoren, was der Komprimierbarkeit nicht so sehr zugute kommt. Daher würd ich für Youtube auch kein [lexicon]Lanczos[/lexicon] 4 mehr empfehlen und ich sollte mal meine avisynth profile aktualisieren - bzw rate ich eh in Kürze die [lexicon]GUI[/lexicon] für Scripterstellung zu nehmen die Sagaras für uns macht und ich mit ihm das Ding teste und vorschläge mache.

    Max [lexicon]GOP[/lexicon] Infinite bringt bei beschissen komprimierbarem Material natürlich wenig - wenn ein Video schlecht komprimierbar ist, trifft das mehr oder weniger auf alle Kompressionstechniken zu. Ist doch klar ;)
    Max [lexicon]GOP[/lexicon] Infinite bringt am stärksten bei inkomplexem Material. Und da dann excessiv. Ebenso können dann auch andere Kompressionstechniken entsprechend mehr trumpfen. Bei inkomplexem Material bringt dann auch slow so richtig viel.
    Warum holst du das Thumbnail aus der komprimierten Datei? Nimm doch das [lexicon]Rohmaterial[/lexicon]. So rekomprimierst du nicht einen [lexicon]Frame[/lexicon] aus einer Verlustquelle nochmals (Artefakte vom Verlustmaterial verschlechtern die PNG Kompression ebenso wie es bei Video encodes der Fall ist - und yt benutzt schwere jpg kompression) Und nichts lässt sich schneller spulen als [lexicon]Rohmaterial[/lexicon] in virtualdub 32bit geöffnet ;D Daher versteh ich nicht, warum du die Verlustencodes dafür heranziehst, die sich auch mit Max [lexicon]GOP[/lexicon] 250 weit langsamer spulen lassen und dir keine optimale Quelle bieten.
    Aber wenn ihr schwer komprimierbares Material habt und mit der Dateigröße unzufrieden seid, gibt es nur 2 Möglichkeiten. A) Das Video in schlechterer Qualität encodieren, und/oder B) Dem Video Detail entziehen - zb eine leichte Unschärfe einbringen. Da kann man sogar Unschärfe nutzen die man (fast) nicht sieht, aber dem [lexicon]Encoder[/lexicon] erleichtert. -> Mit dem Filter Blockbuster geht sowas.


    Code
    Blockbuster(method="blur", detail_min=50, detail_max=100, strength=100, block_size=4)


    könntest du zb mal probieren.


    Blockbuster: http://killerinstinct.ath.cx:2000/files/blockbuster.dll


    Kommt in c:\Program Files (x86)\AviSynth 2.5\plugins\ (ausgehend davon das du in den Standardinstallationsordner Avisynth installiert hast)


    aq-strength 1.25 arbeitet der Adaptive Quantizer aggressiver und hilft entsprechend bei Kompression der Dunkelheit indem kleinere Quantizerfaktoren benutzt werden - die dunklen Stellen bekommen aber dann auch mehr Dateigröße, auch wenn es extrem minimal ist, da Dunkelheit eh nach wie vor excellent komprimiert werden kann. Dennoch ist aq-strength höher als 1.0 ja nicht dienlich für jemanden der eher kleinere Datei will ..
    partitions all würd ich nich machen, bringt bei schlecht komprimierbarem material voraussichtlich eher wenig, erhöht aber die Encodierzeit merklich.

    Das macht aber nur dann Sinn wenn mehrere Videos hintereinander gelegt werden


    Falsch. Das macht grundsätzlich Sinn!


    Youtube mag das nicht wenn die Spuren asynchrone Enden haben und macht die gerne asynchron. Bis zu ca 1sek hinterher hängenden Audio hab ich da schon erlebt. Und das war nicht ein [lexicon]Afterburner[/lexicon] Video. Will gar nicht wissen was youtube daraus dann macht.