Worum geht es dir da überhaupt?
Der "Farbraum" des Videos hängt von der Kompression durch den beim Erzeugen verwendeten Codec ab, sowie von der Anfrage, die das decodierende Programm an den Codec beim Decodieren meldet.
Beispielsweise wird VirtualDub, wenn du den Modus "Full Processing" einstellst, den Codec immer anweisen, das AVI als RGB24 zu decodieren. Bei "Fast Recompress" dagegen wird VirtualDub dem encodierenden Codec erlauben, dem decodierenden Codec erwünschte Farbräume vorzuschlagen -- das wird bei MPEG4 als Zielformat meist eine YUV-Variante sein.
__
Hi.
Danke für Deine schnelle Antwort und sorry, dass es bei mir dann etwas länger gedauert hat.
Ist leider eine längere Geschichte:
Ich möchte Skript gesteuert ein paar Videos "schneiden". Ich hab als Ausgangsmaterial diverse Videos aus unterschiedlichen Quellen, die zwar alle mit DivX 4 komprimiert sind, aber (widererwarten) scheinbar nicht den gleichen Farbraum haben (erwartet hätte ich eigentlich yv12, weil ich dumpf im Hinterkopf hatte, dass der Codec intern diesen Farbraum verwendet?).
Zum "schneiden" will ich mit avisynth ein Schnippsel aus einem Video erzeugen um es später mit direct stream copy wieder ans Ausgangsmaterial anzuhängen.
Zunächst lasse ich das avisynth Skript dazu von VDub nach DivX 4 enkodieren, danach will ich das Ausgangsvideo und den Schnippsel aneinanderhängen - und an der Stelle zickt es dann, weil die Dateien lt. VDub ein unterschiedliches Format haben sollen. Einige "Untersuchungen" später habe ich feststellen müssen, dass das Format sich absolut nicht unterscheidet, außer offensichtlich im Farbraum.
Try and error brachte mich schließlich soweit, dass es für die Videos aus einer Quelle nun klappt, wobei ich das Outputformat zum Enkodieren der Schnippsel auf XRGB32 einstelle (VirtualDub.video.SetOutputFormat(8)).
Daraus schließe ich, dass der Farbraum des so erzeugten Videoschnippsels auch RGB32 ist? und wenn ich dieses und das Ausgangsvideo auch aneinanderhängen kann folglich das Ausgangsvideo auch RGB32 ist?
(oder könnte es sein, dass sie eigentlich yv12 sind und nur im header fälschlicherweise rgb32 eingetragen ist???) -> um dem nachzugehen, wäre ich eben auf der Suche nach einem Programm, das den Farbraum analysiert oder identifiziert.
Der "Farbraum" des Videos hängt von der Kompression durch den beim Erzeugen verwendeten Codec ab, sowie von der Anfrage, die das decodierende Programm an den Codec beim Decodieren meldet.
...
Beispielsweise wird VirtualDub, wenn du den Modus "Full Processing" einstellst, den Codec immer anweisen, das AVI als RGB24 zu decodieren. Bei "Fast Recompress" dagegen wird VirtualDub dem encodierenden Codec erlauben, dem decodierenden Codec erwünschte Farbräume vorzuschlagen -- das wird bei MPEG4 als Zielformat meist eine YUV-Variante sein.
Versteh ich nicht ganz. Bzw. betrifft mein Problem doch nur indirekt? -da bei direct stream copy ja nichts de/enkodiert wird. Außerdem kann ich doch auch bei full processing das decompression format festlegen (oder ist das nur eine pseudo Einstellung und VDub verwendet trotz anderer Einstellung einfach RGB24)?
Dennoch wäre das bei meinem Problem doch irrelevant, da es doch eigentlich nur darum geht, beim direct stream copy die gleichen Formate bei den aneinandergehängten Videos zu haben und da ist doch in meinem Fall lediglich das Outputformat beim Schnippselenkodieren wichtig. (Am decompression format zu drehen, brächte mir doch höchstens einen kleinen Performanzvorteil, wenn ich in avisynth eine Konvertierung nach yuy bzw. yv12 anwiese und dann in VDub dieses direkt an den Codec geben würde statt es erst nach RGB24 zu konvertieren?)
Danke nochmal für Deine Hilfe und viele Grüße
osirus
PS:
Danke, genau das habe ich gesucht!
Du willst Videos schneiden... Da gibt es zwei Möglichkeiten:
1) Du kannst die Keyframes verwenden: "Video - Direct Stream Copy", ohne Rekomprimierung, Qualität bleibt erhalten.
2) Du musst an beliebigen Frames schneiden, auch mitten in einer GOV:
2a) komplett dekomprimieren, schneiden, dann neu komprimieren: AviSynth und die Trim()-Funktion sind auf jeden Fall nützlich. Beim Öffnen der Videos mit der Funktion "AviSource()" kannst du angeben, in welchem Farbraum das Video denn möglichst zu öffnen sei:
AviSource hat den optionalen Parameter "pixel_type". Der steht in Version 2.5x standardmäßig auf "YV12". Man kann damit aber auch angeben, dass AviSynth das Video gern in "YUY2" oder "RGB24" hätte. YV12 macht eventuell bei der Vorschau Probleme (da muss evtl. ein Raw-Konverter-Codec installiert sein, wie bestimmte Versionen von DivX, XviD oder ffdshow), aber beim Konvertieren geht das normalerweise problemlos. Und bei Interlaced-Video muss man in YV12 gut aufpassen, sonst bekommt man Matschfarben.
2b) stückchenweise neu komprimieren, wo es nötig ist: VirtualDub 1.7.x hat eine experimentelle Smart-Rendering-Option. Wenn du hier mit VirtualDub allein schneidest, kannst du eventuell Zeit sparen. Allerdings kannst du nur im "Full processing"-Modus filtern, und VirtualDub-Filter sind technisch meist hinter AviSynth-Filtern zurück.
Du solltest Funktionen von AviSynth und VirtualDub möglichst nicht unbedingt gemischt verwenden. Und alle Schnipsel erst mal in DivX 4 zu konvertieren, ist nun wirklich ein "grober Fehler", wo AviSynth doch auch mehrere Quellen öffnen, verbinden, und als ein komplettes Video ausgeben kann.
Versuche, alles was möglich ist, in AviSynth komplett durchzuführen. Dann komprimiere den kompletten Ausgabe-Clip in das endgültige Zielformat.
AviSynth dekomprimiert immer.
Danach wirst du immer neu komprimieren müssen.
Deshalb verstehe ich nicht, warum du erst mal mit Verlusten nach DivX komprimierst, dann durch AviSynth die DivX-Schnipsel wieder dekomprimierst, und zum Schluss noch mal neu komprimierst.
Wenn du Video aus einem AviSynth-Skript mit Direct Stream Copy in ein AVI kopierst, dann wird in dem AVI unkomprimiertes Video sein - in dem Farbraum, der im AviSynth-Skript verwendet wurde (also bei ehemaligen DivX-AVIs meist ein neues riesiges YV12-AVI).
Hallo.
AviSynth dekomprimiert immer.
Danach wirst du immer neu komprimieren müssen.
Ja, das ist ja klar uns soll ja auch so sein. Aber damit erzeuge ich ja nur einen kleinen Schnippsel aus dem Ausgangsvideo neu (um ihn zB mit irgendeinem Filter zu verändern) und komprimiere den dann wieder nach divx um ihn anschließend wieder an das Ausgangsvideo anzuhängen.
Dieses Anhängen erfolgt dann mit direct stream copy (kein avisynth mehr beteiligt und keine Neukompression).
Deshalb verstehe ich nicht, warum du erst mal mit Verlusten nach DivX komprimierst, dann durch AviSynth die DivX-Schnipsel wieder dekomprimierst, und zum Schluss noch mal neu komprimierst.
Verstehst Du mich jetzt?
Wenn du Video aus einem AviSynth-Skript mit Direct Stream Copy in ein AVI kopierst, dann wird in dem AVI unkomprimiertes Video sein - in dem Farbraum, der im AviSynth-Skript verwendet wurde (also bei ehemaligen DivX-AVIs meist ein neues riesiges YV12-AVI
Das mach ich ja nicht.
Viele Grüße
osirus
Also noch mal von vorn: Deine Ausgangslage sind Videos verschiedener Formate. Daraus willst du jeweils Stückchen ausschneiden, und am Ende alle Stückchen hintereinander als ein Video haben?
Ja, wie gesagt: Möglichst alles von AviSynth erledigen lassen! Videos im Original öffnen, Bereiche ausschneiden, zu einem Gesamtclip zusammenfügen, komplett in DivX encodieren.
Ich schlag einfach mal ein Skript vor (so als Diskussionsgrundlage):
clip1 = AviSource("video1.avi").Trim(125, 8456).SpezialFilterFuerVideo1()
clip2 = AviSource("video2.avi").Trim(93, 7834).SpezialFilterFuerVideo2()
clip3 = AviSource("video3.avi").Trim(276, 13846).SpezialFilterFuerVideo3()
clip4 = AviSource("video4.avi").Trim(652, 9354).SpezialFilterFuerVideo4()
return clip1 ++ clip2 ++ clip3 ++ clip4Die Zwischenclips erst mal als DivX einzeln zu codieren, ist anscheinend die Ursache von Problemen, weil die sich nicht so einfach von VirtualDub zusammenfügen lassen; und wenn man sie mit AviSynth öffnen und verbinden würde, hätte man durch die Konvertierung in DivX zwischendurch erheblich Qualität verloren -- was zu vermeiden wäre.
Eigentlich will ich ein Programm, das mir den Farbraum eines Videos verrät (siehe meine ersten beiden Posts).
Das ist aber ziemlich nutzlos. DivX 3-6 oder XviD: Alles "MPEG-4 Advanced Simple Profile". Chroma-Subsampling 4:2:0, wie bei MPEG-4 üblich - unkomprimiert entspricht das am ehesten YV12. Insofern müssen eigentlich alle DivX-4-Videos mit der gleichen Bildfläche auch kompatibel zueinander sein.
Leider speichert Windows in AVIs auch noch, ob mal beim Komprimieren RGB, YUY2 oder YV12 in den Codec hineinkam (24, 16 oder 12 bit). Das ist bei MPEG-4 vollkommen irrelevant; trotzdem kann es ein Hinderungsgrund für das Zusammenfügen sein.
Ich will doch gar kein riesiges Video aus vielen Stückchen. Ich will aus zb 100-Ausgangsvideos einfach 100 Videos machen, die immer aus folgendem bestehen sollen:
Schnippsel aus Ausgangsvideo 1 + Ausgangsvideo 1 = Zielvideo1
Schnippsel aus Ausgangsvideo 2 + Ausgangsvideo 2 = Zielvideo2
...
Schnippsel aus Ausgangsvideo x ist dabei immer ein durch avisynth erzeugter Schnippsel aus Ausgangsvideo x, den ich mit VDub wieder ins das vermeintliche Ausgangsformat von Ausgangsvideo x enkodieren will.
Sicherlich eine Art Intro, so nach dem Motto: "Dieser selbstgedrehte Urlaubsfilm wird Ihnen präsentiert von ..." auf ein paar Best-of-Ausschnitten? Na, wenn du das unbedingt brauchst... ;D
Auf die Einstellung von RGB32 für manche der Videos bin ich halt nur durch brute-force try and error gekommen. Sprich ich hab den Schnippsel halt mal in alle möglichen Formate enkodiert und dann der Reihe nach versucht, welcher davon sich an das Ausgangsvideo anhängen lässt. Da dann der in RGB32 komrimierte Schnippsel sich anhängen lies, habe ich daraus gefolgert, dass dieses Ausgangsvideo auch in RGB32 kodiert sein musste (oder eben RGB32 nur fälschlicherweise im header stand? - weis nicht?)
Ja, jetzt ist etwa klar, was das Problem ist.
Also soweit ich weiß, konnte man diese Eigenschaft am besten in dem Dialog lesen, den man per Rechtsklick im Windows-Explorer und über den Menüpunkt "Eigenschaften" dieses Videos bekommt. Kann aber von der Windows-Version und den installierten Dateityp-Handlern abhängen (bei mir geht's nicht, kann mit der Verknüpfung zum VLC zusammenhängen).
Vielleicht hilft auch "abcAVI" beim Feststellen (evtl. sogar Patchen?) dieses - für MPEG-4-Videos zumindest - absolut nutzlosen Header-Eintrags in der AVI-Datei; bei unkomprimierten Videos mag dieses Feld ja nützlich sein, bei komprimierten aber überhaupt nicht.
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!