[FFmpeg-devel] Corrupted blocks and seeking issues in H264 disc sources
Wed Jul 18 09:59:40 CEST 2007
Michael Niedermayer wrote:
> On Sat, Jul 14, 2007 at 10:22:58AM +0200, Andreas ?man wrote:
>> infernix wrote:
>>> 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 
>> and . (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 :
>> [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.
More information about the ffmpeg-devel