Any news about a potential successor to VVC / H.266?

[rwill]

If memory serves me well, a "field-picture" encodes a pair of interlaced fields (top and bottom field). Basically, in MPEG-2, in interlaced mode, you can either have a picture encoded as a progressive frame or as a pair of fields. The first type of picture is useful for "fake interlace" (needed to get a 25p video on DVD-Video because DVD-Video doesn't support progressive mode for example) or for scenes with zero motion in true interlaced video, and the other is for scenes with motion in true interlaced video.

Note: when I say "true interlaced video" I mean the kind of interlaced video that would give you those annoying comb artifacts during motion if you tried to weave/overlay its field-pairs into frames.

If so, does it mean y262 can't encode true interlaced video?

You have not understood interlaced support in Mpeg-2.
y262 can encode interlaced content just fine.

[kurkosdr]

You have not understood interlaced support in Mpeg-2.
y262 can encode interlaced content just fine.
Then what are "field pictures"? Any hint?

[rwill]

Then what are "field pictures"? Any hint?

Well maybe I am the wrong one to answer that. As far as I know a field picture in the context of Mpeg-2 is a coded picture where picture_structure is equal to "Top field" or "Bottom field".

If you need more information: The whole internet is at your fingertips.

[hajj_3]

This thread should be integrated into this thread: https://forum.doom9.org/showthread.php?t=185662

[kurkosdr]

Well maybe I am the wrong one to answer that. As far as I know a field picture in the context of Mpeg-2 is a coded picture where picture_structure is equal to "Top field" or "Bottom field".

If you need more information: The whole internet is at your fingertips.
That's what the internet tells me, a "field picture" is basically a field. If you have a 720x576i50 video, a field picture will be a 720x288 picture to encode a field (either top or bottom). Because if you have motion in that particulate field-pair and try to weave the two fields into a 720x576 frame and encode it as a "frame picture", you'll get combing artifacts that will need lots of bitrate to compress without massive artifacting. So, better encode that field-pair it as two pictures 720x288 each in "field picture" mode, not "frame mode".

Anyway, have you tried true interlaced (with combing artifacts when you weave/overlay) with y262? How well does it perform, say at 4mbps for 720x576 during motion scenes?

[rwill]

Anyway, have you tried true interlaced (with combing artifacts when you weave/overlay) with y262? How well does it perform, say at 4mbps for 720x576 during motion scenes?

Well of course I have. It performs. I do not know how well because I had skipped the stuff with the reference.

[Asmodian]

Anyway, have you tried true interlaced (with combing artifacts when you weave/overlay) with y262?

I would not call that 'true interlaced'. I would call that treating interlaced video as progressive. It is never good. If a codec cannot encode as fields it is better to bob deinterlace than encode the two fields from different timepoints in the same frame.

[rwill]

I would call that treating interlaced video as progressive.

What kurkosdr described, with is own words, appears to be interlaced content. I do not know why you suddenly come along with treating it as progressive content. No one talked about that. Can you explain further?

[Asmodian]

I mean encoding an interlaced frame as a single picture with combing artifacts (treating it as a single progressive frame) results in much worse quality than encoding the two fields as seperate pictures and weaving during decode.

The combing artifacts are very sharp high frequency detail that does not work well with our lossy frequency domain compression methods. This is even worse when considering 4:2:0 chroma sampling.

[rwill]

I know this thread is originally about a H.266 successor but I just have to ask, do you guys have ever heard about field-based prediction in a frame picture in the context of Mpeg-2 video ?

I mean it all started with modus-ms325c where I had hopes he can tell me what features to add to y262 so it might see wider use, but I got disappointed.

Then kurkosdr and you came along and, if I understood you right, tried to argue that you need field pictures to encode interlaced content. But this is just not true, at least for Mpeg-2 video. I got disappointed again.

[benwaggoner]

The combing artifacts are very sharp high frequency detail that does not work well with our lossy frequency domain compression methods. This is even worse when considering 4:2:0 chroma sampling.
Yeah, interlaced-as-progressive is very common in the worst video on the internet. Very early YouTube, along with anamorphic-as-square and limited-range-as-full.

Interlaced was the whole point of 4:2:2, really. I'm not sure why it remains such a big deal in production and post for progressive-only titles. It seems like 4:2:0 or 4:4:4 should be used.

[Asmodian]

do you guys have ever heard about field-based prediction in a frame picture in the context of Mpeg-2 video ?

You mean adaptive field/frame compression? Changing between field or frame based encoding per-macroblock? My experiance (a long time ago now) was that this does not work as well for interlaced video compared to always using field pictures. I always got some blocks that should have been encoded field based, but were encoded frame based instead.

It might not be a big deal for y262 adoption, hopefully no one is encoding interlaced video today, but it is a feature I would want for encoding camcoder VHS tapes into MPEG2.

[benwaggoner]

You mean adaptive field/frame compression? Changing between field or frame based encoding per-macroblock? My experiance (a long time ago now) was that this does not work as well for interlaced video compared to always using field pictures. I always got some blocks that should have been encoded field based, but were encoded frame based instead.
I mean interlaced, period. Scripted entertainment has been exclusively progressive for years now. We still see some interlaced production for broadcast and sports, but that's declining, and mainly for legacy stuff that doesn't support HEVC anyway.

It might not be a big deal for y262 adoption, hopefully no one is encoding interlaced video today, but it is a feature I would want for encoding camcoder VHS tapes into MPEG2.
Yeah, having 4:2:2 is definitely essential for archiving interlaced sources.

[kurkosdr]

I mean interlaced, period. Scripted entertainment has been exclusively progressive for years now. We still see some interlaced production for broadcast and sports, but that's declining, and mainly for legacy stuff that doesn't support HEVC anyway.
Personally, I'd prefer 50p/60p at 1080p resolution was universally supported even in H.264 hardware. Let the broadcaster/encoder side decide how they want to de-interlace the legacy content, not the de-interlace filter in my TV that might or might not mess it up. At least we got it with HEVC, since 50p/60p is supported across the resolution range in pretty much all HEVC hardware, even at 2160p resolution.

IMO, allowing interlaced on anything other than 480i and 576i was a huge mistake. If my old CRT TV can't handle the new HD resolution, why allow a mode (interlaced) that's tailor-made for my old CRT TV for those higher resolutions? You have to convert anyway.

[Z2697]

You just confused the relationship of "macro block level interlacing" and "field pictures".
Which is nothing beyond "they both used for interlaced content".
The former is what you are really talking about. Which is supported in y262.

Field pictures is like the way (and the only way) HEVC handles interlaced contents today.

[FranceBB]

allowing interlaced on anything other than 480i and 576i was a huge mistake.


Yes... and you know what's the most ironic thing in all this? We're not even shooting interlaced anymore, we're shooting 2160p at 50fps, the whole thing is produced progressively even on live events that go through video mixers etc and then the matrix/transfer/primaries conversion + downscaling + dithering + fields division to create the 25i TFF FULL HD version and the 25i TFF SD version occurs at the very end of the chain... So yeah, it could have been 50p from beginning to the end if only they allowed us to do that, but unfortunately the choice at the time was between HD (1280x720 50p) and FULL HD (1920x1080 25i TFF) and the overwhelming majority of broadcasters picked the latter with just a few exceptions like NRK (the Norwegian public broadcaster) which went to HD 50p.


At least we got it with HEVC, since 50p/60p is supported across the resolution range in pretty much all HEVC hardware, even at 2160p resolution.


Yeah... The great advantage of H.265 for me was moving from interlaced to progressive 50p and from 8bit planar to 10bit planar. That on its own would have been a good enough reason to move to H.265, aside from the whole UHD resolution bump, BT2020 wide color gamut and later also HDR PQ/HLG transfers.

[benwaggoner]

Yes... and you know what's the most ironic thing in all this? We're not even shooting interlaced anymore, we're shooting 2160p at 50fps, the whole thing is produced progressively even on live events that go through video mixers etc and then the matrix/transfer/primaries conversion + downscaling + dithering + fields division to create the 25i TFF FULL HD version and the 25i TFF SD version occurs at the very end of the chain... So yeah, it could have been 50p from beginning to the end if only they allowed us to do that, but unfortunately the choice at the time was between HD (1280x720 50p) and FULL HD (1920x1080 25i TFF) and the overwhelming majority of broadcasters picked the latter with just a few exceptions like NRK (the Norwegian public broadcaster) which went to HD 50p.
We almost killed interlaced with ATSC 1.0. The idea of playing broadcast on computers was really exciting back then, and Intel was adamant that interlaced just couldn't be done well on the PC. Broadcasters fought for interlaced, but were about to cave to Intel when some Intel engineer found a lousy-but-functional way to do it, and here we are today.

(as I remember from Joel Brinkley's history of HD Defining Vision, the greatest video standards true crime page-turner thriller of our era. Highly recommended for anyone interested in video standards or history. I hope they make a TV series of it.)

Yeah... The great advantage of H.265 for me was moving from interlaced to progressive 50p and from 8bit planar to 10bit planar. That on its own would have been a good enough reason to move to H.265, aside from the whole UHD resolution bump, BT2020 wide color gamut and later also HDR PQ/HLG transfers.
10-bit was really the killer feature for HEVC, as it enabled HDR-10m with compression efficiency at UHD resolutions #2. Those drove very quick and broad implementation for the codec when it was only a few years old (although both 10-bit and HDR were pretty late additions, and there wasn't PQ optimization built in). It's universal in mobile devices and near universal in living room devices. Most new devices had HEVC decoders by the time the standard was as old as VVC is now.