Still menu from interlaced video

[jeanl]

Guys,
I used MenuShrink on the Thomas Crown Affair (original one, 1968) R1, and the main menu is interlaced video. After MenuShrink processing, when watched on my DVD player, the resulting menu shows 2 slightly different pictures alternating rapidly (not the best you could ask for!).
I kind of understand what's going on, the top and bottom fields are shown in alternance at 60Hz, but I'm puzzled by the fact that the player does not handle that too well: If I pause an interlaced movie during playback, I get a nice steady de-interlaced frame, the player knows what to do. But apparently, for a still menu, the player does not use the same technique.

2 questions:
- Have you guys seen similar problems?
- What would be a good solution to avoid the problem (other than trying to pick a picture whose 2 fields are very similar)? I'm guessing there's no easy/simple way to repeat the first field and stuff that in the second one (primitive line-double so to speak)...

Thanks in advance for any suggestion...
Jeanl
EDIT: I went back to check more movies and found quite a bunch with interlaced videos in the menus! I didn't expect that. Spiderman1, Godzilla, and many others...

[arsmori]

Yeah, I got that a few times.

A non deinterlaced still will give an impression of movement in areas where there's differences between the two fields and is due I think to the CTR doing what it's suppose to do, i.e., alternating them (sorry for my non-tehcie babble). On a still it give a moiré effect, even if you say, display a still cap from some video footage and its scan lines doesn't correspond to the CTR real scan lines, if that still isn't deinterlaced you will get that effect.

Isn't implementing deinterlacing beyond the scope of MenuShrink? Sound complicated as you'll need to implement some discriminating routine to detect interlaced material and just doubling a field will surely screw the writing if any, right?

Frankly, I can live with that side-effect. Just need to screen the results and chose another still where it get real bad.

[mpucoder]

Most VCRs and DVD players when you press "pause" do a field still, both displayed fields are actually the same. They do it to avoid this very problem.
As for messing up the text, that could happen. But frames that are intended to be used as a still menu background will have thicker lines to avoid the flicker. Which makes me wonder if the chosen frame is the best in these cases.

There is not much that can be done about it without re-encoding. You might be able to choose a better frame by analysing the data a little. A non-progressive frame structure is a sure thing to avoid. But even progressive frames can have large differences between the fields. These will have a large percentage of field encoded macroblocks.

[jeanl]

Originally posted by mpucoder
Most VCRs and DVD players when you press "pause" do a field still, both displayed fields are actually the same. They do it to avoid this very problem.
As for messing up the text, that could happen. But frames that are intended to be used as a still menu background will have thicker lines to avoid the flicker. Which makes me wonder if the chosen frame is the best in these cases.

There is not much that can be done about it without re-encoding. You might be able to choose a better frame by analysing the data a little. A non-progressive frame structure is a sure thing to avoid. But even progressive frames can have large differences between the fields. These will have a large percentage of field encoded macroblocks.
mpucoder, you lost me here :)! There are progressive and non progressive frames? Can you explain, or point me in the right direction? I thought a video stream was either progressive or interlaced, and that didn't change in the middle...
Do you mean the way in which the frames are coded (i.e. coded as a full image, or each field separately - field-encoded I guess)?

jeanl

[mpucoder]

Well, if you have a copy of ISO 13818-2 it would help, if not you can get one at Neuron2's (http://www.neuron2.net/library/library.html)

A video sequence (not stream, there can be many sequences in a stream) can be progressive or non-progressive. This relates to how it is displayed, as fields or frames. A progressive sequence will contain only progressive frame pictures. DVD is non-progressive.

In non-progressive sequences, each picture can be a field or a frame. Each frame can be progressive or non-progressive. Most transfers from film are progressive frames, while television shows are not. The distinction at this level is whether the two fields are from the same instant in time, or temporally seperate. Only progressive frames can be pulled down.
But within each progressive frame picture the encoder has the choice of two DCT transforms, interlaced or progressive, at the macroblock (16x16 pixel) level.
Interlaced with whole-frame motion is best encoded as non-progressive frame pictures. Interlaced with small motion (a hand wave, or car moving through frame) is best encoded as progressive frame using interlaced macroblocks in the area of motion.
Interlaced with no motion is best encoded as progressive frames.
It is possible to use all three methods in one non-progressive sequence.

This is why it is difficult to determine if the original source was interlaced or not. It's like trying to determine the gender of a frog after being in a blender.

[jeanl]

Originally posted by mpucoder

This is why it is difficult to determine if the original source was interlaced or not. It's like trying to determine the gender of a frog after being in a blender.
sweet analogy! :D but I get your point! I'll do some reading! Thanks for the pointers...
jeanl

[Surf]

lmaoooo.

mpucoder just released the chicken mcnugget recipe unknowingly..

[mpucoder]

Really?
I don't know where I first heard the expression "frog in a blender" but I do remember it was about a hopeless situation - something about bringing it back to life. I often use the term after reading a long post about 12 or so wrong steps toward converting a DVD and the poster wants to know how to fix it.

Does Mickey-D's know that Fear Factor has served up this concoction?

[jeanl]

mpucoder, I read the ISO file you pointed out (well, not in its entirety! ;) ) but I still have one quick question prompted by your comment.
If the source is progressive to begin with, in what situation could you have a frame picture that's encoded as non-progressive? Is that because of the 2-3 pulldown?

I was hoping I could change one of the frame flags to instruct the decoder to output twice the same field, but it does not look like that's supported by the MPEG standard, right?

Finally, I'm guessing there's no simple way to separate the two fields in the encoded data and possibly replace the second one with the first one, right? (remember, in the current case, the image is an I-frame so at least we don't have to deal with motion vectors).

Jeanl

[mpucoder]

Originally posted by jeanl
mpucoder, I read the ISO file you pointed out (well, not in its entirety! ;) ) but I still have one quick question prompted by your comment.
If the source is progressive to begin with, in what situation could you have a frame picture that's encoded as non-progressive? Is that because of the 2-3 pulldown?
Pulldown, as we use it, requires a progressive frame picture in a non-progressive sequence, ie you are going from progressive (the picture structure) to interlaced (sequence type / display device).
The picture structure decision is made by the decoder based on a strategy that is intended to save bits or increase quality. There are some test examples, the one of interest is alternating black and white lines. It's hard to imagine a film having such high contrast (and perfect alignment) but if it did the most efficient encoding would be non-progressive. That eliminates all the AC components as you end up with a field of black, and a field of white. It's not real world, but there are real world situations where non-progressive is better.

I was hoping I could change one of the frame flags to instruct the decoder to output twice the same field, but it does not look like that's supported by the MPEG standard, right?Correct, the flags from one picture affect only the next display frame, and do not work at all in a still.

Finally, I'm guessing there's no simple way to separate the two fields in the encoded data and possibly replace the second one with the first one, right? (remember, in the current case, the image is an I-frame so at least we don't have to deal with motion vectors).Right again, but knowing what percentage of the frame is non-progressive could help choose better candidates for the still.

[jeanl]

OK, thanks for the clarification! That makes more sense now. In the example you give, the black/while line image would be best encoded as 2 separate fields, but whether these two fields are displayed simultaneously or not is a separate issue. That's what was confusing me.

In any case, it does not look like I can do much in MenuShink to improve the quality, except maybe in the automatic I-frame mode, where I could check the flags, to try to find a progressive frame structure. Looking inside the image data to look for interlaced/progressive macroblocks is probably more complicated than I'm willing to go!

Thanks!
Jeanl