Eine Videodatei im Avi-Format mit Codec "Lagarith", Farbraum YUY2, soll in YUY2 zuürckgewandelt werden.
Wozu, wenn es der gleiche Farbraum ist? :zunge:
Wozu, wenn es der gleiche Farbraum ist? :zunge:
Die Videos sollen komprimiert in Lagarith archiviert werden. Danach sollen sie beliebig weiterverarbeitbar sein, möglichst unabhängig von derzeitigen Codecs und Programmen.
D.h. es ist eine Anforderung, die Videos in "unkomprimiertes" YUY2 zurückführen zu können.
Es ist allerdings noch zweierlei, ob LAGS zu YUY2 decodiert werden kann, und ob YUY2 auch direkt in den Vorschaufenstern angezeigt werden kann. Die Anzeige funktioniert mit "herkömmlichen" Techniken (DIB o.ä.) möglicherweise nicht, ohne dass eine Umrechnung in RGB erlaubt wird. Direkte Anzeige wird u.U. Hardware-Overlay oder DirectX-Funktionen erfordern. Davon unabhängig ließe sich aber decodiertes YUY2 in AVI speichern oder an den nächsten Codec weiterleiten.
Mittlerweile sollte man hier auch schon die Optionen von VirtualDub 1.10.x von Avery Lee mit den Optionen von VirtualDub FilterMod vergleichen. Letzteres bietet in vielen Schritten der Verarbeitungskette noch ein paar mehr Optionen.
... Davon unabhängig ließe sich aber decodiertes YUY2 in AVI speichern oder an den nächsten Codec weiterleiten.
Ja, und hier ist die Frage, wie bzw. wie am besten?
Ich hatte angenommen: mittels Fast recompress, das funktioniert aber nur über RGB, nicht über YUYV (siehe #2).
Full processing mode geht, ffdshow auch.
Welcher Weg ist "richtig"?
Wenn AviSynth als Zwischenschritt erlaubt wäre, könnte man das mit dem Parameter AviSource(filename, pixel_type="YUY2") festlegen, der dem Lagarith-Codec mitteilt, er solle doch bitte versuchen, in YUY2 zu decodieren, wenn er kann.
In VirtualDub intern sollte "Color Depth / Decompression format = YUY2" das gleiche bewirken. Dass das nur im "Full Processing Mode" funktioniert, kann sein, da müsste ich aber erst mal wieder die Dokumentation studieren, um die Unterschiede zwischen den vier Video-Verarbeitungsmodi zu verstehen (sicher weiß ich nur, dass "Direct Steam Copy" LAGS weiterreichen würde, ohne es zu decodieren, und dass "Fast Recompress" die Verarbeitung von VirtualDub-Videofiltern = *.vdf deaktiviert).
(Uncompressed RGB/YCbCr) mittels "Full processing mode":
- Dies scheint in Ordnung zu sein.
Eigentlich ja, wenn in VirtDub der Clip geladen wird und mit "speichern unter", wie richtig erkannt unter "Full prozessing mode" der richtige Codec mit YUYV ausgewählt ist.
Wenn aber danach wieder ein anderer Codec zur Komprimierung verwendet wird, gibt es wieder Qualitätseinbußen.
Ich weis nicht was du vorhast, kannst aber von "lagarith" gleich unter "ut-video" abspeichern, anstatt erstmal unkomprimierte AVI's zu erzeugen.
Wo ist denn hier eigentlich das Problem?
Wenn Legarith installiert ist, kann das doch so ziemlich JEDES Programm direkt lesen, oder?
An sonsten:
VDub, "Decompression" auf YUY2, Output auf "same" oder auch "YUY2"...
Und dann "Full Processing Mode" ohne irgendwelche Filter (schadet jedenfalls nix)...und abspeichern...
Und was is eigentlich "besser"? UtVideo oder Legarith?
Von der "Qualität" gibts ja DEFINITIONSBEDINGT (lossless) keine Unterschiede...und von der Komprimierung her?
Ich hab immer UtVideo genommen...und Legarith vorhin installiert um nen paar Samples von jemandem anzugucken. Bei UtVideo kann man bei der Codec-Auswahl 4:2:2 und 4:2:0 wählen...bei Legaritz gibts nur einen Eintrag (der macht es wohl so wie er es bekommt?
Was ist denn "kleiner"?
Hast du eine Autokorrektur an, die dir "Lagarith" immer falsch schreibt? 
_
Das "Problem" war wohl u.a., warum es dafür den "Full Processing mode" braucht. Sollte eine schnellere Methode nicht auch geeignet sein? "Fast Recompress" sollte doch auch Decodierung in ein YUV-Format ermöglichen. In früheren VirtualDub-Versionen erzwang FPM noch die Decodierung zu RGB.
Bei Ut Video sollte man die Variante des Codecs verwenden, die zum decodierten Video passt, die muss man dafür allerdings kennen. Ansonsten gibt es Verluste durch Konvertierung des Chroma-Subsamplings oder Darstellungsfehler bei der Wiedergabe.
Welcher von beiden stärker komprimiert ... kann vom Material abhängen. Erheblich dürften die Unterschiede grundsätzlich nicht sein (verlustlose Kompressionsmethoden nähern sich einer Entropie-Grenze an, nach Claude Shannons Informationstheorie), vermutlich ist Ut meist etwas stärker. Takeshi hat vor kurzem Links zu einem Benchmark in seinem Blog veröffentlicht.
Hast du eine Autokorrektur an, die dir "Lagarith" immer falsch schreibt?
Nö! Das sind wohl meine Finger! :lol:
Ich HASSE Auto-Korrekturen und Auto-Vervollständigen! Außer die "roten Schlangen in Word" als "Hinweis" - das lasse ich mir gefallen...
Die Leute wundern sich auch immer warum ich auf meinem Androiden auch immer alles ausschreibe, und alle "Auto großschreiben" usw. und auch die Wortvorschläge immer AUS hab. Und ich bin trotzdem SCHNELL!
Ich hatte nichtmal T9 auf alten Tastenhandys eingeschaltet - mich NERVT sowas...ich will schreiben was ICH schreiben will 
Das "Problem" war wohl u.a., warum es dafür den "Full Processing mode" braucht. Sollte eine schnellere Methode nicht auch geeignet sein?
Ob die wirklich so merklich viel "schneller" ist...:hm: Ich lass es immer auf Full Processing, weil ich jedesmal wieder vergessen habe was die anderen beiden genau machen^^
(Außer "Direct Stream" - das ist klar, braucht man oft...)
Bei Ut Video sollte man die Variante des Codecs verwenden, die zum decodierten Video passt, die muss man dafür allerdings kennen. Ansonsten gibt es Verluste durch Konvertierung des Chroma-Subsamplings oder Darstellungsfehler bei der Wiedergabe.
Das ist klar. Ich verwende nur den 4:2:2er (Rec. 601 - wobei das auch nur ein irrelevantes "Flag" ist). Wenn ich (von YUY2) in VDub nach Ut 4:2:2 zwischenspeichere, lasse ich "Interlaced Encoding" auch immer aus (trotz interlaced), sonst kann es XMedia Recode nicht lesen. Aber das macht ja nix, solange ich in XMR bei H.264-Codec wieder "Interlaced TFF" einstelle...
In dem Fall mache ich die 4:2:2->4:2:0-Konvertierung weder in VDub, noch im Ut-Codec, sondern das passiert dann eben im H.264-Encoder (ffmpeg). Wird schon OK sein...
Welcher von beiden stärker komprimiert ... kann vom Material abhängen. Erheblich dürften die Unterschiede grundsätzlich nicht sein
Dachte ich mir - deswegen spare ich mir das Testen einfach...
-----
Hätte meine letzten VHS'en auch in H.265 encoden können (ist bei XMR auch schon mit drin). Aber das habe ich (der Kompatibilität wegen) lieber gelassen. Macht glaube ich auch kein so großen Unterschied mehr bei SD-Auflösungen ob H.264-AVC oder H.265-HEVC...
PS.: Hast du als "Encoding-Profi" eigentlich irgendwas gegen XMedia Recode einzuwenden? Wenns mir halt gefällt?
Ich stehe nicht so auf "Scripting" - bei XMR habe ich halt alle wichtigen Encoder-Settings grafisch...deswegen mag ich auch VDub so, und mache das meiste damit...
H.265 / HEVC würde ich nicht unbedingt "flächendeckend" für jeden Zweck empfehlen. Es hat deutliche Vorteile gegenüber H.264 / AVC und anderen Formaten, wenn es um hohe Auflösungen geht (FullHD, UHD). Bei SD-Auflösungen gibt es einige, die mit dem Detailerhalt von x264 immer noch zufriedener sind und mit x265 nach eigenen Aussagen zu starken Detailverlust bekommen; außerdem sollte mit HEVC eigentlich die Ära der Unterstützung von Interlacing vorbei sein (x265 kann es trotzdem).
Was die verwendete Konverter-Software angeht: Wenn du damit alles tun kannst, was du brauchst, und sie andererseits nichts unerwünschtes in deinem System anstellt, dann verwende, das dir gefällt. Ich würde davon ausgehen, dass XMR als eine Art "ffmpeg mit m.o.w. bunten Fenstern" mir nicht flexibel genug wäre, deshalb hab ich's bisher noch nie verwendet, aber der Screenshot im Software-Archiv von VideoHelp hinterlässt bei mir einen relativ angenehmen Eindruck... Zum direkten Konvertieren ohne viel Filtern wird es sicher gut brauchbar sein.
Wenn du damit alles tun kannst, was du brauchst, und sie andererseits nichts unerwünschtes in deinem System anstellt
XMR ist nicht "SUPER (c)"...da kommt einem ja wirklich das Grausen...
Das Tool ist ganze 9MB groß.
Zum direkten Konvertieren ohne viel Filtern wird es sicher gut brauchbar sein.
Schau es dir doch mal an! 
Vielleicht wird es eine Empfehlung für Leute, denen du sonst immer das Scripten beibringen musstest.
Es gibt unendlich viele Encoder-Einstellungen (wenn nicht sogar alle) - wie ich finde sehr übersichtlich.
Soweit ich gelesen habe, dürfte es etwa vergleichbar sein mit Handbrake oder VidCoder. Und auch TEncoder ist nicht weit weg (v.a. interessant für Batch-Verarbeitung in mehreren Threads).
Soweit ich gelesen habe, dürfte es etwa vergleichbar sein mit Handbrake oder VidCoder. Und auch TEncoder ist nicht weit weg
Von denen hab ich auch schon gehört - Handbrake hab ich auch schon ausprobiert... MXR gefällt mir besser.
Ich codiere damit auch Video-DVDs und BluRays in MP4. Der ließt direkt die komplette Menüstruktur ein und man kann die Spuren wählen. (Geht natürlich in der Tat nur mit nicht-kopiergeschützten Scheiben - klar. Ja ja...;))
Und er hat halt nahezu ALLE ffmpeg-Formate drin - nicht nur H.264 und AAC...
v.a. interessant für Batch-Verarbeitung in mehreren Threads).
Batch kann XMR auch vorzüglich. Mehrere Threads? Die Clips werden natürlich nacheinander codiert, aber die Encoder lasten meinen 4-Kerner komplett aus...
Auch Cropping (z.B. bei DVD-Filmen) kann man damit sehr einfach "direkt" machen. Einziges Manko ist, dass man das Seitenverhältnis oft von Hand über die PAR und die tatsächliche Auflösung in eine DAR umrechnen muss (weil man die eingeben muss). Hab das dem Autor auch schon geschrieben, hat sich nichts dran geändert - aber was solls...geht ja schnell die Rechnung...
Nicht alle Encoder arbeiten so gut parallelisiert wie x264; gerade Audio-Encoder eher nicht. So kann man mit TEncoder z.B. eine Musiksammlung gut multithreaded konvertieren. So hat jeder seinen Vorteil.
Wenn XMR die logische Struktur einer DVD gut versteht, ist das sicher ein Vorteil für diesen; die meisten Konverter erwarten doch eher nur eine minimalistische Vorlage (im Fall einer DVD Video: 1 PGC, 1 Angle, am besten 1 zusammenhängende PGC-VOB oder rohe Streams statt 1-GB-Segmente).
XMR macht das perfekt mit dem Einlesen dieser Strukturen (auch Bluray!). Dem gibt man via "Medium öffnen" nen Video_TS-Ordner zu fressen (egal wo der herkommt), und er listet alle Tracks separat und zusammenhängend auf.
Zeigt auch alle Daten an (MPEG2, alle Audiostreams usw.). Und man kann jede Sprachspur einzeln codieren oder 1:1 kopieren. (Der längste ist dann eben der Hauptfilm.
(Interessant dass die meisten DVD-Filme interlaced encodet sind - das ist doch eigentlich ineffizient?!?) Auch wenn ich mal nen "Film" von VHS überspiele, wird der progressiv encodet...
Ich beschäftige mich schon lange nicht mehr mit irgendwelchen DVD-/Bluray-Strukturen...
Und wenn ich wirklich mal noch ne DVD ERSTELLEN muss, dann mache ich das MPEG2-Encoding mit XMR und den "Rest" mit nem uralten TMPGEnc DVD-Author...feddisch...
(Kommt aber selten vor...hab glaube ich seit Jahren nix mehr gebrannt...außer mal ne DVD mit paar MP3-Alben für ne Freundin )
Für Audio-CDs und Audio-Konvertierung nehme ich "Easy CDDA Extractor" - hat alle Formate (MP3, FLAC, ALAC, WAV, OGG, AAC/M4A) mit drin, und übernimmt beim Konvertieren auch die Tags...
Und für allgemeines Tagging nehme ich "MP3Tag" (kann auch alle Container).
Aber mit XMR kann man auch gut Audio machen: Hab von einigen Konzertmitschnitten von VHS, die ich in einzelne Tracks (MP4) geschnitten hatte (H.264 + MP3) am Ende noch einzelne MP3s extrahiert (Stream kopieren) - für die Musiksammlung auf dem Handy...
Und den Ton von Youtube-Videos extrahieren mache ich auch damit (Download per Firefox Downloadhelper) ...
Und für allgemeines Video-Processing VirtualDub und für Audio Audacity und Nero Wave Editor (kostenlos).
Hab schonmal gelesen dass irgendwelche Freaks XMR auf dem Mac über Wine/Parallels Desktop laufen lassen, weil es was vergleichbares in der tollen "Apfelwelt" nich gibt! 
Wo ist denn hier eigentlich das Problem?
Wenn Legarith installiert ist, kann das doch so ziemlich JEDES Programm direkt lesen, oder?
Ich hatte bei den ersten Tests verschiedener lossless-Codecs festgestellt, dass Logaritz von mehreren Programmen nicht abgespielt wird. Mittlerweile hat sich aber geklärt, dass es zwei Registry-Einstellungen vom Lagarith gibt, die dies beeinflussen. Jetzt geht's also.
Wahrscheinlich ist eine Weiterverarbeitung mit Avisynth, das ist sowieso kein Problem.
Die Videos sollen aber einige Zeit in komprimierter Form archiviert werden. Wer weiß schon, was später einmal auf dem Markt ist und was dann noch läuft. Als Sicherheit soll ein Weg aufgezeigt werden, die Dateien zurückzuführen in Avi-YUY2-Dateien, die weitestgehend dem Format und der Qualität entsprechen von Dateien, die jetzt direkt und unkomprimiert digitalisiert werden (in YUY2).
Daher die Tests mit VDub.
Die ersten Tests brachten unmotiviert mal YUY2-Dateien, mal doppelt so große RGB-Dateien. Ich habe versucht herauszufinden, woran das liegt.
Dabei habe ich mir folgenden Forum-Tipp notiert:
Eine Kopieerstellung unter Virtual Dub nach YUY2 verändert ggf. das Material. Die verwendete Einstellung "Compression" ist nicht entscheidend (Uncompressed RGB/YCbCr oder ffdshow YUY2).
Wichtig ist die Einstellung "Fast recompress", wodurch der Farbraum nicht verändert wird (im Gegensatz zu "Full recompress" und "Normal Recompress" - die gehen über den Farbraum RGB).
Der stimmt so aber wohl auch nicht. Jedenfalls funktioniert die Variante mit "Fast Recompress" und "Uncompressed" nicht (grüner Schirm). Oder nicht mehr, weil sich vielleicht mein System verändert hat?
Highwayman.
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!
