Beiträge von De-M-oN

CUDA kannst du eher für die Filter benutzen, falls du welche einsetzt.

Aber CUDA kommt beim Encode eh nicht in Frage. Und x264 ist ein reiner CPU Encoder und das ist auch gut so.

CUDA ist LANGSAMER als CPU Encoding.

http://www.computerbase.de/for…php?p=9557413&postcount=9
http://www.computerbase.de/for…hp?p=9947207&postcount=46
http://www.computerbase.de/for…hp?p=9952783&postcount=52

Die Werbemasche das CUDA so schnell sei wird durch schlechte Kompressionseffizienz vorgegaukelt. Dann ist aber auch x264 schnell und das sogar deutlich schneller als GPU.

Hier mal die Kompressionseffizienz von CUDA.

Framegenau geht nur vor dem Encode.

Den GOP Maximum auf weniger als 250 Frames zu beschränken kann ich in keinsterweise empfehlen. Da geht viel zu viel Kompression drauf, wenn du dem Encoder so früh vollgespeicherte Frames aufzwingst.

___
MeGUI -> Tools -> AVS Cutter.

Zitat von iTzMeHeRo

Das bedeutet wenn ich in 1080p Rendern würde es also schneller gehen richtig?

Nein.

Die größeren Frames die x264 dann encodieren muss wiegen die Zeit des Filters 3x auf.

x264 muss dann 1920x1080 große Frames encodieren, statt 1280x720 Frames.

CRF 20 musste dich nicht wundern, wenn die Dateigröße anwachsen tut. CRF 20 nimmt man dann, wenn man auch das Internet dazu hat.

Mit CRF 20 hast du einen enormen Qualitätsanspruch. Und wenn das Material bisschen komplexer ist, kann auch x264 nicht hexen und benötigt mehr Datenrate bei deiner geforderten enorm hohen Qualität.

Von daher probiers mal mit größerem CRF.

Auch bitte bedenken das Youtubes 1080er Encode bei einem 720p Encode halt entfällt. Aber Youtube encodiert ja jede Datei in aufsteigend besserer Qualität und nicht bloß unterschiedliche Auflösungen.

Daher kann sogar ein CRF 25 Video auf Youtubes 1080p Encode besser aussehen, als ein CRF 21 720p Encode mit Youtubes 720p Datei.

Die Fehlermeldung kommt dann von einem DirectShow Decoder/Filter und nicht von MeGUI.

MeGUI trifft hier keine Schuld, sondern DirectShow.

Irgendn Filter/Decoder muss für AVI Dateien in dein DirectShow System gelangt sein.

Zitat

Hab nur mal eine Kurze Frage und zwar : Ist es normal das ich zum rendern von 16 Minuten ungefähr 45 mins brauche und diese datei dann 600-800mb groß sind ?

Du änderst die Auflösung. Das Umrechnen kostet CPU Aufwand. Der Lanczos4 Resize Filter ist ein sehr hochwertiger Resizefilter, braucht aber auch bisschen Zeit. Trotzdem geht es mit kleineren Frames viel schneller als mit großen.

Die CPU ist nicht die beste. und mit Preset Slow durchaus normale Zeit wenn das Material ein wenig schwerer komprimierbar ist.

Wie groß die Datei wird, wie lange die Encodierzeit ist, hängt von der Komprimierbarkeit des Materials, den Encodiereinstellungen, der geforderten Qualität (CRF Faktor) und deiner CPU Leistung ab.

Wenns dir zu groß wird, probier CRF 23. Immer noch zu groß? Probier CRF 25. Musst halt sehen was du an Kompromiss aus Videoqualität und Dateigröße eingehen willst.

Wenns dir zu lange dauert: Preset Medium probieren. Bei entsprechend schwer komprimierbarem Material, bringt slow weniger Kompressionseffizienz ein, als wo man gut komprimieren kann.
Bei schwächerer CPU kann es daher schonmal sinnvoll sein lieber medium zu nehmen, wenn man schwer komprimierbares Material hat und die Encodierzeit dann kürzer ist, und die paar mbytes mehr weniger Zeitaufwand zum Upload benötigen, als der Encode mit slow dauern würde.

öhmmm ok ...

Sehr seltsam.

Kannste mal die Log kopieren?

Könnte das vllt an einem Fremddecoder liegen? Sprich irgendwelche Filter mal installier gehabt oder so?

