Flickering/Jumping B-frames problem

[DeathTheSheep]

In nearly any still scene in my encodes, B-frames seem to flicker annoyingly and actually cause filesize increases. I've been experiencing this problem with all builds of the XviD v1.1 tree (including the latest CVS build dating back to the 16th).

I've tried different VFW settings, but all seem to produce this horrendous B-frame flickering problem to one extent or another.

This problem is present for me on all encodes: anime, real-life DVD movies, etc at low bitrates. This problem was not present for me in XviD 1.0.3. This problem occurs regardless of the decoder used (it even occurs on my Pocket PC).

In order to demonstrate what I mean, I've uploaded:

1. My original, Source clip (http://www.filepost.us/userfiles/xsquaredx/source.avi)
2. An XviD encode at Quant=7 with Default settings (http://www.filepost.us/userfiles/xsquaredx/q7_default.avi)
3. An XviD encode at Quant=7 with Default settings but no B-VOPS (http://www.filepost.us/userfiles/xsquaredx/q7_noB.avi)
4. My AVISynth script used when encoding in VirtualDub 1.6.10 (fast recompress) (http://www.filepost.us/userfiles/xsquaredx/script.avs)
and of course,
A file using bicubicresize(320,240) instead of lanczos1 (http://filepost.us/userfiles/xsquaredx/bicubic_bframe_q7.avi)

Hypothesis: I think this problem is being caused by a problem with XviD's B-frame bias. Is there some way (recall that I currently only use the VFW) to force the codec not to use B-frames on still scenes besides tweaking the B-Bias or using an all-IPPP stream? Or is there any other solution to my problem?

Thanks in advance,
DTS

[Didée]

I'd not recommend to use tap=1 for LanczosResize. Really not.

[DeathTheSheep]

It's really the best resizer in my opinion in terms of sharpness/compressability ;). But okay, I'll repeat with bicubicresize(320,240). :p

Here (http://filepost.us/userfiles/xsquaredx/bicubic_bframe_q7.avi)'s the bicubic version, which shows exactly the same problem.

[stephanV]

The problem is not in the resizer, its in XviD's frame type decision. The p-frame only encode is not only better in quality, it is also smaller in file size. I have no idea why any encoder would prefer b-frames if they don't actually increase efficiency as there is no way in hell an MPEG4 ASP b-frame at quant 11 will look better than a p-frame at quant 7.

The only solution would be to not use b-frames (or at least reduce the b-frame sensitivity). As you yourself have stated before IIRC, the usefulness of b-frames at low to very low bit rates is questionable at the very least.

[DeathTheSheep]

...reduce the b-frame sensitivity
How would I go about doing such a thing in XviD? The only commandline tool I've use to encode with that supported B-frame bias was XviD EncRaw (http://forum.doom9.org/showthread.php?t=98469), and the bias feature didn't do anything at all for any source at all with any version of XviD1.1 at all... Any tips on how to get this feature working?

The p-frame only encode is not only better in quality, it is also smaller in file size.
It's touching, in a way, how you'd use the exact same quote I did a year back for exactly the same reasons :)

However, I've noticed quite the contrary with high-motion, high-framerate scenes in XviD: the difference is hardly perceptible to the human eye, and the filesize experiences a dramatic decrease. However, XviD (quite erroneously, it seems) lavishes B-frames on motionless scenes, which does indeed increase the filesize. There is apparently a need of a decent B-frame bias control mechanism in Constant Quality encodes. (Either that, or smart N-VOP insertion, but that's a topic for another thread ;) ).

[stephanV]

How would I go about doing such a thing in XviD? The only commandline tool I've use to encode with that supported B-frame bias was XviD EncRaw (http://forum.doom9.org/showthread.php?t=98469), and the bias feature didn't do anything at all for any source at all with any version of XviD1.1 at all... Any tips on how to get this feature working?
In VFW it is accesible in the zone options, for command line XviD encoders I have no idea. I've never used them as I see no point in them. (Perhaps its possible with mencoder?)


However, I've noticed quite the contrary with high-motion, high-framerate scenes in XviD: the difference is hardly perceptible to the human eye, and the filesize experiences a dramatic decrease.
Of course, you can get away with anything on high motion scenes (anything but excessive blockyness), since you dont get the chance to study all those fine details in the iris of someones left eye anyway. ;) (The high/low motion modulation in DivX is not completely useless either of course)

However, XviD (quite erroneously, it seems) lavishes B-frames on motionless scenes, which does indeed increase the filesize. There is apparently a need of a decent B-frame bias control mechanism in Constant Quality encodes. (Either that, or smart N-VOP insertion, but that's a topic for another thread ;) ).
n-vop insertion won't gain you that much. First of all, XviD won't encode one still frame and then insert all n-vops right after on a no motion scene. It will first correct a bit the errors it made with following p-frames. Secondly, after a while those p-frames will take up almost no space anymore, because they can be encoded very effciently. On the other hand you are doing such low bit rate stuff you can use all the gain you can get. :)

[Shinigami-Sama]

hahaha I remember said quote sheep
I also noticed soem weird stuff with b-frames last time I was playing around with random video files last summer

[DeathTheSheep]

@Mr. Death God (Shinigami-Sama) (wait a sec, if you're a death GOD and I'm just a death SHEEP... woah)
A-hem! That's...eh...interesting. I love playing around with random files. ;) Speaking of random files, did you happen to notice ugliness in still scenes?

@Everyone else (especially the XviD Team)
After tweaking B-bias, I managed to eliminate the problem (flashing blocks and huge filesize) in this particular still scene. However, the video's overall quality and filesize is heavily sacrificed, and B-frames don't even come up in high-motion scenes (at bias -22).

So,
B-frame decisions, I believe, need to be tweaked in XviD before a final is released. The encoder tends to put B-frames in nearly still scenes. This raises filesize, reduces quality, and makes junky flickering blocks appear. With medium to high-motion scenes, XviD's B-frame descision is great, but in nearly still scenes, it is...suboptimal to say the least.