B-frames or Trellis in x264 interlaced?

[Caiwyn]

Hi, everybody. I'm using mencoder to encode interlaced video with the x264 codec, and I have a question:

I found this post (http://forum.doom9.org/showthread.php?t=111527) from over a year ago when interlaced encoding was first included in x264. In that post it notes that B-frames and trellis were not supported at that time.

Has this changed at all? Can I use B-Frames and/or Trellis in my interlaced encodes now?

[Manao]

Trellis works, and I would say bframes work too.

However, do you really want to encode your video as interlaced ?

[Caiwyn]

Trellis works, and I would say bframes work too.

Well, I ask because I'm getting occasional glitches when I play back video encoded with the following options:

mencoder source.file -vf harddup -nosound -ovc x264 -x264encopts interlaced:bitrate=1800:bframes=3:b_pyramid:weight_b:turbo=1:pass=1 -of rawvideo -o movie.264
mencoder source.file -vf harddup -nosound -ovc x264 -x264encopts interlaced:bitrate=1800:subq=6:me=umh:partitions=all:8x8dct:frameref=6:bframes=3:b_pyramid:weight_b:trellis=1:pass=2 -of rawvideo -o movie.264
MP4Box -add movie.264 movie.mp4


Both VLC and mplayer show the similar artifacts at the same points during playback. It's rare, but it's very visible when it happens, and I'm trying to narrow down the cause... Do you know when b-frames and trellis were made compatible with interlaced encoding? Would this be in the changelog for x264?

However, do you really want to encode your video as interlaced ?

Well, the source video is interlaced, and if I understand correctly, you can't deinterlace an encode without halving the framerate or doubling the size, right? I can deinterlace during playback, so that's not a problem.

[akupenguin]

Interlace + B-pyramid is broken. In particular, the glitches appear only in frames with two L1 refs. But I don't know what's causing it -- it's not as simple as "interlace isn't compatible with multiple L1 refs", because interlaced refs are measured in fields so it'ds actually four L1 ref fields that break while two ref fields work.

Interlace + B-frames and trellis were supported ever since interlace was committed to svn. It was only some of the patches floating around that didn't.

[Caiwyn]

Interlace + B-pyramid is broken. In particular, the glitches appear only in frames with two L1 refs. But I don't know what's causing it -- it's not as simple as "interlace isn't compatible with multiple L1 refs", because interlaced refs are measured in fields so it'ds actually four L1 ref fields that break while two ref fields work.

Interlace + B-frames and trellis were supported ever since interlace was committed to svn. It was only some of the patches floating around that didn't.

Ah, awesome -- thanks so much for the clarification. Also, I notice that in the changelog the entry for interlace support reads:


r570 | pengvado | 2006-10-01 04:41:22 +0200 (Sun, 01 Oct 2006) | 2 lines

support interlace. uses MBAFF syntax, but is not adaptive yet.

Does this mean that b_adapt does not work for interlaced encodes? If so, is that still the case? I don't see anything in the changelog to suggest that it has changed.

[akupenguin]

It means the AFF part of MBAFF isn't implement. It says nothing about the adaption of anything else.
That said, b_adapt might not be optimal, since it applies to a deinterlaced picture rather than what actually gets encoded, and the number of B-frames useful for a deinterlaced picture may be different. (Why I did this: b_adapt downscales the picture for speed, and there is no way to scale interlaced pictures without deinterlacing them.)

[Caiwyn]

It means the AFF part of MBAFF isn't implement. It says nothing abou the adaption of anything else.

Ah, okay, my mistake. Sorry for the confusion -- some of this is over my head. :)

That said, b_adapt might not be optimal, since it applies to a deinterlaced picture rather than what actually gets encoded, and the number of B-frames useful for a deinterlaced picture may be different. (Why I did this: b_adapt downscales the picture for speed, and there is no way to scale interlaced pictures without deinterlacing them.)

So just to clarify, if I use b_adapt, does it try to deinterlace the picture for that calculation (but not for the actual encode), or does it just get ignored altogether? I'm trying to decide which of the following is better:

