Interlaced to interlaced problem in H.265 (but not in H.264!)

[gilius2k14]

I've got an interlaced source (top field first). When I encode that to H.265, using ffmpeg or Handbrake, the resulting file has jerky motion. But in H.264 it's always perfect. I've confirmed that the encoders are accepting the interlaced flag:
H.264: tff or tff=1
H.265: interlace=tff

What's the difference between H.264 and H.265 interlaced? Is this a bug? How can I report it?

[Cornucopia]

Even though interlacing is now supported in h265, it is still deprecated. Therefore, you probably shouldn't be using it that way. If interlacing is so important to the title, I recommend you just use h264. If it's not that important, make the title progressive.

Scott

[PuzZLeR]

Yes, as was mentioned, the HEVC, or "H.265", standard kind of frowns upon interlacing. In fact, the standard is not supposed to support interlacing at all - at least it's still as such stated in Wikipedia pending further update. So if it currently does support interlacing, it is indeed VERY recent news as of this moment, so I can't see it being any good at it for a long, long time.

Just use H.264 for this, which has always included interlacing, fully supporting MBAFF/PAFF. As for x264, it only uses MBAFF, but it's more efficient anyway, and really all you'd need for most, if not all, source.

Either that, or de-interlace.

[gilius2k14]

OK thanks, but the problem is: x264 doesn't save me much space over the DVD source, whereas x265 gives greater compression and smaller filesize.

The main problem with deinterlacing is that I need to preserve the fluidity as opposed to the quality. What is the best deinterlacing method for retaining fluidity besides Bob - loses half the resolution?

How to complain about lack of MBAFF in H.265?

[sneaker]

OK thanks, but the problem is: x264 doesn't save me much space over the DVD source, whereas x265 gives greater compression and smaller filesize.

You can freely set filesize with both x264 and x265. The only reason you got a bigger filesize with x264 is because you told it to do so by setting CRF/bitrate that way.

The main problem with deinterlacing is that I need to preserve the fluidity as opposed to the quality. What is the best deinterlacing method for retaining fluidity besides Bob - loses half the resolution?

In HandBrake try setting deinterlacing to "decomb" and "Bob", then video framerate to double the source framerate. Resolution should stay the same but I do not know how good the quality is compared to other advanced deinterlacers like QTGMC.

How to complain about lack of MBAFF in H.265?

The encoder developers cannot just add features not allowed in the specifications. Advanced interlacing tools were not added to those for a reason. Complaining is futile.

[pandy]

Split fields - H.265 should encode them as frames - this is how H.265 was designed - interlace is accepted as PAFF. As alternative you can encode interlaced video as progressive (not sure how H.265 will distort/analyse such video).

[PuzZLeR]

What is the best deinterlacing method for retaining fluidity besides Bob - loses half the resolution?

Best method is with using Avisynth and the mentioned QTGMC. Double the framerate to preserve a great deal of what you'd lose otherwise in resolution, and - VERY IMPORTANT - keep the source, and keep it interlaced (as methods, codecs, playback devices, etc, change all the time).

How to complain about lack of MBAFF in H.265?

That's like complaining to a judge that a law did not allow you to drive over a speed limit that was posted on a legal sign. What's included, or not included, in H.264/H.265 is standard, and kind of like law. Any diversion breaks the standard and becomes a different juristiction.

[gilius2k14]

OK thanks, but the problem is: x264 doesn't save me much space over the DVD source, whereas x265 gives greater compression and smaller filesize.

You can freely set filesize with both x264 and x265. The only reason you got a bigger filesize with x264 is because you told it to do so by setting CRF/bitrate that way.

The main problem with deinterlacing is that I need to preserve the fluidity as opposed to the quality. What is the best deinterlacing method for retaining fluidity besides Bob - loses half the resolution?

In HandBrake try setting deinterlacing to "decomb" and "Bob", then video framerate to double the source framerate. Resolution should stay the same but I do not know how good the quality is compared to other advanced deinterlacers like QTGMC.