Um das zu testen probiere mal File Indexer, drück darauffolgend auf Queue und führe den idx Job mal durch und berichte ob der AVS Script Creator dann ohne der Meldung erscheint.

Zeig dann mal die vollständige Fehlermeldung.

Und Avisynth haste wieder installiert oder?

Wenn das Video im Laufe der Zeit komplizierter zu komprimieren wird, dauerts natürlich länger und die Dateigröße wächst an, da du mit CRF eine einheitliche Qualität haben willst mit deinem gewählten Faktor.

Die Dateigröße ist groß, weil dein Material entsprechend schwer komprimierbar ist und du mit CRF 21 eine enorme Qualität forderst. Und ich glaub das wird dir nicht so ganz bewusst irgendwie und guckst rein nur auf die Dateigröße, aber merkst gar nicht so recht, was für eine Qualität du verlangst und erwartest nun Wunder
Guck doch mal dein Video an. Das dürfte verdammt geil aussehen und anscheinend biste sogar mit 23 noch zufrieden ^^.

Sonst musste halt noch höheren CRF nehmen, wenns dir immer noch zu groß ist ..

ja sicher ..

x264 ist der CPU effizienteste Encoder.

Nur hat er eben auch die besten Encodingtechniken die entsprechend komplex zu berechnen sind. Darum muss man eben sehen, was für einen in Bezug Geduld, Dateigröße, Qualität und Internetleistung am besten passt.

Na direkt 26 nicht. Versuch erstmal 23 oder 24.

Wenn das Encodieren jetzt schon 2 Std mit Medium bei dir benötigt, würde ich auch kein Slow machen, da Slow deutlich mehr Aufwand ist und bei komplexerem Material der Kompressionserfolg nicht so ergiebig ausfallen wird, wie bei inkomplexerem Material.
Und Minecraft ist halt schwer komprimierbares Material.

Edit: verlesen, dachte bei medium dauerts schon 2 Std xD 1,5 std ist aber eig. auch ok für komplexeres Material, aber es kann durchaus sein, das Medium mehr Sinn macht, da wie gesagt der Kompressionserfolg bei entsprechend komplexem Material nicht immer so wundervoll ausfallen muss, das es sich lohnen würde - je nach dem wie gut halt auch der Upload ist. Ein DSL1000 würd sich ja schon eher über jedes gesparte Megabyte freuen.^^

Dann hatter Pech. Aber du kannstes einfach nicht verallgemeinern, da es wie immer aufs Material ankommt und die Kompressionseffizienz einfach grundlegend davon abhängig ist.

Zitat von maestrocool

bei 21 spaarst du ca 50mb, bei 22 sparst du ca 100mb-150mb, bei 23 ca 200-300 mb

Das kannst du nie im Leben so verallgemeinern. Genauso wenig auch mit den ganzen anderen x264 Einstellungen. Das hängt immer arg vom Material ab. 8x8 DCT zb sollte halt ebenfalls nicht abgeschalten werden. Mag ja sein das du bei deinen Videos mitm Normal Profil ohne 8x8 DCT keine wesentlich größere Datei hattest. Das kann aber durchaus auch mal ganz anders ausfallen. Und so ist das mit jeder anderen x264 Einstellung auch. Je inkomplexer das Material, desto mehr Kompressionsmethoden können sich auch effektiv entfalten.

Zitat

einen besseren Videoencoder für Youtube wirst du zur Zeit nicht finden.

Kleine Korrektur.

Zitat von Julien

Pauschale Frage, pauschale Antwort: Ja.

Das ist Unsinn, inkomplexeres Material wird auch kleiner wie andere schon sagen. Mein MeGUI Tutorial ist sogar nur 26 MB, trotz 2048x1152, CRF 20, und 43min 50 Länge,30fps.

__

Zitat

Wenn ich vor der veränderten Abspielgeschwindigkeit noch "video" schreibe, bekomme ich die Fehlermeldung, dass MeGUI diesen Befehle nicht kenne. Aber macht ja nichts, es geht ja auch ohne, danke^^

Damit definierst du Variablen. Ganz wie bei Programmierung.

Da du dein AVISource also in eine Variable "Video" definierst, aber video nirgends anwendest, kann er das halt nicht finden. Bei dem kleinen Script, wo du eh lediglich eine AVISource benutzt, macht sich eine Variable zu setzen auch nicht wirklich bezahlt. Das ist halt sinnvoll, wenn man zb noch mehrere Filter einsetzt und dann evtl nochmal die AVISource braucht, dann braucht man nicht alles doppelt und dreifach wiederholen. Ist ja auch ein bisschen Textmenge und daher übersichtlicher wenn man mit Variablen arbeitet.

