Possible incorrect decoding by divx avc codec

[mariush]

I've been running some tests on a sample and I've stumbled on a frame that looks to be decoded slightly differently by divx, compared to CoreAVC and Di-AVC's output. As far as I know, the output should be bit by bit exact, no matter what decoder is used.

Maybe it's some bug in the codec. I've pm a while ago the guy i think works at divx but he never answered so...

So I'm talking about frame 464 in this sample: http://www.mediafire.com/file/biodim1xnmy/test.mkv
Here are the frames I extracted - the differences are minimal but they're there: http://www.mediafire.com/file/nmlz3nytnwm/frames.rar

divx control panel says divx pro codec 6.9.2

[[P]ako]

I have no idea what to look at. The frames looked exactly the same to me.

[Keiyakusha]

I don't have divx and don't want to install it, but if you judging only by visual difference, you may also want to try something like:
open file with avisynth+virtualdub using different decoders (by changing merit or creating .grf file)
make sure there is no other filters in the graph that can alter frame in one way or another
save some frames to bmp, calculate and compare checksums. they should be the same with any decoder used.
you may want to test libavcodec too.

EDIT: or maybe you can use something like ssim or psnr comparsion in avisynth. they should report that frames are identical.
EDIT2: also make sure divx has deblocking ON and their nasty logo feature off.

[AnonCrow]

Can't actually see any difference either, but obviously there is some difference. The DivX frame has 244300 unique colors while the two others have 244307 colors.

[mariush]

I've used Avisynth and Virtualdub to get to that frame and extract it. Did this for about 10 randomly chosen frames. Only this frame was different.

Used CoreAVC (two versions), DiAVC and DiVX and only divx's frame was different. Got to this conclusion using Total Commander's Binary comparison tool. The MD5 checksums are also different:

9caa1a1c07a9eabf224e8e36c0a36804 *04-divx_dec.bmp
3a52aecebbf691372268cb57a2c62c10 *05-coreavc-1.8.5.bmp

A software I used (image comparer) reports the visual difference in that small square - but if needed i can write a small vb app to show the highlight the pixels and whatever.

http://savedonthe.net/image/628/difference.png

[Keiyakusha]

does this stream uses weightp? if so, maybe this is the problem. I remember some time ago DS said that divx has some problems with these frames. Hoverer that was long ago, there was enough time to fix that.
also not sure what is "divx pro codec 6.9.2", this probably refers to mpeg4-asp decoder. Latest h264 decoder (ver 1.2.1, build 9.0.1.21) installed with divxplay 8

[AnonCrow]

Could be a coincidence , but can see the difference now - what looks like a pretty clear letter D on the left side of the highlighted squere , and a square overlapping the highlighted square.

[mariush]

Yeah, bingo. It's their logo. Looks like this (picture from another movie):

http://savedonthe.net/image/629/logo.png

What I can see is a very, very faint border and the P in plus, basically just illumination difference.

Must have forgotten to disable logo and jump to that frame and thought it's far away in the movie to not have logo but yet it still had a bit logo.
Frame 464 is still 18-20 seconds into the movie and their logo goes away in 10 seconds ... My bad and sorry.

[DigitAl56K]

Hi mariush,

Glad you found the cause. AFAIK there is no known decoding problem in the current decoder build except one reported to us with specific in-loop filter parameters which causes a slight virtually invisible error and that has already been fixed in an internal build so should be corrected in the next release.

Incidentally, I think DivX decoder did not have any issue with x264's weightp, IIRC there was a bug fixed by Dark Shikari (http://git.videolan.org/?p=x264.git;a=commit;h=e8501efbd235b1b5321adda8926e7a859beafd3c) present for only a few revisions of x264 (~1330 - ~1339).

[Dark Shikari]

Hi mariush,

Glad you found the cause. AFAIK there is no known decoding problem in the current decoder build except one reported to us with specific in-loop filter parameters which causes a slight virtually invisible error and that has already been fixed in an internal build so should be corrected in the next release.

Incidentally, I think DivX decoder did not have any issue with x264's weightp, IIRC there was a bug fixed by Dark Shikari (http://git.videolan.org/?p=x264.git;a=commit;h=e8501efbd235b1b5321adda8926e7a859beafd3c) present for only a few revisions of x264 (~1330 - ~1339).Isn't the loop-filter problem caused by duplicate reference frames, which are part of weightp?