How to complain about lack of MBAFF in H.265?

The encoder developers cannot just add features not allowed in the specifications. Advanced interlacing tools were not added to those for a reason. Complaining is futile.

Aren't the bitrates relatively different between x264 and x265? What would you suggest for a DVD source? For x265 I am using 250. Apparently, Blu Rays should be about 400? I'll try 250 in x264, but I don't think that's comparable?

I am now using Decomb - Bob in Handbrake, which is actually quite good: it doesn't gain too much filesize and doesn't lose much quality for static scenes with minimal motion. Perhaps it's comparable to what QTGMC can do? I mean there's only so much one can do with interlaced fields?

[gilius2k14]

Split fields - H.265 should encode them as frames - this is how H.265 was designed - interlace is accepted as PAFF. As alternative you can encode interlaced video as progressive (not sure how H.265 will distort/analyse such video).

But if you output fields as frames then it takes up twice the filesize. The Interlace=tff/bff is meant to output as fields, yet it doesn't retain the correct interlacing structure in the original source like what x264 does perfectly. So I don't actually know what purpose H.265's interlace output serves except for outputting progressive sources to interlaced - certainly it cannot output an interlaced source directly to interlaced without messing up the motion.

[gilius2k14]

x264 seems to require about twice as much bitrate as x265 in order to match filesize

[sneaker]

That does not make any sense since filesize = bitrate * duration. Same duration and same filesize mean same bitrate. Maybe HandBrake does something wrong when setting the bitrate depending on how you deinterlace (double rate deinterlacing = double framerate).

[sneaker]

But if you output fields as frames then it takes up twice the filesize. The Interlace=tff/bff is meant to output as fields, yet it doesn't retain the correct interlacing structure in the original source like what x264 does perfectly. So I don't actually know what purpose H.265's interlace output serves except for outputting progressive sources to interlaced - certainly it cannot output an interlaced source directly to interlaced without messing up the motion.

I wonder if your player can handle interlaced HEVC correctly in the first place.

[gilius2k14]

I confirmed the interlacing was messed up - not software player related - by feeding the output back into the encoders.

[sneaker]

Or it's a case of two wrongs making a right.

I have only little experience with interlaced HEVC but MPC-HC and VLC do not seem to handle it correctly. Each field gets treated like a single half-resolution frame without proper deinterlacing. Or maybe my samples are broken - I cannot tell for sure...

[poisondeathray]

Yes, that's how it currently works. It's a player/decoder issue. Broadcast streams do it the same way, but their decoders take the additional step to resize the field. There is an native sample in this post
https://trac.mpc-hc.org/ticket/5088

I can confirm that works with x265 as well. You have feed it separate fields, otherwise it gets messed up.

HEVC encodes interlaced content as fields. Fields must be provided to the encoder in the correct temporal order. The source dimensions must be field dimensions and the FPS must be in units of fields per second. The decoder must re-combine the fields in their correct orientation for display.

So you are essentially encoding fields as frames, keeping them separate. The interlace flags are supposed to tell the player/decoder to resize and account for the field shift, which currently isn't being done properly by most open source decoders/ffmpeg/libav

But the motion is correct, you're only seeing fields (1/2 sized frames)

[sneaker]

But I'd be careful about that specific sample. It's from the early stage of German DVB-T2 trials when they were still experimenting with a lot of parameters, not always sticking to proper standards. It might as well simply be encoded incorrectly.
And while the German DVB-T2 does allow interlaced encoding it currently looks like no channel will use it. In their tests interlaced did worse than progressive (for reasons already discussed above).
Good reasons to not create interlaced HEVC.

[gilius2k14]

Here's my DVD MPEG2 source (interlaced); see if anyone can convert that to H.265 Interlaced - without converting to progressive first.
It's top-field first... you can separate the fields first or whatever, but it seems H.265 is not fit to carry out that kind of direct interlaced to interlaced conversion unlike it's predecessor:
https://www.sendspace.com/file/ij5dhl

[poisondeathray]

