Handbrake kann kein Lagarith.
Musst MeGUI oder Staxrip benutzen. Ich persönlich bevorzuge MeGUI über Staxrip, aber deine Entscheidung^^.
Um schreiben oder kommentieren zu können, benötigst du ein Benutzerkonto.
Du hast schon ein Benutzerkonto? Melde dich hier hier an.
Jetzt anmeldenHier kannst du ein neues Benutzerkonto erstellen.
Neues Benutzerkonto erstellenHandbrake kann kein Lagarith.
Musst MeGUI oder Staxrip benutzen. Ich persönlich bevorzuge MeGUI über Staxrip, aber deine Entscheidung^^.
Number of extra I-Frames ist besser auf 40.
Ansonsten wird das Tutorial demnächst eh ein Update unterzogen, wo dann einiges einfacher verlaufen wird, da ich mehrere Presets dann zur Verfügung stelle, was euch mehr Variationsmöglichkeiten gibt zwischen Encodierzeit vs Dateigröße und durch den Presets werden manche Sachen auch einfacher verlaufen.
Edit: Habs nun mal mit Sony Vegas probiert.
Das rendert das ganze problemlos.
In den Lagarith Codec?
Wenn ja, dann nimm danach die Lagarith Datei für MeGUI ![]()
ich hab das Gefühl, das Youtube die B-Frames und die Pyramidal-P-Frames wieder nicht mehr mag.....
denn nachdem ich wieder auf mein altes Profil mit ausgeschalteten B-Frames/Pyramidal-P-Frames zurückgegangen bin, sind meine Videos wieder normal verarbeitet worden bis 1080p.
[...]
Aber nachdem ich gerade hier im Forum, und auch bei Youtube öfter gelesen hab, das bei manchen die Videos noch immer nicht richtig verarbeitet werden, kam mir eben dieser verdacht mit den B-Frames und Pyramidal-P-Frames.... etwas anderes hab ich nicht geändert in den Profilen.
Und jetzt wollte ich mal wissen was De-M-oN zu der These denkt.
Also ich habs nach wie vor mit
--preset slow --crf 21.0 --partitions all
was bei den frames das hier ergibt:
Das mach ich schon sehr lange so.
Profile steht schon immer auf High bei mir.
Und ich hatte das Problem mit dem 480p max noch nicht ein einziges Mal.
Mit dem heutigen Audiosurf Video nicht, als auch mit den Doom 3 Videos nicht.
Geschmackssache.
Ich füg meine Fraps parts mit TMPGEnc 4 zusammen.
Kannst ja Sony Vegas oder so mal probieren.
Falls du den Lagarith Codec noch nicht hast - hier:
http://lags.leetcode.net/LagarithSetup_1325.exe
In dessen Config: YV12 & Multithreading anhaken.
PS: hättest du Fraps genommen, hättest diese Decodierungsprobleme nicht gehabt
Ich stelle fest:
Der Codec ist ganz schön scheisse...
Und ich weiß auch nicht wirklich mehr, wie ich dir da helfen soll, wenns schon an der Decodierung scheitert - was hier der Fall ist.
Kriegste sie vllt mit 'nem größeren Videoprogramm hin? Vegas, Camtasia o.ä.?
Dann könntest es nach Lagarith encodieren und dann eben die Lagarith Datei für MeGUI benutzen.
Und wo ist das Video bei Avisource? Da steht ja gar nichts.
Zeig mal das AVS Script mit AVISource pls.
Dann stimmt was mit der Decodierung nicht..
Was extrem komisch ist, wenns selbst via AVISource nicht geht - weil dann heißts das der Playclaw Decoder decodiert (Bei AVISource wird aufs DirectShow System zurückgegriffen)
Daher direkt mal die Frage: Läuft das Video mit einem DirectShow Player (Sprich einem Player, der keine internen Decoder mit sich bringt)? WMP, Winamp z.b. WMP12 und Winamp bringen zwar auch interne decoder mit, aber wenn sie ein Video selbst nicht decodieren können, gibts ein Fallback aufs DirectShow System, was bei Playclaw passieren wird, da beide ja standardmäßig den nicht abspielen können, daher muss aufs DirectShow System und somit auf dem Decoder vom Playclaw zurückgegriffen werden. Und der arbeitet aber fehlerfrei mit WMP / Winamp etc?
Jedenfalls bekommt MeGUI es von DirectShow offensichtlich fehlerhaft übermittelt. Sonst würde es laufen.
Der Playclaw Codec scheint ja dann wirklich Klasse zu sein, wenn der so gerne Probleme bereitet ![]()
Aber wenn du zur YV12 Frage angelangt bist, scheints doch jetzt zu gehen?
Die Frage bestätigst mit Ja und dann encodierst das Video.
Wenn ich DirectShowSource benutzten würde müsst ich ne Farbumwandlung machen in YV22 oder so.
Ist halt die Frage ob das wirklich nötig ist.
JA!
x264 benötigt es in YV12.
PS: Sorry für die späte Antwort, aber es ist halt extrem mistig, wenn man edits nicht mitgeteilt bekommt vom Forum, sondern eben nur neue Posts der Thread nach oben gelangt / markiert wird etc.
Er findet keinen Decoder für dein Video.
MJPG? JPG ist natürlich nicht verlustfrei.
Das zum Thema Playclaw wäre verlustfrei^^
Also das Video ist aufgenommen im TAMB codec. Also lossless.
Der ist nur dann Lossless wenn du keine Kompression verwendest. (Dann zumindest dürfte er lossless sein)
Haste denn nun mal mit AVISource probiert oder nicht?
@Chaosfisch:
Hast du Lagarith als Lossless Codec verwendet?
Dann musst du statt FFVideoSource AVISource benutzen.
Kannst beim bereits bestehendem AVS Script einfach das FFVideoSource durch AVISource ersetzen.
Die 1. Zeile kann dann komplett entfernt werden, da ffms2.dll ja nur zu FFVideoSource gehört.
Vllt hat Youtube zurzeit Probleme.
Wenn man im Youtube Thread hier guckt, scheinen ja mehrere Probleme mit deren Encode zurzeit zu haben (dauert sehr lange etc)
Kopfdatenkompression mit MKVMergeGUI entfernt?
Fraps kann von FFVideoSource gelesen werden.
Naja der File Indexer guckt nach, wo in deinem Video die ganzen keyframes stecken. Dies ist vor allem beim schneiden framegenauer, als der Weg über DirectShowSource/AVISource, welche das nicht unbedingt immer so genau nehmen.
Dies dürfte aber bei Lossless Codecs wie Lagarith und Fraps nicht von Nöten sein, da diese ja eh keine b oder p frames schreiben aufgrund ihrer Natur das sie verlustfrei speichern.
Mit FFVideoSource werden außerdem eventuell genutzte DirectShow Filter ausgeklammert (Deblocker oder sonstige Dinge)
Ansonsten aber sparste mit AVISource halt den index job. Spart halt Zeit.
Die herausgekommene Datei war größer als das Original 8|.
Das kann nur bedeuten, das auch hier wieder verlustbehaftetes Material an x264 gegeben wurde ...
Bitte VERLUSTFREIES !!!! Material an x264 geben.
Und wenn es selbst dann nachher mehr Dateigröße ergibt, als bei dem Programm wo ihr sonst immer euren Lossy(verlustbehafteten) Encode macht, liegt es schlichtweg dran, das der gewählte CRF Faktor einfach mehr Dateigröße erfordert um dem CRF Faktor treu zu bleiben.
Ihr könntet dann den CRF Faktor erhöhen, dann habter weniger Anspruch an Qualität und die Datei wird kleiner (aber eine z.b. 600 MB Datei von x264 wird bessere Qualität besitzen als ein 600 MB Video von einem der vielen anderen schlechteren H.264 Encodern.
Auch kann Dateigröße eingespart werden mit rechenintensiveren Encodiereinstellungen - erhöht aber natürlich die Encodierzeit.
Skaliers auf 2048x1152 hoch -> 16:9
Auch aus 16:10 Auflösung auf 2048x1152 skaliert:
http://www.youtube.com/watch?v=yM-qZ0W4r-U (Video ist vom Freund)
Ich sehe hier die Problematik nicht.
Sieht doch trotzdem noch ok aus.
Dann lässt sich bei deinem Material nur schwer weiter komprimieren.
Kommt halt wirklich aufm Videoinhalt an.
Und lädst du auch in 1920x1200 hoch?
16:10 ist ein doofes non-standard Seitenverhältnis und hat in Video vor allem nichts verloren.
Mit 16:9 Monitor haste dann schön die schwarzen Ränder links und rechts.