Frage von Max Puille:Hi all,
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.
Alternativ auch mal das:
AVISource(;"mein video.avi", true, "YUY2")
ConvertToRGB24(;interlaced%true)
Antwort von Max Puille:
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)
