dvd2avi/mpeg2dec3 interlaced/progressive output

[Wilbert]

There is one thing which is bugging me for a long time.

Does mpeg2dec3 always return interlaced YV12 (even if the source *looks* progressive, i.e. the majority of the pal dvd's for example)? Related to this, can pal dvd streams be progressive, or are they always encoded as interlaced?

[SeeMoreDigital]

I'm glad you brought this up because it's linked to the reason why I'm trying to find a 'software media player' (http://forum.doom9.org/showthread.php?s=&threadid=73880)that can detect/play interaced video correctly!

Anyway, I have many PAL DVD's that are progressive (or at least they play progressivly). I'm not sure whether this helps or not but Nero's Recode2 seems to be able to detect interlaced and progressive Mpeg2 sources!

Cheers

[RB]

I'm sure one of the Mpeg2Dec3 developers (trbarry, Nic, Neuron2) can answer this but .... it is my understanding that Mpeg2Dec3 does no "conversion" on the color space when decoding. At least when looking briefly through the source code, the progressive_frame flag is retrieved and used in various places.

And yes, PAL streams can of course be progressive. I own many DVDs that are encoded progressive, but OTOH a lot that "look" progressive are encoded interlaced.

And interestingly enough, I now have seen a PAL DVD where all frames had the progressive_frame flag but it really was and looked interlaced, also used alternate scan and field DCT. I wonder what encoder can be set up like this? CCE surely can't. The video looked OK though in both software player and standalone, I couldn't see any obvious color problems.

[SeeMoreDigital]

Originally posted by RB
...And interestingly enough, I now have seen a PAL DVD where all frames had the progressive_frame flag but it really was and looked interlaced, also used alternate scan and field DCT. Yes, this is bloody annoying.

I've got some DVD's that rippers/encoders (such as DVDdecrypter, Recode2 etc) list the 6Ch AC3 stream as being 2Ch AC3!

But what can you do?

Cheers

[Wilbert]

Is it possible to output those flags to a text file. Thus

frame 1: progressive_frame
frame 2: progressive_frame
frame 3: interlaced_frame
etc.

Maybe Neuron2 could implement that?

[SeeMoreDigital]

I wish I had the knowledge to answer a question like that!

It's logical to think that generating genuine PAL progressive frames should be easier to do than with NTSC.

But I too would like to see a software player that could correctly identify the frame base. It might also be handy to have such a feature included in an 'file information tool' such as Gspot.

Cheers

[Guest]

Originally posted by Wilbert
Is it possible to output those flags to a text file. Thus

frame 1: progressive_frame
frame 2: progressive_frame
frame 3: interlaced_frame
etc.

Maybe Neuron2 could implement that? DVD2AVI is a glorified MPEG indexer. Depending on how far we wish to diverge from the known D2V file format, which is the result of the indexing, there are many useful things that can be indexed. The problem is that existing tools expect a certain index file format (D2V). In my recent work on DVD2AVIdg/MPEG2DEC3dg I've improved random access performance at the expense of modifying the frame digits (to encode whether they require the previous GOP to be decoded). But I also have an option to output compatible 1.76-style D2V files. We need to standardise on an *extendable* index file format, so that each new enhancement doesn't break existing tools. It's something I am thinking about.

BTW, my current worklist is here:

http://neuron2.net/misc/Work_List.html

[Guest]

Originally posted by Wilbert
Does mpeg2dec3 always return interlaced YV12 (even if the source *looks* progressive It does not convert the sampling so whatever is coded is delivered. The problem is that the per-frame progressive/interlaced flag is lost when the data leaves MPEG2DEC3 as an Avisynth "AVI".

If a conversion to 4:2:2 is required it should be done in MPEG2DEC3 itself, which should respect the flag. If a conversion is not required then you'd have to assume that all the frames in a clip are encoded as progressive or interlaced, and that the receiving application (e.g., a transcoder) can be configured appropriately. But how would you know how to configure the application?

This is a real monkey wrench in the idea of using YV12 all the way through the chain. I think it is safer to just deliver 4:2:2 from MPEG2DEC3, converting it based on the per-frame progressive flag.

[RB]

Originally posted by neuron2
I think it is safer to just deliver 4:2:2 from MPEG2DEC3, converting it based on the per-frame progressive flag.
I agree, but please make it optional. Some people may want to use filters that work faster/are only available in YV12. Hmmm... do you think something like this would be even possible:

Mpeg2Source("some.d2v",yuy2=false) # YV12 output
SomeFilter()
SomeOtherFilter()
Mpeg2YV12ToYUY2() # Mpeg2Dec3dg built-in conversion to YUY2

I think the problem will be to make the progressive flag available across the two functions and of course to make sure that the current clip comes from Mpeg2Dec3dg in the first place...

[Wilbert]

Hmmm... do you think something like this would be even possible: (...)
It might be possible, but it is not correct. YV12 filters (with the exception of deinterlacers) require progressive YV12. There are several possibilities:

1) trully interlaced YV12, which can be deinterlaced with any deinterlacer.

2) progressive encoded as interlaced YV12. This one is problematic. You should _always_ use the following avs script:

ConvertToYUY2(interlaced=true)
ConvertToYV12() # if you want to convert it back to progressive YV12

3) Progressive YV12. No problems.

4a) Mixed progressive-interlaced YV12. Where interlaced means trully interlaced. If (3) is not possible, (4a) is also not possible. This is also problematic. I guess deinterlacers need interlaced YV12. I don't know what to do in this case (in theory).

4b) Mixed progressive-interlaced YV12. Where interlaced means progressive encoded as interlaced. Also problematic. This one can be converted to progressive YV12 correctly (in principle).

4c) Mixed interlaced1-interlaced2 YV12. The former means progressive encoded as interlaced, and the latter means trully interlaced. I guess deinterlacers like kernetdeint treat this correctly?

Let me ask a dumb question again:

Does this progressive-flag mean progressive or 'progressive encoded as interlaced'? I got the feeling it means the latter, and that implies that only 1, 2 and 4c are relevant.

The remaining issue with 2 is the following: is there a faster way to do this conversion (without converting to YUY2 and back).

Sorry if I'm talking nonsense, but I would like to understand this some day :)

[Guest]

Originally posted by Wilbert
Does this progressive-flag mean progressive or 'progressive encoded as interlaced'? I got the feeling it means the latter, and that implies that only 1, 2 and 4c are relevant. ISO:

progressive_frame -- If progressive_frame is set to 0 it indicates that the two fields of the frame are interlaced fields in which an interval of time of the field period exists between (corresponding spatial samples) of the two fields. In this case the following restriction applies:
• repeat_first_field shall be zero (two field duration).
If progressive_frame is set to 1 it indicates that the two fields (of the frame) are actually from the same time instant as one another. In this case a number of restrictions to other parameters and flags in the bitstream apply:
• picture_structure shall be “Frame”
• frame_pred_frame_dct shall be 1
progressive_frame is used when the video sequence is used as the lower layer of a spatial scalable sequence. Here it affects the up-sampling process used in forming a prediction in the enhancement layer from the lower layer.

[Wilbert]

So, the answer is no (ie progressive encoded as interlaced is indicated by the interlace flag)?

A different question. What happens if you feed fielddeinterlace and kerneldeint with an YV12 stream of the form (4a) or (4c)? Does (4a) produce incorrect output?

[trbarry]

FWIW I personally believe (but can't prove) that if you properly deinterlace YV12 you can then do a progressive conversion to YUY2 if you choose, which gives slightly better chroma detail than just ConvertToYUY2(Interlaced=true).

The fly in this ointment is whether you can properly deinterlace any imbedded progressive frames without losing anything.

- Tom

[kassandro]

The discussion here is quite confusing to me. I was convinced for quite some time that interlaced yv12 is a flawed concept, because the the first chroma line corresponds to luma rows 0 and 2, while the second chroma line is for the luma rows 1 and 3. Thus the areas of subsequent chroma lines overlap in interlaced yv12, which clearly leads to a quality loss without any reward. Nevertheless I am equally convinced that european digital tv is always encoded as interlaced yv12 no matter what kind of material is broadcasted. One can see this from the fact that sometimes the bottom field of a progressive video moves to the next frame and generates combs. So far I thought that one has simply to ignore the difference between interlaced and non-interlaced yv12. Also inspection of the deinterlacer sources shows that the chroma planes are treated the same way as the luma plane, which means that there also the difference between both color spaces is ignored and frankly I don't know how to do better. Now I am
surprised about the following suggestion:
Originally posted by Wilbert

2) progressive encoded as interlaced YV12. This one is problematic. You should _always_ use the following avs script:

ConvertToYUY2(interlaced=true)
ConvertToYV12() # if you want to convert it back to progressive YV12

What can these conversions do any good?

[scharfis_brain]

this conversion will result in 2x4 pixel large chroma blocks, but they are smeared vertically.

i think, that the way, trbarry showed up would be clever.
deinterlace the yv12-ed chrom to progressive yv12 using a deinterlacer and mergechroma()

[kassandro]

Originally posted by scharfis_brain
this conversion will result in 2x4 pixel large chroma blocks, but they are smeared vertically.


It surprising that colors are still that good. The chroma is already quite thin in ordinary yv12 and now some additional blurring is done to pass from interlaced to non-interlaced yv12.



i think, that the way, trbarry showed up would be clever.
deinterlace the yv12-ed chrom to progressive yv12 using a deinterlacer and mergechroma()

Ah, I understand, you only deinterlace the chroma and leave the luma untouched. But then the deinterlacer should be purely spatial (no motion detection), because the chroma fluctuations caused by interlaced yv12 are motion independent.

[scharfis_brain]

thought over it.

a deinterlacer won't gain anything on progressive video that has interlaced YV12

(but i am not totally sure, wait until I've made some tests with that.
Interlaced YV12 really mixes up my brain)