ich fange grade mit dem Thema Videocapture an (;nach einigem rumlesen, u.a. hier) und bin für den Anfang eigentlich recht zufrieden. Cinergy 400 TV, Aufnahme mit VirtualVCR, PICVideo MJPEG: AVI in absolut zufriedenstellender Qualität, keine framedrops, lippensynchrones Audio. Problem: wenn ich versuche, daraus mit TMPGEnc (;beta 12a) ein MPEG-2 zu machen (;DVD-PAL-template), wird das Ganze viel zu hell. So hell, daß versuchsweises Runterdrehen der Helligkeit eine Einstellung von -60 für die Brightness (;basic color correction) erfordert, um im resultierenden MPEG den etwa gleichen Helligkeitseindruck zu ergeben. System: XP (;kein SP) mit DirectX 9.0 Hardware: Athlon 3000 , ASUS A7N8X Deluxe Grafik: G-Force FX5600 Der YUV->RGB "Bug" des Codecs scheint's nicht zu sein, dazu ist die Helligkeitsänderung viel zu ausgeprägt. Interessanterweise tritt der Effekt nie beim Betrachten des AVI auf, sondern erst nach der MPEG-Konversion (;egal ob per Direkteinlesen vom File oder per Frameserving von VirtualDub). Hat irgendjemand einen Tip? MfG Max
-- When you are a Bear of Very Little Brain, and you Think of Things, you sometimes find that a Thing which seemed very Thingish inside you is quite different when it gets out into the open and has other people looking at it. (;Winnie the Pooh)
Antwort von Ottfried Schmidt:
On Fri, 12 Mar 2004 09:54:19 0100, Max Puille wrote:
>Der YUV->RGB "Bug" des Codecs scheint's nicht zu sein, dazu ist die >Helligkeitsänderung viel zu ausgeprägt. Interessanterweise tritt der >Effekt nie beim Betrachten des AVI auf, sondern erst nach der >MPEG-Konversion (;egal ob per Direkteinlesen vom File oder per >Frameserving von VirtualDub). >Hat irgendjemand einen Tip?
Genau genommen hat der Codec keinen YUV->RGB-Bug. Er interpretiert den Umgang mit dem Farbraum nur anders, als manche das gerne hätten. Wahrscheinlich liegt bei Dir das Video bereits mit der Luma-Range von 16-235 vor, wie sie auch für MPEG-Videos genutzt wird. Ist dem so, muss in TMPGEnc unter Setting->Quantize matrix die Option "Output YUV data as Basic YCbCr not CCIR601" aktiviert werden, da sonst die Luma-Range nochmals komprimiert wird. Ein strahlendes Weiß hätte dann bereits den Wert von 219, schwarz läge dann bei 32.
Antwort von Max Puille:
Hallo Otfried,
Ottfried Schmidt schrieb: > On Fri, 12 Mar 2004 09:54:19 0100, Max Puille > wrote: > >>Der YUV->RGB "Bug" des Codecs scheint's nicht zu sein, dazu ist die >>Helligkeitsänderung viel zu ausgeprägt. Interessanterweise tritt der >>Effekt nie beim Betrachten des AVI auf, sondern erst nach der >>MPEG-Konversion (;egal ob per Direkteinlesen vom File oder per >>Frameserving von VirtualDub). >>Hat irgendjemand einen Tip? > > Genau genommen hat der Codec keinen YUV->RGB-Bug. Er interpretiert den > Umgang mit dem Farbraum nur anders, als manche das gerne hätten. > Wahrscheinlich liegt bei Dir das Video bereits mit der Luma-Range von > 16-235 vor, wie sie auch für MPEG-Videos genutzt wird. Ist dem so, > muss in TMPGEnc unter Setting->Quantize matrix die Option "Output YUV > data as Basic YCbCr not CCIR601" aktiviert werden, da sonst die > Luma-Range nochmals komprimiert wird. Ein strahlendes Weiß hätte dann > bereits den Wert von 219, schwarz läge dann bei 32.
Tja, leider ist's das nicht, soweit ich das bisher beurteilen kann. Eine exakte Analyse der Farbwerte habe ich noch nicht vornehmen können, aber ein Umstellung dieses Parameters in TMPGEnc beseitigt den Fehler leider nicht. MfG Max
-- When you are a Bear of Very Little Brain, and you Think of Things, you sometimes find that a Thing which seemed very Thingish inside you is quite different when it gets out into the open and has other people looking at it. (;Winnie the Pooh)
Antwort von Ottfried Schmidt:
On Fri, 12 Mar 2004 11:40:52 0100, Max Puille wrote:
>Tja, leider ist's das nicht, soweit ich das bisher beurteilen kann. Eine >exakte Analyse der Farbwerte habe ich noch nicht vornehmen können, aber >ein Umstellung dieses Parameters in TMPGEnc beseitigt den Fehler leider >nicht.
Tja, eine andere Möglichkeit, die Farben bzw. die Helligkeit so zu verfälschen gibt es aber zumindest beim Direkteinlesen des Videos mit TMPGEnc nicht. Außer vielleicht der, dass sich bei Dir irgendein anderer Codec für die YUY2- und RGB-Ausgabe anstelle des normalen System-Codecs für diesen Zweck eingeschlichen hat, der Mist baut. Das würde dann auch erklären, warum die AVIs normal sind, das neu encodete Material aber nicht.
Aber nur, um sicher zu gehen: Bist Du sicher, dass die MPEGs tatsächlich zu hell encodet und nicht einfach nur von Deinem Player zu hell wieder gegeben werden?
Antwort von Max Puille:
Ottfried Schmidt schrieb: > On Fri, 12 Mar 2004 11:40:52 0100, Max Puille > wrote: > >>Tja, leider ist's das nicht, soweit ich das bisher beurteilen kann. Eine >>exakte Analyse der Farbwerte habe ich noch nicht vornehmen können, aber >>ein Umstellung dieses Parameters in TMPGEnc beseitigt den Fehler leider >>nicht. > > Tja, eine andere Möglichkeit, die Farben bzw. die Helligkeit so zu > verfälschen gibt es aber zumindest beim Direkteinlesen des Videos mit > TMPGEnc nicht. Außer vielleicht der, dass sich bei Dir irgendein > anderer Codec für die YUY2- und RGB-Ausgabe anstelle des normalen > System-Codecs für diesen Zweck eingeschlichen hat, der Mist baut. Das > würde dann auch erklären, warum die AVIs normal sind, das neu encodete > Material aber nicht.
Das habe ich mir vorhin auch überlegt, muß ich mal checken. Der MJPEG-Codec bietet ja die Möglichkeit der Einstellung als "primärer" Codec - nur ist die disabled weil er wohl kein anderes MJPEG-Codec findet.
> Aber nur, um sicher zu gehen: Bist Du sicher, dass die MPEGs > tatsächlich zu hell encodet und nicht einfach nur von Deinem Player zu > hell wieder gegeben werden?
Leider werden die MPEGs nach dem Brennen als DVD vom Standalone auch zu hell wiedergegeben - ich bin mir also *ziemlich* sicher. Mir ist noch eine dritte Möglichkeit eingefallen: ist es denkbar, daß irgendein DirectX-Trick dabei eine Rolle spielt? Könnte ja theoretisch sein, daß "richtig" aussehende AVI ist bereits vom Wiedergabesystem zurechtgerechnet, was beim Encoden dann wegfiele. Mir fällt allerdings im Moment kein Erklärung dafür ein, daß es im frameserving-Mode dann genausowenig funktioniert. MfG Max
-- When you are a Bear of Very Little Brain, and you Think of Things, you sometimes find that a Thing which seemed very Thingish inside you is quite different when it gets out into the open and has other people looking at it. (;Winnie the Pooh)
Antwort von Ottfried Schmidt:
On Fri, 12 Mar 2004 14:01:23 0100, Max Puille wrote:
>Leider werden die MPEGs nach dem Brennen als DVD vom Standalone auch zu >hell wiedergegeben - ich bin mir also *ziemlich* sicher.
Nun, dann passiert's wohl wirklich beim Encoden. Nun weiß ich aber definitiv, dass TMPGEnc sowas nicht von sich aus macht.
>Mir ist noch eine dritte Möglichkeit eingefallen: ist es denkbar, daß >irgendein DirectX-Trick dabei eine Rolle spielt? Könnte ja theoretisch >sein, daß "richtig" aussehende AVI ist bereits vom Wiedergabesystem >zurechtgerechnet, was beim Encoden dann wegfiele.
Das meinte ich ja, als ich die System-Codecs erwähnte. Es ist durchaus möglich, dass bei der Wiedergabe andere Systeme genutzt werden als bei der Übergabe an ein anderes Programm. TMPGEnc verlangt z.B. zwingend RGB-Video als Source. Wenn ein Codec jetzt aber z.B. nur YV12 oder YUY2 liefern kann, dann sucht Windows intern nach einem Codec, der die Wandlung nach RGB durchführen kann - welcher das dann ist, hängt vom jeweiligen PC bzw. davon, was darauf an Codecs installiert ist, ab.
>Mir fällt allerdings im Moment kein Erklärung dafür ein, daß es im >frameserving-Mode dann genausowenig funktioniert.
Auch VirtualDub benötigt RGB...
Du kannst ja mal AVISynth installieren (;2.5x). Als Skript dann das hier:
AVISource(;"mein video.avi", true, "RGB24")
Das dann mal anstelle des Videos mit TMPGEnc öffnen.
Ottfried Schmidt schrieb: > On Fri, 12 Mar 2004 14:01:23 0100, Max Puille > wrote: > >>Leider werden die MPEGs nach dem Brennen als DVD vom Standalone auch zu >>hell wiedergegeben - ich bin mir also *ziemlich* sicher. > > Nun, dann passiert's wohl wirklich beim Encoden. Nun weiß ich aber > definitiv, dass TMPGEnc sowas nicht von sich aus macht.
Muß man "nur noch" rausfinden, wer der Böse ist. Aber das schränkt die Möglichkeiten schon mal ein Stück weit ein.
>>Mir ist noch eine dritte Möglichkeit eingefallen: ist es denkbar, daß >>irgendein DirectX-Trick dabei eine Rolle spielt? Könnte ja theoretisch >>sein, daß "richtig" aussehende AVI ist bereits vom Wiedergabesystem >>zurechtgerechnet, was beim Encoden dann wegfiele. > > Das meinte ich ja, als ich die System-Codecs erwähnte. Es ist durchaus > möglich, dass bei der Wiedergabe andere Systeme genutzt werden als bei > der Übergabe an ein anderes Programm.
Das dürfte der Knackpunkt sein.
> TMPGEnc verlangt z.B. zwingend RGB-Video als Source. Wenn ein Codec > jetzt aber z.B. nur YV12 oder YUY2 liefern kann, dann sucht Windows > intern nach einem Codec, der die Wandlung nach RGB durchführen kann - > welcher das dann ist, hängt vom jeweiligen PC bzw. davon, was darauf > an Codecs installiert ist, ab.
RGB ist nicht das Problem, denke ich: auch das kann ich ja testen, indem ich beim Codec "Force YUV Output" einstelle. Ist das der Fall, streikt VirtualDub (;mit TMPGEnc nicht getestet), was mir sagt, daß eine Zwischendekodierung nicht durchgeführt wird - oder sucht Windows in dem Fall aus irgendeinem Grund nicht?
>>Mir fällt allerdings im Moment kein Erklärung dafür ein, daß es im >>frameserving-Mode dann genausowenig funktioniert. > > Auch VirtualDub benötigt RGB...
...und stellt das AVI in völlig korrekten Farben dar, wie übrigens auch TMPGEnc im Preview.
> Du kannst ja mal AVISynth installieren (;2.5x). Als Skript dann das > hier: > > AVISource(;"mein video.avi", true, "RGB24") > > Das dann mal anstelle des Videos mit TMPGEnc öffnen. > > Alternativ auch mal das: > > AVISource(;"mein video.avi", true, "YUY2") > ConvertToRGB24(;interlaced%true)
OK, das wird dann Versuch 3. Versuch 1 wird erstmal eine gründliche Überprüfung der installierten Codecs bzw. eventuell zu ändernder Einstellungen im DirectX. Versuch 2 wird die Verwendung von HuffYuv 2.2. Ich werde berichten. MfG Max
-- When you are a Bear of Very Little Brain, and you Think of Things, you sometimes find that a Thing which seemed very Thingish inside you is quite different when it gets out into the open and has other people looking at it. (;Winnie the Pooh)
Antwort von Max Puille:
Hallo,
nur 'ne kurze Rückmeldung für den Fall, daß es mal jemanden interessiert: das Problem war zweiteilig. Teil 1 war die YUV->RGB Konversion - die Option "Output YUV data as Basic YCbCr not CCIR601" in TMPGEnc hat das beseitigt. Teil 2 war eine hardwareseitige MPEG2-Dekompressions-"Unterstützung" durch meine GraKa, die den MPEG2-Stream wesentlich heller darstellte als er in Wirklichkeit war. An der Stelle mal ein lautstarkes "DANKE" an alle hier, die uns newbies mit Infos versorgen (;in dem Fall besonders Ottfried, aber ich frag' bestimmt nochmal was Blödes). MfG Max
-- When you are a Bear of Very Little Brain, and you Think of Things, you sometimes find that a Thing which seemed very Thingish inside you is quite different when it gets out into the open and has other people looking at it. (;Winnie the Pooh)
