[FFmpeg-devel] Corrupted blocks and seeking issues in H264 disc sources

[Andreas Öman]

Michael Niedermayer wrote:
> Hi
> 
> On Sat, Jul 14, 2007 at 10:22:58AM +0200, Andreas ?man wrote:
>> Hello,
>>
>> infernix wrote:
>>> Hi,
>>>
>>> Andreas, perhaps this new sample can give you more insight as to what 
>>> the problem is? If I find more blocks, I'll upload them and post a followup.
>>>
>> I've taken a quick look at it, and it seems the motion vectors
>> are somehow incorrect for the affected macro blocks. see [1]
>> and [2]. (Both frames have errors in the bottom left part of
>> the picture)
> 
> issue4 also has an error at the top right part of the same image which
> has that black block
> 
> 
>> I've done some additional tracing on [1]:
>>
>> [h264 @ 0x84b1de8]pic:11 mb:15/58
>> [h264 @ 0x84b1de8]mb_type = 0x1008, partition_count = 1, cbp = 0x0
>> [h264 @ 0x84b1de8]pred_motion match_count=3
>> [h264 @ 0x84b1de8]pred_motion ( 0  0 -2) ( 0  0  0) ( 0  8 -8) -> ( 0  0 
>> -2) at 15 58 0 list 0
>> [h264 @ 0x84b1de8]final mv:198 102, cabac delta: 198 104
>>
>> It would seem that the output from decode_cabac_mb_mvd() is
>> incorrect, but why (or if) it fails for this particular macroblock,
>> i'm not expert enough to tell.
> 
> are you sure its decode_cabac_mb_mvd() ? 

Nope :-) I was initially a bit confused since the
mv visualization draw the vectors twice as long as they
should've been (but since i've fixed that now i'll have
a look at this with fresh eyes)

i would rather guess that the issue
> is from a wrongly predicted mv  (which can be caused
> by less vissible errors in previous frames if the buggy frame is a b frame) or
> wrong reference image
> an error in decode_cabac_mb_mvd() is likely to cause more bitstream errors
> after that but there dont seem to be any ...

Indeed true, the reason i suspected cabac_mb_mvd() is due to its
high contribution (198, 104) to the invalid MVs. But as you say,
it should most likely result in further errors as well.

> also you could compare the various values with what the reference
> implementation produces (this is easy as the reference implementation
> can just dump all that for your viewing pleasure)

Yes, this is probably the best way to proceed.

Thanks