PDA

View Full Version : weird chroma blending with mpeg2dec3


Shalcker
10th April 2004, 06:48
I'm trying to backup a R2 "Tenshi ni Narumon" DVD (anime) and found a really weird problem... As output from MPEG2Source I get blended chroma (and separate chroma motion too), while luma remains perfectly clear and fine. I thought that maybe it was error in a source, but the weirdest thing is that I get no such artifacts from either DirectShowSource (using PowerDVD decoder) or MPEGSource (using Nic's mpegdecoder.dll) - everything is perfectly fine there, with chroma following luma as it should in interlaced parts and remaining non-blended at progressive parts.

Both mpeg2dec3 and mpeg2dec3dg show this effect.

here is m2v sample (~6MB) (http://animeburg.omake.ru/download/sample.zip) that shows this effect.

Is there any way to fix that? Since both DirectShowSource and MPEGSource often has other problems i'd prefer to use MPEG2Source, but this chroma blending is really awful...

Ark
10th April 2004, 09:08
There should be a "chroma delay" function in Avisynth if I remember well, that allows you to solve that weird problem.

Look at the Avisynth documentation for more info.

Shalcker
10th April 2004, 14:07
Originally posted by Ark
There should be a "chroma delay" function in Avisynth if I remember well, that allows you to solve that weird problem.

Look at the Avisynth documentation for more info.
Ummm... Looked and can't find that... :(

The thing is, output from MPEG2Source contains _blended_ chroma. Not delayed. Sometimes chroma moves before luma motion, sometimes remains a bit after luma motion, sometimes both. So this will require some kind of chroma unblending... and then synching "unblended" chroma to luma... which doesn't seems to be easy task.

MPEGDecoder decodes everything almost perfectly when used without any other filters, but anything requiring seeking (like Decomb, for example) results in the same buggy output as from MPEG2Source. Maybe this "proper" output is result of some kind of bug in MPEGDecoder... but i'd like to keep it :)

Any suggestions? :)

Here is a few frames to show difference between output of MPEGSource and MPEG2Source
(cropped, separated by luma and chroma, same sequence, no other filters):
MPEGDecoder.jpg (200k) (http://animeburg.omake.ru/download/MPEGDecoder.jpg) (MPEGDecoder.png (800k)) (http://animeburg.omake.ru/download/MPEGDecoder.png)
MPEG2Source.jpg (200k) (http://animeburg.omake.ru/download/MPEG2Source.jpg) (MPEG2Source.png (800k)) (http://animeburg.omake.ru/download/MPEG2Source.png)

Mug Funky
10th April 2004, 15:14
please post script?

if you're converting to RGB then you'd concievably get this problem.

also if you're using postprocessing in mpeg2dec you'll possibly get blurring happening.

try Mpeg2Source("blah.vob", cpu=0) and see if the problem persists.

it's a chroma sampling problem - if mpeg2source doesn't know about interlacing then the postprocessing might b0rk (hmmm... i thought it was interlace-aware, but if the source is encoded as progressive then mpeg2source wont catch the interlacing and will postprocess it as progressive)

Shalcker
10th April 2004, 15:32
Originally posted by Mug Funky
please post script?

if you're converting to RGB then you'd concievably get this problem.

also if you're using postprocessing in mpeg2dec you'll possibly get blurring happening.

try Mpeg2Source("blah.vob", cpu=0) and see if the problem persists.

it's a chroma sampling problem - if mpeg2source doesn't know about interlacing then the postprocessing might b0rk (hmmm... i thought it was interlace-aware, but if the source is encoded as progressive then mpeg2source wont catch the interlacing and will postprocess it as progressive)
Base script used consists ONLY from
MPEG2Source("sample_x.d2v")
or
MPEGSource("sample.m2v")

No postprocessing are enabled. Changing MPEG2Source("sample_x.d2v") to MPEG2Source("sample_x.d2v", cpu=0) makes no difference.

For "screenshots" was used this script

#src = MPEG2Source("sample_x.d2v")
src = MPEGSource("sample.m2v")
function CropX(clip clp)
{ return clp.Crop(200,(18+18)*8,-200,-0*8) }
function CrX(clip clp)
{
xb = BlankClip(clp,color=$000000)
xw = BlankClip(clp,color=$F08080)

crm = clp.MergeLuma(xw).CropX
lum = clp.MergeChroma(xb).CropX
clp = clp.CropX
return StackVertical(clp,lum,crm)
}
return src.CrX

It was saved separately as image sequence for each case and then "united" into one picture manually.

Well, obviously if I'm viewing script in VirtualDubMod it probably gets converted to RGB somewhere... but converting to RGB in AviSynth makes little difference - chroma is still misplaced.

Dreassica
10th April 2004, 17:05
I can see it even if u load d2v directly into an app like tmpgenc. Using avs scipt with mpegdecoder doesnt show it in tmpgenc.
Something else then mpeg2dec taht causes it? like dvd2avi?

Mug Funky
11th April 2004, 16:09
that's peculiar. just downloading the clippy to see what i can find.

[edit]
chroma blending appears with both mpegsource and mpeg2source (dg fix).

i used mpegsource to generate the d2v, but i'm sure that has nothing to do with it.

just about to test with directshowsource

[edit edit]
bugger it, it looks like i've b0rked mpeg-2 playback in directshow for the 50th time (yay!). but i'm 98% sure it's a problem with the original stream, as the problem gets worse, not better if i swap chroma fields with respect to luma fields (which i suspected was the problem).

you're most likely stuck with it. i'd check again whether this shows up with your directshow decoder.

it looks to me like something that happened before encoding, not after decoding.

mf
11th April 2004, 16:23
Chroma upsampling? Mug Funky, this doesn't have anything to do with chroma upsampling. If luma is progressive and chroma is interlaced, something went wrong at decoding time. Most likely badly written field repeat flags in the D2V file, possibly from a strange bitstream that DVD2AVI has troubles with.

Mug Funky
11th April 2004, 18:44
yah, i made that guess before looking at the video. there's definitely something odd going on though. it's not cleanly interlaced chroma, but rather blended strangely between fields.

i don't know enough about this source or the equipment used to encode it to say what's wrong. i can't imagine a repeat-field flag applying only to luma or chroma channels and still being decoded without error (ie, without being rejected outright as non compliant).

dammit, i wish i could get mpeg-2 to play in directshow. it's always crapping out on me.

hmm. even running the stream through ReStream, and loading with TMPGenc's decoder (not d2v), and even nic's ReJig, i still get these effects.

i can't see how powerDVD could fail to show this problem, but then i can't get mine working so...