Interlaced YV12 to progressive YV12

[wonkey_monkey]

What's the simplest/least lossy/technically correct way to convert interlaced YV12 (edit: that is to say, progressive video which has been encoded as interlaced, with interlaced chroma placement) to properly progressive YV12?

[Gser]

It's a bit baffling that you joined here in 2004 and yet have not heard of deinterlacing. QTGMC (https://forum.doom9.org/showthread.php?t=156028) is quite a nice filter for that. And I do take issue with "simplest/least lossy/technically", If you want simple and least lossy you can just weave video but that will give you a mess, and there is no "technically correct way", only ways that produce less pleasant results, and ways that produce more pleasant results. As with most complex filters you will find that pleasant results take a long time.

I am also sure this question has been asked here for about a million times.

[wonkey_monkey]

It's a bit baffling that you automatically assume I don't know what I'm talking about rather than asking me to clarify. Maybe I should have explained more clearly to avoid anyone jumping to conclusions. I just couldn't see the incorrect reading of my question as I already knew what I meant, and at the time I couldn't think of anything that needed adding.

The video in question is not interlaced, per se, but it has been encoded as interlaced, so the chroma placement is interlaced. I want to convert the chroma placement to progressive, but with as little conversion loss as possible.

converttoyv24(interlaced=true).converttoyv12(interlaced=false)

would be one way of doing it, but will resample twice, and in two directions, with the horizontal resample being unnecessary.

[johnmeyer]

Gser, it is amazing that you aren't smart enough to understand what was actually being asked, nor do you seem to know who davidhorman is and what his past contributions have been. However, great job being snarky. You've got that skill perfected.

David, I wish I could do more than come to your defense. It sounds like the chroma needs to be shifted, but only on one field. Your "as little conversion loss as possible" is probably not possible, since you are going to have to re-encode. Without a sample, I can't know for sure how to fix it, but if the chroma is only bad on one field you might be able to do a dumb bob:

bob(0.0,1.0)

then separate the chroma and luma, and finally take the chroma from the good field and merge it with the adjacent bad field. The chroma will obviously not match perfectly, but may be far less objectionable than what you have. You then reassemble the video with either

separatefields().selectevery(4,1,2).weave()

or

separatefields().selectevery(4,0,3).weave()

depending on original field order.

Hopefully this will spark some other ideas.

[wonkey_monkey]

The chroma isn't bad, it's just interlaced - so the first line of chroma belongs to the first and third lines of luma, the second line of chrome belongs to the second and fourth lines of luma, and so on. It should be resampled so that (roughly) the first line of chroma belongs to the first and second lines of luma, and the second line of chroma belongs to the third and fourth lines of luma. I'm just not sure what the maths should be.

[Asmodian]

Don't you have to go through 4:2:2 to get progressive YV12 from interlaced YV12?

I think this should be pretty close to lossless horizontally:

converttoyv24(interlaced=true,chromaresample="point").converttoyv12(interlaced=false, chromaresample="linear")

Edit: It should also keep vertical blur as low as possible, though I am not sure chromaresample="linear" is needed in the coverttoyv12.

[wonkey_monkey]

Thanks Asmo, I gave that a try but it seems to blur horizontally more than vertically. It also introduces a 1-pixel downward shift which isn't present if I take out the chromaresample="point" from the first call (it should be "bilinear" for the second call). It does get rid of residual interlacing though.

[mkver]

Wouldn't it be better and easier to first convert to YV16 (not YV24) to avoid horizontal blur?

[MrVideo]

I've run into the same situation because of the Blu-ray camp's infinite wisdom (i.e., stupidity) in not having 25p as part of the specification. Only allowing 25i was, IMHO, stupid. That forces those that produce programming in 25p to have to convert to 25i. Did I mention this was stupid?

So, as a test, I used
converttoyv16(interlaced=true).converttoyv12(interlaced=false, chromaresample="bilinear")
in an AVS script and the result on a 4 min test video was really great looking, using x264 two-pass.

Thanks for the above posts from fellow forum members. The timing of this thread was perfect.

[real.finder]

can we have samples for this case?

[Sharc]

..... That forces those that produce programming in 25p to have to convert to 25i....
Not necessarily. In such case they could still encode as 25p and flag it as interlaced with --fake-interlaced in x264.

[MrVideo]

can we have samples for this case?
Who from?

[MrVideo]

Not necessarily. In such case they could still encode as 25p and flag it as interlaced with --fake-interlaced in x264.
Ah right. Forgot about that option. Assuming, of course, that they used x264.

The point was that 25p should have been allowed in the first place. Now they have to play games. I wish I knew the logic behind that decision.

[wonkey_monkey]