It's not "converting to progressive" per se - Currently stores it with separate fields, and most/all decoders decode it like that too. ie. the separate fields are not weaved back into 1 frame like they are now for interlaced MPEG2 or PAFF or MBAFF for AVC. Sneaker has a good point - that might not be the "final" way things work out, and the way that station, and x265, and HEVC currently handles it might change. Or maybe it is good riddance for interlace the way you know it as

[poisondeathray]

Here's my DVD MPEG2 source (interlaced); see if anyone can convert that to H.265 Interlaced - without converting to progressive first.
It's top-field first... you can separate the fields first or whatever, but it seems H.265 is not fit to carry out that kind of direct interlaced to interlaced conversion unlike it's predecessor:
https://www.sendspace.com/file/ij5dhl

This is an exceptionally poor example to use , because it's field blended. (It's actually progressive content)

[gilius2k14]

Here's my DVD MPEG2 source (interlaced); see if anyone can convert that to H.265 Interlaced - without converting to progressive first.
It's top-field first... you can separate the fields first or whatever, but it seems H.265 is not fit to carry out that kind of direct interlaced to interlaced conversion unlike it's predecessor:
https://www.sendspace.com/file/ij5dhl

This is an exceptionally poor example to use , because it's field blended. (It's actually progressive content)

Really? How can you tell? Thanks for checking. Field blended is not progressive though?

[gilius2k14]

Why does it look good as interlaced x264 but not x265?

[pandy]

Split fields - H.265 should encode them as frames - this is how H.265 was designed - interlace is accepted as PAFF. As alternative you can encode interlaced video as progressive (not sure how H.265 will distort/analyse such video).

But if you output fields as frames then it takes up twice the filesize. The Interlace=tff/bff is meant to output as fields, yet it doesn't retain the correct interlacing structure in the original source like what x264 does perfectly. So I don't actually know what purpose H.265's interlace output serves except for outputting progressive sources to interlaced - certainly it cannot output an interlaced source directly to interlaced without messing up the motion.

Why? each field is half of frame size...

H.265 is designed for progressive - UHD by definition is progressive - not sure why you trying to ignore this.
And H.265 at today provide maybe 20 - 30% bandwidth reduction when compared to H.264. For sure it doesn't reduce bitrate by half.

[poisondeathray]

Here's my DVD MPEG2 source (interlaced); see if anyone can convert that to H.265 Interlaced - without converting to progressive first.
It's top-field first... you can separate the fields first or whatever, but it seems H.265 is not fit to carry out that kind of direct interlaced to interlaced conversion unlike it's predecessor:
https://www.sendspace.com/file/ij5dhl

This is an exceptionally poor example to use , because it's field blended. (It's actually progressive content)

Really? How can you tell? Thanks for checking. Field blended is not progressive though?

You can tell it's field blending by examining the fields. There are "double images", or blurry "ghosting"

I said the content is progressive. Another way you can infer this is originally it was film - you can tell by the genre, age and content. Film is progressive - full frame pictures. Interlace was devised by engineers as a method of reducing bandwith for distribution.

This source is a bad example, because it's not interlaced content. You can have progressive content, interlaced content, progressive encoding, or interlaced encoding. Ideally you would test interlaced content with interlaced encoding if you were discussing HEVC and interlace

True interlaced 25 FPS content would have 50 distinct fields per second (50 different moments in time represented per second). This doesn't have that.

Instead, you should use a deblender on this, to attempt to recover the original progressive film frames then encode progressive

[lostcub]

It's been my understanding H.265 supported interlace video from the get-go since it's debut in Oct 2014, unlike H.264 which only had an adapted patch added later. That patch isn't good either as it drifts in and out of interlacing causing some frames to have that combing effect, especially when going from near static to full motion, then goes into a true interlace.

I also can't understand why many here seem to believe interlace video is dead, when, in fact it's still the broadcast standard in North America; and, it doesn't seem to be changing anytime soon. The FCC is no longer going to issues broadcast standards hereon out. 1080i looks to remain the standard 'til broadcast TV dies as we know it. There is NO broadcast standard for 1080p. Believe or not, while there is no standard for 720p many broadcasters use a workaround trick to get that 60hz interlace look, but I won't go into that.