-x264encopts bframes=3:b_adapt:weight_b

or

-x264encopts bframes=1:nob_adapt

[akupenguin]

if I use b_adapt, does it try to deinterlace the picture for that calculation (but not for the actual encode)
right

[Caiwyn]

So it sounds to me (and please correct me if I'm wrong) that using b_adapt isn't likely to hurt picture quality here -- it just may not be particularly useful, right?

Thanks again for all the help; this has done me a world of good. :)

[Caiwyn]

Just FYI, after more extensive testing with b_pyramid turned off, I have noticed that while both bframes and trellis do work with interlaced coding, there are problems when you use both options together. If I use:

-x264encopts interlaced:bframes=3:weight_b:trellis=1

Then I still get intermittent glitches in the video. If I remove either "trellis=1" or "bframes=3:weight_b" then the glitches stop. But using all of those options together on an interlaced encode isn't working for me. So I can use either Trellis or Bframes, but not both.

I have tried reducing the number of bframes, I have tried adding "nob_adapt", and I have tried removing "weight_b", but none of this makes any difference as long as trellis is on. I have to either disable bframes entirely or turn off trellis.

I have tested playback with both mplayer and vlc.

[akupenguin]

That's just screwed up, because trellis is in no way related to B-frames. The same trellis code runs for all macroblock types.

[Caiwyn]

Maybe there's some other contributing factor? Here's what I'm doing to encode:

mencoder source.file -vf harddup -nosound -ovc x264 -x264encopts interlaced:bitrate=1800:bframes=3:weight_b:turbo=1:pass=1 -of rawvideo -o movie.264
mencoder source.file -vf harddup -nosound -ovc x264 -x264encopts interlaced:bitrate=1800:subq=6:me=umh:partitions=all:8x8dct:frameref=6:bframes=3:weight_b:trellis=1:pass=2 -of rawvideo -o movie.264
MP4Box -fps 29.97 -add movie.264 movie.mp4

I've tried the encode three times now and keep getting the same results... every few minutes I see a split-second glitch consisting of either a bright white flash and/or sudden blockiness. It goes away almost instantly but it is definitely noticeable. If I turn off trellis or remove all the b-frames options, it stops happening. Haven't tried tweaking the other options; I assume they're unrelated, but is there another option here that's not totally compatible?

Note that this only happens when I'm encoding interlaced material -- progressive video doesn't seem to have this problem.

[akupenguin]

I've tried the encode three times now and keep getting the same results.
If you encoded twice and got bitwise identical files, then you didn't need a third encode. Otoh if you encoded twice and didn't get bitwise identical files, then that's a bug (or hardware failure) all by itself, and it doesn't matter whether there is anything visibly wrong with the video.

Note that this only happens when I'm encoding interlaced material -- progressive video doesn't seem to have this problem.
Is it the content that matters, or x264's interlaced option?

[Jay Bee]

Concerning random glitches this old post (http://forum.doom9.org/showpost.php?p=993479&postcount=3) of mine might be of interest. Haven't done any testing for quite a while though.


Well, the source video is interlaced, and if I understand correctly, you can't deinterlace an encode without halving the framerate or doubling the size, right? I can deinterlace during playback, so that's not a problem.

Bingo.

[Caiwyn]

Sorry for the tardy reply, work caught up to me.

If you encoded twice and got bitwise identical files, then you didn't need a third encode. Otoh if you encoded twice and didn't get bitwise identical files, then that's a bug (or hardware failure) all by itself, and it doesn't matter whether there is anything visibly wrong with the video.

I'm pretty sure they came out identical, as they were all the exact same filesize and the visible glitches happen in the same places. But I didn't do any check beyond that. I deleted all but the most recent encode, but I can do another and run some sort of file comparison if you'd like.

Is it the content that matters, or x264's interlaced option?

It's definitely the interlaced option, and not the content. I've done the following:

1. Encoded whilst deinterlacing the picture so that the final format is deinterlaced
2. Encoded without deinterlacing and without using the interlaced option

In both scenarios, the glitches do not appear.