I've run into the same situation because of the Blu-ray camp's infinite wisdom (i.e., stupidity) in not having 25p as part of the specification. Only allowing 25i was, IMHO, stupid. That forces those that produce programming in 25p to have to convert to 25i. Did I mention this was stupid?


It's not stupid - 25p would be completely redundant because (such is my understanding) the codecs all allow any macroblock to be flagged as progressive. Edit: I don't think MPEG2 does but if you're using that to encode a progressive blu-ray video you've got bigger troubles.

Effectively, it is in the spec.

[real.finder]

Who from?

anyone or better everyone

[MrVideo]

It's not stupid - 25p would be completely redundant because (such is my understanding) the codecs all allow any macroblock to be flagged as progressive. Edit: I don't think MPEG2 does but if you're using that to encode a progressive blu-ray video you've got bigger troubles.

Effectively, it is in the spec.
AIUI, the video has be be flagged as interlaced. As mentioned above, if x264 was used as the encoder, then the fake it flag could be used. If not, then the 25p chroma has to be messed with when encoding to 25i (frames, not fields). If 25p were allowed, then the chroma would be a little better off. By having both 25i and 25p in the spec, then true 25i video sources would be included, as they are now. Just my personal observation. I could be way off base. :eek:

Hopefully the encodings for Blu-ray would be from 4:2:2, or 4:4:4 edited masters, improving the conversion to 4:2:0 interlaced, or progressive, encoding.

In any event, the above AVISynth script code segment seems to work really well to get 25p video from Blu-ray 25i video.

It is all water under the bridge anyway. Actually in an area west of where I live, the water under the bridge took out the bridge. Record rainfall yesterday overflowed the creek, closing a portion of US14.

[MrVideo]

