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 erstellen[lexicon]Lagarith[/lexicon] kann mit Haali nicht abgespielt werden, korrekt.
Wenn ich im MPC-HC Haali als DirectShow Renderer einstelle, werden meine [lexicon]Lagarith[/lexicon] Videos (mit [lexicon]VirtualDub[/lexicon] encodiert) problemlos, wenn auch durch die hohe Kompression bedingt etwas ruckelnd, abgespielt.
Mich "stört" nur der Lagarith... Hatte mich an den [lexicon]DXTory[/lexicon] [lexicon]Codec[/lexicon] gewöhnt und an die Möglichkeit die rohe Aufnahme direkt mal anzuschauen und auf Fehler überprüfen. [lexicon]Lagarith[/lexicon] kann ich aber mit Haali nicht abspielen. Oder bin zu blöd dafür.
Was passiert denn, wenn du die Datei abspielen willst? DirectShowSystem durch ein Codecpack zerschossen?
Dann sollte das wohl eher an ExKoder gemeldet werden; [lexicon]Camtasia[/lexicon] lass ich mal weg, Bugreport bringt bei TechSmith eh nichts xD .
Jedes Mal den Header zu editieren kann nämlich schon nervend sein...
@ET
YUV 420 != YV12
Aber dann scheint es wirklich an [lexicon]DXTory[/lexicon] zu liegen, dass der unterschiedliche Header generiert.
Ich melde das mal promt an die Entwickler xD . Aber immerhin wissen wir jetzt, das es nicht an Avisynth oder [lexicon]MeGUI[/lexicon] liegt.
@Saragas
Importiere die [lexicon]Lagarith[/lexicon] AVI mal in [lexicon]VirtualDub[/lexicon] und encodiere wieder als [lexicon]Lagarith[/lexicon] mit YV12 und Multithreading. Dann erstell ein Avisynth Script, in dem du die encodierte AVI lädst und eine Info ausgibst.
@ET
Kein Unterschied im Colorspace, war aber auch zu erwarten, weil Histogram und Stackhorizontal YV12 unterstützen.
Histogram und Info deuten allerdings klar auf YV12 hin:
Also bei mir steht da mit aktuellstem [lexicon]MeGUI[/lexicon] und einem Input Video im [lexicon]Lagarith[/lexicon] [lexicon]Codec[/lexicon] nach dem Encode kein ConvertToYV12 im Avisynth Script.
Ich denke, dass man da nichts mehr machen kann, um das komplette Videomaterial zu reparieren 
.
Dann scheint es mit dem FPS1 [lexicon]Codec[/lexicon], wie auch mit dem UT Video [lexicon]Codec[/lexicon] 4:2:2, Probleme beim Reparieren des Videos zu geben; das ist zumindest meine Schlussfolgerung, und wenn sie zutrifft, ist das Videomaterial wohl hinüber. Du kannst natürlich aber nochmal De-M-oN nach seiner Ansicht fragen.
Welcher [lexicon]Codec[/lexicon] wurde zur Aufnahme verwendet?
Du hast mit [lexicon]MeGUI[/lexicon] zwei Möglichkeiten:
- Schneiden mit MKVMerge nach dem [lexicon]Encodieren[/lexicon] => nur an Vollbildern im Video, daher ungenau (bei Standart Max. [lexicon]GOP[/lexicon] und 30FPS bis zu ~6 Sekunden Abweichung)
- Schneiden mit TRIM bzw. dem [lexicon]AVS Cutter[/lexicon] vor dem [lexicon]Encodieren[/lexicon] => Framegenau, allerdings Angabe in Frames und nicht in Sekunden
Dieser Workflow wird außerdem deine Videoqualität verbessern, da nicht durch einen zweiten lossy Encode in [lexicon]Camtasia[/lexicon] Qualität verloren geht.
Hab jetzt testweise das Ganze mal ohne Resize laufen lassen, nur um zu sehen ob es dann die [lexicon]CPU[/lexicon] ausnutzt... Fehlanzeige. Und das mit dem zweiten Job raff ich nicht ganz, kannst du das noch genauer erklären?
Danke aber schon mal für die Antwort.
Verwendest du als [lexicon]x264[/lexicon] Preset etwas höheres als Medium (Fast/Very Fast/...)?
Alles anzeigenSo, hab gerade auch ein Problem mit [lexicon]MeGUI[/lexicon], hier scheint ja Kompetenz vorhanden zu sein, deshalb hier meine Anfrage:
Ich render schon länger mit [lexicon]MeGUI[/lexicon], hatte auch noch nie Probleme, [lexicon]Prozessor[/lexicon] wurde immer schön ausgelastet, alles in Ordnung.
Jetzt habe ich meinen Rechner neu gemacht, und [lexicon]MeGUI[/lexicon] will einfach die [lexicon]CPU[/lexicon] (i7 3770k) nicht mehr 100% auslasten.
Bei Qualität auf 22,5 und dem Preset Slow, mit Resize von 1080p auf 1152p, rendert [lexicon]MeGUI[/lexicon] mit gerade mal 10 fps, und nutzt nur ~40% der [lexicon]CPU[/lexicon].
Wie bekomme ich die volle Auslastung, also die optimalste Nutzung der CPU?
Danke schon mal,
LG
Cooke
Die Resizefilter von Avisynth sind Single-Threaded geschrieben und compiliert worden, das heißt, [lexicon]x264[/lexicon] muss immer darauf warten, dass ein Kern den [lexicon]Frame[/lexicon] skaliert. Ohne den Resize hättest du höchstwahrscheinlich 100% Auslastung.
Die Lösung des Problems sind mehrere Worker, die du durch einen Linksklick -> Run in new temporary Worker auf einen zweiten Job initialisierst.
ZitatNaja viel zu eklären gibts nich
Entweder macht man die lossy [lexicon]PCM[/lexicon] wav von [lexicon]DXTory[/lexicon] über [lexicon]Audacity[/lexicon] wieder zu ner lossy [lexicon]PCM[/lexicon] wav und macht diese über [lexicon]MeGUI[/lexicon] zu ner lossy Vorbis ogg, losless [lexicon]FLAC[/lexicon] oder ner losless Nero aac oder man macht sie über [lexicon]Audacity[/lexicon] direkt zu ner losless [lexicon]FLAC[/lexicon] bzw. ner losless Nero aac
Kann es sein, dass du hier lossless und lossy durcheinander schmeißt?
PCM Wave - Lossless
Vorbis - Lossy
FLAC - Lossless
AAC - Lossy
Natürlich kann man mit Vorbis und Nero AAC für das menschliche (und nicht audiophile) Ohr zum Original transparente Qualität erzeugen, messbar ist der qualitative Unterschied allerdings dennoch immer.
Resizen kann [lexicon]x264[/lexicon] auch ohne avisynth.
Wieder etwas gelernt 
Aber mit was sind der Spline-Resize und der Lanczos-Resize von [lexicon]x264[/lexicon] in Avisynth vergleichbar?
Spline(x264) = Spline64(Avisynth) oder Spline36(Avisynth) oder Spline16(Avisynth)?
Lanczos(x264) = Lanczos(Avisynth) oder Lanczos4(Avisynth)?
mal eine dumme frage von mir, die mich schon ein paar tage beschäftigt
ob es was bringt wenn man beide Resizefilter also spline64 und Lanczos4 benutzt, da ja spline sauberer arbeitet, aber [lexicon]Lanczos[/lexicon] wohl schärfer arbeitet..
Inwiefern beides verwenden? Mir fällt keine Situation ein, in der es sinnvoll wäre, zwei verschiedene Resize-Filter zu verwenden.
Und wenn du das beispielsweise so eingibst
wird [lexicon]Spline64[/lexicon] nicht verwendet, weil das Videomaterial dann bereits die gewünschte [lexicon]Auflösung[/lexicon] besitzt. Andersrum natürlich genauso.
da ich mit [lexicon]Sony Vegas[/lexicon] und [lexicon]Frameserver[/lexicon] arbeite...
Das ist der Grund, weshalb [lexicon]x264[/lexicon] die [lexicon]CPU[/lexicon] nicht zu 100% auslasten kann: Es (also der Encoder) muss zuerst auf Vegas und den Debugmode [lexicon]Frameserver[/lexicon] warten.
Ist ja logisch, da der Weg deutlich länger ist:
Weg des Videomaterials mit Vegas: Decoder(Vegas) -> ggf. Filter(Vegas) -> Frameserver(Debugmode Frameserver) -> Decoder(Avisource) -> Frameserver(Avisynth, ggf. mit Filtern) -> Encoder(x264)
Weg des Videomaterials ohne Vegas: Decoder(Avisource) -> Frameserver(Avisynth, ggf. mit Filtern) -> Encoder(x264)
[lexicon]x264[/lexicon] selbst könnte deine [lexicon]CPU[/lexicon] zu 100% auslasten, aber es muss eben erst warten, bis die vorherigen Schritte erledigt sind. Am idealsten wäre natürlich ein direktes Encoding im [lexicon]CLI[/lexicon] [lexicon]x264[/lexicon] ohne Avisynth [lexicon]Frameserver[/lexicon], allerdings wäre das für den konventionellen Let's Player zu zeitaufwendig und unflexibel (kein Resize etc.) im Vergleich zu einer [lexicon]GUI[/lexicon] wie [lexicon]MeGUI[/lexicon]. Zumal Avisynth ohne angewandte Filter und nur mit dem Avisource-Decoder das Encoding nur marginal verzögert.
Wenn du also nicht weiter viel bearbeitest, wäre es das sinnvollste, auf Vegas zu verzichten und nur [lexicon]MeGUI[/lexicon] zu verwenden.
Ja, dann ging es.. Ich dachte, audio=true bedeutet, das Audio des Videos wird gleich mitencodiert und ist in der mkv drinne, aber so war es wohl nicht, also ist der Eintrag ja total unnötig und ich kanns auch auf false lassen.
Falls (Audio=True), wird das Audiomaterial ja auch encodiert, nur eben nicht automatisch mit dem encodierten Videomaterial gemuxt.
Wenn (Audio=False), hast du insofern mehr Aufwand, weil du den Audiostream erst aus dem Video extrahieren musst, bevor du das Video- und das Audiomaterial wieder [lexicon]muxen[/lexicon] kannst, aber letztendlich durch [lexicon]PCM[/lexicon] Wave auch einen lossless [lexicon]Codec[/lexicon]. Inwiefern sich die Qualität von diesem und die Qualität eines gut eingestellten und somit zum Inputmaterial Transparenz erzeugenden Encoders (z.B. Nero [lexicon]AAC[/lexicon] mit VBR=0.8) unterscheiden, ist jetzt Ansichtssache. Ich bin der Meinung, dass Effizienz wichtiger als überschüssige Qualität ist.
Wie ich [lexicon]MeGUI[/lexicon] hasse
Muxen des encodierten Video- und Audiomaterials vergessen? Andernfalls mal die letzte .log hier posten.