audio=true gibt Avisynth nur die Info das die Quelle auch Audio hat.
Der Filter ist hier AssumeFPS und wenn er Audio mit berücksichtigen soll, musste wie Serra schon dir schrieb das true angeben als Parameter.

Nimm halt nicht so einen beschissenen Server.

Nimm Frankfurt. Bestes Routing

Zitat von DarkyYyLP

[IMG: http://www.speedtest.net/result/2023415944.png]

32.000 Leitung

Schrottiger Upload. Da bin ich jedes Mal froh bei Kabel Deutschland zu sein, da hab ich 2 mbit Upload bei 'ner 32000er und nicht nur 1mbit, was ja wohl echt mal 'nen schlechter Scherz ist, 1 mbit hat man doch schon bei DSL 16000.

Zitat von Saerex

jetzt hab ich wieder meine gute alte 32k leitung :3

[IMG: http://www.speedtest.net/result/1975134281.png]

Netter Ping, wow..

Gleich mal den Thron erobert

Naja hab vergessen mit anzugeben das es ein RAID 0 ist. Wäre vllt eine weitere Spalte für nett gewesen.

Schön wäre auch gewesen wenn man hätte SATA 1, SATA 2 oder SATA 3 angeben können, da ich leider kein SATA 3 habe und mein RAID Konstrukt von SATA 2 limitiert wird, (da ja eine einzelne Barracuda bereits 196 mbyte/s liefert und theoretischer Max von SATA 2 ist halt 300 mbyte/s ).

Aber dennoch kann ich bereits damit mit DXTory Codec @ RGB und ohne Compress Haken mit 90 ingame fps aufnehmen bei einer Aufnahme fps Rate von 30 und einer Auflösung von 2048x1152. Spiel: Descent.

Kannst auch schon bei Audacity in FLAC encodieren, der benutzt den selben FLAC Encoder.

Beim "Speichern unter" Dialog kannst du auch beim Audacity mit dem Optionen Button die Kompressionsstufe auf 8 stellen.

Dann waren die Parts mit CRF 20 und very fast erheblich besser komprimierbar als die anderen.

thritaldor

x264 = Handbrake, MeGUI etc.

Sony Vegas' sein H.264 Encoder ist jedoch nicht x264, sondern MainConcept.

Bleibst du bei deiner Falschaussage?

Zitat

Zudem: Wenn du Handbrake nicht einstellst und das Normal Profile, CRF 20 etc. übernimmst, ist es schon klar, dass die Datei am Ende verdammt groß wird.

^this.
Wenn man sich nicht mit dem Programm beschäftigt - selbst Schuld.

Aber dann sollte man ein Programm auch nicht verurteilen, wenn man nicht mal Lust hatte sich damit auseinanderzusetzen.

____

Der Frameserver geht mit Handbrake nicht, weil Handbrake nicht auf DirectShow zurückgreift, was aber logischerweise absolute Voraussetzung ist. Würde Handbrake einen Zugriff auf DirectShow erlauben würde auch Lagarith gehen. Ich versteh einfach nicht, warum die Entwickler da keine Option einbauen, das man auf DirectShow bei Bedarf zurückgreifen kann. Hier wäre Avisynth Support bereits hilfreich gewesen..

Der UTVideo Codec ist allerdings mit 4:2:0 sehr sehr langsam was ingame fps betrifft.

Mit 4:2:2 ist er aber dem DXTory Codec ebenbürtig.

4:2:2 frisst aber auch deutlich mehr Speicherplatz.

Der DXTory Codec ist auch auf 4:2:0 mit guter ingame FPS und somit der mir bisher geeigneteste Codec für höchste ingame fps. Kompression allerdings etwas schwächer als Lagarith, dafür eben mehr ingame FPS, sofern die HDD eben halt nicht der Flaschenhals wird. Sollte sie aber eig. nicht.

Luckis AVS Generator hat die Möglichkeit Audio zu mischen. Siehe 1. Post dieses Threads bzw auch gleich hier:

[ Text-Tutorial ] Der AviSynth Scriptgenerator

Ich empfehle es dir aber bei MKV zu bleiben. Der MP4 Container hat größeren Header und unterstützt auch nicht die Tonformate die ich im Tutorial empfehle.