Even saying that, I did some research as I too like to keep interlace video in its original smooth motion. My research showed interlace was fully supported with individual fields more like MPEG-2 and xviD, not H.264. It even showed the command line commands. I had no issues uses handbrake to preserve interlace from an MPEG-2 DVD from video and not film onto H.265.

This is all I did:

First: I made sure the frame rate was set to constant NOT variable. I wonder if the original poster forget this? YOU CANNOT USE VARIABLE FRAME RATE IN INTERLACE. Remember, handbrake has variable as a default!

Second: In the additional options box I put: interlaced=tff nothing else. (Broadcast contents should be changed to bff as ATSC/NTSC uses bottom field first.)

Third: I set the level to the highest setting. not sure if that helped or not.

Video came out like the original interlace DVD video. Amazingly better than the H.264 and was only 38Mb (Original MPEG-2 is about 250Mb) with the original passthrough Dolby Digital audio. And that was at ultrafast speed! I'm sure if I had it medium it would be much-much smaller! (But It might of given my CPU a heart attack) The only issue I had was the playback. My graphics card does not support H.265 (but does support simulated interlace at a 60hz refresh rate on progressive) and I only have a dual core 2.2 CPU so I dropped a few frames and audio samples. it took more processing than 1080p medium bandwidth. But from what I could tell it did it flawlessly. I was impressed, too bad my stand-a-lone Blu-ray player doesn't support H.265 either or I'd start using it. No seeable blockiness in dark settings, nor ringing. I was very impressed with the whole thing, not just how it interlaces.

[sneaker]

It's been my understanding H.265 supported interlace video from the get-go since it's debut in Oct 2014, unlike H.264 which only had an adapted patch added later.

No. You can download the 2003 H.264 spec from ITU and see it already had interlacing (including MBAFF) right then. Anyways, it wouldn't mean that "added later" is worse than "from the get-go".

That patch isn't good either as it drifts in and out of interlacing causing some frames to have that combing effect

What is that even supposed to mean? Your deinterlacer shouldn't care about how a fame is coded. Coding mode is first and foremost about compression efficiency, not hinting for playback.

I also can't understand why many here seem to believe interlace video is dead, when, in fact it's still the broadcast standard in North America; and, it doesn't seem to be changing anytime soon. The FCC is no longer going to issues broadcast standards hereon out. 1080i looks to remain the standard 'til broadcast TV dies as we know it. There is NO broadcast standard for 1080p.

People say it's dead because no one uses it for UltraHD. And because of HEVC's inefficiency we will see little interlacing. In Germany DVB-T2 channels send 1080p50 even if they are still produced in 1050i25 because of that.

Even saying that, I did some research as I too like to keep interlace video in its original smooth motion. My research showed interlace was fully supported with individual fields more like MPEG-2 and xviD, not H.264. It even showed the command line commands. I had no issues uses handbrake to preserve interlace from an MPEG-2 DVD from video and not film onto H.265.

We know HEVC supports interlacing. But as discussed earlier:
- it's inefficient (compared to deinterlacing the same source and encoding progressively or even to H.264)
- you are probably doing it wrong

[pandy]

It's been my understanding H.265 supported interlace video from the get-go since it's debut in Oct 2014, unlike H.264 which only had an adapted patch added later. That patch isn't good either as it drifts in and out of interlacing causing some frames to have that combing effect, especially when going from near static to full motion, then goes into a true interlace.

H.265 is first video broadcast codec designed to support progressive encoding - interlace in H.265 can be considered as special extension and it coded more or less as progressive.
There is nothing you describe as interlace drift in H.264 - something is obviously wrong with your setup.
And in broadcast there is no such things as variable framerate - variable framerate is typical for low cost acquisition devices where video quality is not important and and it may be tolerated in IP streaming where video quality is also not important.