anyone or better everyone
OK, here is my video sample (http://vidiot.com/video/Video.Sample.1080i25.30sec.ts). (83MB)

[Asmodian]

Thanks Asmo, I gave that a try but it seems to blur horizontally more than vertically. It also introduces a 1-pixel downward shift which isn't present if I take out the chromaresample="point" from the first call (it should be "bilinear" for the second call). It does get rid of residual interlacing though.

It is odd there is a shift if you use point resize, maybe bilinear or bicubic is better there too.

Wouldn't it be better and easier to first convert to YV16 (not YV24) to avoid horizontal blur?

YV16 is 4:2:2, isn't it? That would be better. Or YUY2. :o

[hello_hello]

AIUI, the video has be be flagged as interlaced. As mentioned above, if x264 was used as the encoder, then the fake it flag could be used. If not, then the 25p chroma has to be messed with when encoding to 25i (frames, not fields). If 25p were allowed, then the chroma would be a little better off. By having both 25i and 25p in the spec, then true 25i video sources would be included, as they are now. Just my personal observation. I could be way off base. :eek:

The Wikipedia page on "progressive segmented frames" implies they can, or should be encoded as progressive, but I don't really understand how that works.

Anyone know how the decoder tells the difference between a PsF frame and an interlaced one, in respect to chroma sub-sampling, and/or if de-interlacing is required?

https://en.wikipedia.org/wiki/Progressive_segmented_frame#Video_recorders

Most video formats including professional ones utilize chroma subsampling to reduce amount of chroma information in a video, taking advantage of the human visual system's lower acuity for color differences than for luminance.[11] Such a reduction improves compression of the video signal, which is always desirable because of storage and transmission limitations. To ensure compatibility with interlaced-based systems, chroma information in PsF video is sometimes recorded in interlaced format, despite that the content is progressive. This may result in interlaced artifacts being noticeable on colored objects.

[wonkey_monkey]

AIUI, the video has be be flagged as interlaced. As mentioned above, if x264 was used as the encoder, then the fake it flag could be used. If not, then the 25p chroma has to be messed with when encoding to 25i (frames, not fields). If 25p were allowed, then the chroma would be a little better off. By having both 25i and 25p in the spec, then true 25i video sources would be included, as they are now. Just my personal observation. I could be way off base. :eek:

https://www.afterdawn.com/glossary/term.cfm/macroblock-adaptive_frame-field_coding

If done right (and I don't exactly what --fake-interlaced does) using MBAFF will be exactly the same as 25p, so that's why it's not specified separately.

[Groucho2004]

I don't exactly what --fake-interlaced doesIt's just a flag in the video stream telling the playback device to treat it as interlaced. It doesn't necessarily mean that the stream is interlaced.

[MrVideo]

Most video formats including professional ones utilize chroma subsampling to reduce amount of chroma information in a video, taking advantage of the human visual system's lower acuity for color differences than for luminance.[11] Such a reduction improves compression of the video signal, which is always desirable because of storage and transmission limitations. To ensure compatibility with interlaced-based systems, chroma information in PsF video is sometimes recorded in interlaced format, despite that the content is progressive. This may result in interlaced artifacts being noticeable on colored objects.
Strange. Don't professional video cameras record 4:2:2, or better yet, 4:4:4? Or even better yet, a video format that yields the best for video editing during post production? I've never really dug into professional video gear.

I'd love to have an 8K camera and the video editing gear to go along with it. I'd have to win Powerball, or MegaMillions, in order for that to happen. :D

[MrVideo]

https://www.afterdawn.com/glossary/term.cfm/macroblock-adaptive_frame-field_coding

If done right (and I don't exactly what --fake-interlaced does) using MBAFF will be exactly the same as 25p, so that's why it's not specified separately.
OK, thanks for the update.

[mkver]

https://www.afterdawn.com/glossary/term.cfm/macroblock-adaptive_frame-field_coding

If done right (and I don't exactly what --fake-interlaced does) using MBAFF will be exactly the same as 25p, so that's why it's not specified separately.
A H.264 SPS (Sequence Parameter Set; this is the place where several encoding parameters that are not allowed to change on a frame-per-frame basis are transmitted (because transmitting it with each frame would be a waste of bits)) contains one or two parameters that influence the encoding mode: frame_mbs_only_flag and mb_adaptive_frame_field_flag.
If frame_mbs_only_flag is 1, then there are only coded frames, no fields, and all these frames are encoded with frame macroblocks.
If frame_mbs_only_flag is 0, then there may be coded frames and coded fields. In this case mb_adaptive_frame_field_flag is present and if set to 1, the encoding mode is MBAFF (Macroblock-Adaptive Frame-Field Coding -- slow-moving (e.g. background) parts of interlaced material can be more efficiently encoded as if it were progressive whereas it's the opposite for fast moving parts (e.g. faces); with MBAFF a part of a picture can be encoded with frame macroblocks (as if it were progressive) and other parts with field macroblocks). If mb_adaptive_frame_field_flag is 0, then it is PAFF (Picture-adaptive frame-field coding). Both PAFF and MBAFF allow coded fields as well as coded frames, but in PAFF mode all coded frames have only frame macroblocks.
Neither PAFF nor MBAFF nor frame_mbs_only_flag set to 1 automatically flag the content as progressive or interlaced (and even if it is flagged as progressive or interlaced, this needn't be true); indeed, in all cases (even frame_mbs_only_flag == 1) coded frames can be flagged as interlaced or progressive on a frame-by-frame basis depending on which field is to be shown first. (The frame-by-frame variation is coded via delta_pic_order_cnt_bottom or delta_pic_order_cnt[1]; of course, these needn't explicitly given in the frames, but can be given default values.)

After this background, what does x264 do with fake-interlaced? It uses PAFF mode and uses only frame pictures (which contain only frame encoded macroblocks). Said frames are coded progressively. It moreover sets the display time of both fields of these frames to the same value (it sets bottom_field_pic_order_in_frame_present_flag in the PPS (another place where several encoding parameters that are valid for more than one frame are kept) so that the individuals frames don't even have delta_pic_order_cnt_bottom elements, but the default value indicating that the display time of both fields being the same applies. That way the overhead of fake-interlaced is pretty much negligible: Every frame header (or actually every slice header) contains a (1 bit) flag that says that this slice is a coded frame, not a coded field. That's usually all (there is another downside: if frame_mbs_only_flag is 1, then the vertical frame dimensions are internally padded to mod 16; if the flag is 0, then every coded frame is vertically padded to mod 32; this can increase the bitrate by a bit more).
PAFF mode is better for this than MBAFF mode, because in he latter you would need to code whether the content is progressive or not at the macroblock level (i.e. more than once per coded frame) which would waste more bits.

Unfortunately, there doesn't seem to be a way to indicate that the content is progressive, but the croma is interlaced. There is chroma_sample_loc_type_top/bottom_field, but it can't be used for this purpose.

[Sharc]

Thank you for the explanations.
So with --fake-interlaced the chroma of progressive footage gets actually encoded as interlaced, right?

[mkver]

No, with --fake-interlaced one uses PAFF, but one encodes everything with frames and frame macroblocks and one signals that the display time of both fields encompassing the frame is the same which means that the frame is flagged as progressive. If the height of your video rounded up to the nearest multiple of 16 is actually a multiple of 32, then the decoded output of fake-interlaced and a normal no-interlaced encode coincide.
There is no flag in H.264 to tell that the content is progressive, but the chroma is interlaced.

[Sharc]

Ah I see. Thanks for clarification.