ffmpeg avc bug: displaced strange blocks/artefacts

[bond]

after encoding with r137 i noticed the following:

the used settings where: 2pass, cabac, loop-5,-5, mref5, 3 b-frames (temporal), all partitions enabled, subq5

pretty often i saw strange single blocks/artefacts popping up on single frames (the frame before and after doesnt have those) where they definitely dont belong
this happens very often and it seems only on b-frames!

a best of can be seen here (look at the middle, near the heads):
http://www.8ung.at/bond/x264_1.jpg
http://www.8ung.at/bond/x264_2.jpg
http://www.8ung.at/bond/x264_3.jpg
http://www.8ung.at/bond/x264_4.jpg

this is one somewhat different, checkout the multiple (!) strange blocks in the middle by zooming into the picture:
http://www.8ung.at/bond/x264_5.jpg

i have stored the frames as .jpg to save space, i think the artefacts are also clearly seeable without having to use .png

i am not 100% (hard to proove something that doesnt exist) but i think these artefacts are not there in streams encoded with pre-r136 (latest encoder version before r136 i tested was compiled from svn on 14th february) at least they are not that easily spotable as the ones above were

[akupenguin]

I think it's more likely that the artifacts are caused by weighted prediction. The symptoms of that would be: artifacts only in B-frames, occur in rev135 but not rev134. (134 and 135 should make identical encoding decisions aside from wpred, so spotting differences should be easy. Wpred was implemented in 134 but enabled in vfw in 135. Currently it is on when B-frames > 1, with no way to disable it.)
And while I made pretty sure that x264's internal state with wpred is consistent with JM's, I'm not so sure of lavc's decoding.

[AlexW]

I can confirm that this appears to be an decoding problem with ffdshow, Nero's decoder doesn't seem to display these strange blocks/artefacts.

[sysKin]

I discovered a problem with weightned prediction. Patch at http://syskin.is.dreaming.org/x264/

..however, this patch will make MORE artifacts appear. Why? Because with the bug fixed, weightned prediction is used *much more* and ffdshow fails decoding it more often ;) (I hope Alex's info about ffdshow failing will appear before this post. Wasn't here when I started typing ;) )

Radek

[virus]

since a fixed version of ffdshow won't be out before a bit of time, I just wanted to notify everyone that builds/distributes VfW that by editing /vfw/codec.c, line 226 in the SVN code, you can easily disable bvops' weighted prediction just by setting param.analyse.b_weighted_bipred to 0 (unless akupenguin decides to disable it in VfW directly, he's the one with SVN access ;)).
That should allow you to test adaptive bvops without waiting for a new ffdshow build.

[bond]

Originally posted by akupenguin
And while I made pretty sure that x264's internal state with wpred is consistent with JM's, I'm not so sure of lavc's decodingit seems to be indeed a problem of libav's decoding, as it doesnt seem to happen here with the moonlight decoder (cant test nero here)

edit: btw videosofts decoder shows single wierd green blocks on many parts of the picture on all frames

Currently it is on when B-frames > 1, with no way to disable it.)didnt realise that x264 now does weigthed prediction too :D
would be nice if there would be an option to en/disable it (just so that people see how powerful x264 is :D )

btw, why is it currently only done on only more than 1 b-frames?

I think it's more likely that the artifacts are caused by weighted prediction. The symptoms of that would be: artifacts only in B-frames, occur in rev135 but not rev134. (134 and 135 should make identical encoding decisions aside from wpred, so spotting differences should be easy. Wpred was implemented in 134 but enabled in vfw in 135.the 14th february version i used was inside mencoder, dunno what revision :(

edit2: changed thread title :)

[akupenguin]

Originally posted by bond
it seems to be indeed a problem of libav's decoding, as it doesnt seem to happen here with the moonlight decoder (cant test nero here) I just found and fixed a wpred bug in lavc. I hope it was the only one.

btw, why is it currently only done on b-frames? Because B-frames use implicit weights, which are easy: I just modified the averaging function, no additional analysis needed.
In P-frames you need to first decide whether wpred is useful on a given frame and what weights to use, then preprocess the whole frame(s) and make motion estimation use the transformed refrence frames, while keeping the final macroblock encoding based on the original version because the preprocessing introduces rounding errors...