MeGUI [2015] -- x264 - bester Encoder, beste Videoqualität auf Youtube ;-)

Und der Filter FadeIO2 ist auch falsch angegeben. Das Ding hat kein FPS Argument.

Sondern besteht ledeglich aus (Clip Video, int frames, int color)

Das Video Clip wird über die Vererbung von AVISource schon gesetzt. Standardfarbe ist immer Schwarz, wenn diese nicht angegeben wird. Sprich $000000
Und die Frames geben an wie lange das Faden dauern soll. Wirken tuhen die Fadeelemente des Standard [lexicon]AVISynth[/lexicon] nur am Anfang des Clips und am Ende des Clips. Wird danach getrimt, wirste nicht mal sehen das da gefadet wird.

MPEG2Source erfordert glaub ich auch ein Plugin wenn ich mich nicht irre. Aber mit L-Smash kannste das sehr gut laden und das sollte sogar in [lexicon]MeGUI[/lexicon] mit dabei sein.

LoadPlugin("D:\[lexicon]MeGUI[/lexicon]\tools\lsmash\LSMASHSource.dll")
LWLibavVideoSource("D:\Test.mpg")
AudioDub(LWLibavAudioSource("D:\Test.mpg"))

Zitat von De-M-oN

[lexicon]avisynth[/lexicon].nl/index.php/Fade

doch hat es. Er geht sonst von 24fps aus. edit: achso weiter unten steht bei videostream ignoriert. Naja gut das mag sein.^^

Für Audio interessant und durchaus dann verfügbar. Bei Videos halt nicht. Aber steht ja da.

Zitat

Der Parameter fps ist optional, default = 24,0, und bietet eine Referenz für num_frames nur in Audio-Clips (kein Video). Es wird ignoriert, wenn ein Videostream vorhanden ist.

Bedeutet das es für Videos total Sinnbefreit ist.

Zitat von mysteryworldlp

und jetzt habe ich nur noch mit "videos doesn´t match", aber die sollte man ja finden können.

Das bedeutet das die Clips nicht übereinstimmen. Jetzt musst du eines der Clips den anderen angleichen, sodass beide Identisch sind.

ChangeFPS - Für die FPS Angleichung
Resizer - Für die Größenangleichung
SSRC - Für die Sampleratenangleichung
ConvertAudioTo16bit() - Audio Bit Angleichung in 16 Bit

Das hier kannste nehmen für eine Mono to Stereo Angleichung oder umgekehrt

Function StereoChannel(clip audio) {
    Try { return audio.GetChannel(1,2) }
    Catch (Error_2) { Return audio.GetChannel(1,1) }
}


Function MonoChannel(clip audio) {
    Try { return Mixaudio(audio.GetChannel(1),audio.GetChannel(2)) }
    Catch (Error_1) { Return audio.GetChannel(1) }
}

Und Farbraum musste mal schauen. Ansonsten Standardfilter fürs Ändern: ConvertToRGB24() oder ConvertToYV12() oder ConvertToYUY2() etc...

Ich bin gerade etwas überfragt. Ich encode im Moment so:

• AVS-Script mit [lexicon]SSM[/lexicon] erstellen, dabei von 1600x900 auf 3200x1800 skalieren, [lexicon]Blur[/lexicon], [lexicon]Blockbuster[/lexicon], MT
• Audio mit [lexicon]SSM[/lexicon] anpassen
• AVS-Script in [lexicon]MeGUI[/lexicon] und mit Preset Medium und [lexicon]CRF[/lexicon] 23 encoden

Das ist so um groben mein Encoding. Jetzt hätte ich gerne eine verkürzte Encodingzeit bei gleichbleibender (oder vllt sogar besserer?) Qualität. Die Dateien können und werden dann natürlich größer. Jetzt frage ich mich nur, auf welches Preset ich da am besten gehe und in wie weit ich die [lexicon]CRF[/lexicon] anpassen muss um gleiche Quali zu behalten. Oder wird das ganze dann wieder nicht schneller da das Preset zwar schneller ist dafür aber [lexicon]CRF[/lexicon] besser?

Zitat von Dr_Cox1911

Ich bin gerade etwas überfragt. Ich encode im Moment so:

• AVS-Script mit [lexicon]SSM[/lexicon] erstellen, dabei von 1600x900 auf 3200x1800 skalieren, [lexicon]Blur[/lexicon], [lexicon]Blockbuster[/lexicon], MT
• Audio mit [lexicon]SSM[/lexicon] anpassen
• AVS-Script in [lexicon]MeGUI[/lexicon] und mit Preset Medium und [lexicon]CRF[/lexicon] 23 encoden

Das ist so um groben mein Encoding. Jetzt hätte ich gerne eine verkürzte Encodingzeit bei gleichbleibender (oder vllt sogar besserer?) Qualität. Die Dateien können und werden dann natürlich größer. Jetzt frage ich mich nur, auf welches Preset ich da am besten gehe und in wie weit ich die [lexicon]CRF[/lexicon] anpassen muss um gleiche Quali zu behalten. Oder wird das ganze dann wieder nicht schneller da das Preset zwar schneller ist dafür aber [lexicon]CRF[/lexicon] besser?

Da hilft nur ausprobieren
Ist ja auch je nach Vidematerial anders.

Und es kommt drauf an wie wenig Qualität du noch ertragen kannst.
Die Geschwindigkeit hängt von der komplexität des Materials ab, welchen Skalierungsfilter du verwendest vorallem auf welche [lexicon]Auflösung[/lexicon] du encodierst (ist ja schon mehr als das doppelte bei dir) und natürlich das Preset (Medium, Slow usw.).
Normalerweise sollte sich beim [lexicon]CRF[/lexicon] nicht die Geschwindigkeit verändern.

Naja, [lexicon]CRF[/lexicon] hat ja schon eine Auswirkung auf die Encoding-Zeit. Je niedriger, desto länger dauert es doch oder liege ich da falsch? Das war zumindest bisher meine Auffassung. Im Moment ist verhält es sich bei mir so: für 20 Minute Aufnahme braucht mein Rechner (Core i7 2600k mit MT 2) fast 3 Stunden.

Mit meinen 10Mbit upload könnte ich aber auch größere Dateien relativ unproblematisch hochladen.

EDIT: Sorry, während ich hier geschrieben habe ist die Antwort von Demon reingeprasselt. OK, also hat [lexicon]CRF[/lexicon] wirklich nur minimalen Einfluss auf die Zeit. Danke für die Info! Werde es mal ohne [lexicon]Blockbuster[/lexicon] versuchen.
MT habe ich auf 2 Threads, Mode 3 bei Source und Mode 2 bei Tweak. Begrenzt auf 512MB. Bei mehr Threads hatte ich hin und wieder abstürze bei 99%.

EDIT2: Und ResampleHQ hab ich auch noch drin, ganz vergessen zu erwähnen.

10 Quellen hatte ich bisher nie, maximal waren es 4. Könnte ich dann deiner Meinung nach wieder auf 4 Threads gehen? Ich weiß, dass die MT-Einstellungen immer sehr komisch sind und von PC zu PC unterschiedlich gut laufen. Inzwischen wär die Diskussion wahrscheinlich im [lexicon]SSM[/lexicon]-Thread besser aufgehoben. Dachte zu Beginn ich könnte da in [lexicon]MeGUI[/lexicon] mehr optimieren.

Kurzer Test ist im Moment sehr vielversprechend. Mit 4 Threads sagt er 1:20 Stunden. Das wäre deutlich besser (und auch schonender für die Stromrechnung )