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

[Michael Niedermayer]

Hi

On Tue, Jul 24, 2007 at 10:35:49AM +0200, Andreas ?man wrote:
> Michael Niedermayer wrote:
> >Hi
> >
> >
> >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)
> >
> 
> Yep, the issue originates from incorrectly predicted MVs.
> 
> This is the macroblock just above the one mentioned earlier in the
> thread.
> 
> The mb is partitioned as follows:
> 
> [ 8x8 ] [ Dir ]
> [     ] [     ]
> [ 4x8 ] [ Dir ]
> [ 4x8 ] [     ]
> 
> The motion prediction (ffmpeg style) from reference decoder says:
> 
> 8x8:     (-1  0  0) (-1  0  0) (-1  0  0) -> ( 0  0  0)
>          cabac delta: 114, -96
>          final mv: 114, -96
> 1st 4x8: ( 0 114 -96) ( 0  0  0) (-1  0  0) -> ( 0  0  0)
> 	 cabac delta: 100, -102
>          final mv: 100, -102
> 2nd 4x8: ( 0 100 -102) (-1  0  0) (-1  0  0) -> ( 0 100 -102)
>          cabac delta: 0, -2
>          final mv: 100, -104
> 
> 
> 
> However, ffmpeg itself says:
> 
> [h264 @ 0x84aff08]pred_motion (-1  0  0) (-1  0  0) (-1  0  0) -> ( 0  0 
>  0) at 15 57 0 list 0
> [h264 @ 0x84aff08]final mv:114 -96
> [h264 @ 0x84aff08]pred_motion match_count=2
> [h264 @ 0x84aff08]pred_motion ( 0 114 -96) ( 0  0  0) (-1  0  0) -> ( 0 
>  0  0) at 15 57 8 list 0
> [h264 @ 0x84aff08]final mv:100 -102
> [h264 @ 0x84aff08]pred_motion ( 0 100 -102) ( 0  0  0) (-1  0  0) -> ( 0 
>  0  0) at 15 57 10 list 0
> [h264 @ 0x84aff08]final mv:0 -2
> 
> I.e. the MVs for the second 4x8 is incorrectly predicted.
> This is then further propagated to the macroblock below which then
> suffers from the more visually seen error.
> 
> As can be seen, neighbour C is incorrectly determined to be available by
> ffmpeg.
> 
> If I understand the spec correctly, any not-yet-decoded partition
> should be considered as unavailable. In this case, the fourth
> partition is used for prediction, (but it is not yet predicted
> itself).
> 
> The attached patches fixes this. Perhaps it can be done
> smarter, i dont know. But i'd like some feedback before
> proceeding.
> 
> ffh264_issue4.h264 and ffh264_issue5.h264 looks okay now.
> If md5-summed a bunch of my other samples i have and none of
> them changes sum with the patch. I assume they dont have
> this type of prediction coded in.

fill_caches()
does
            h->ref_cache[list][scan8[5 ]+1] =
            h->ref_cache[list][scan8[7 ]+1] =
            h->ref_cache[list][scan8[13]+1] =  //FIXME remove past 3 (init somewhere else)
            h->ref_cache[list][scan8[4 ]] =
            h->ref_cache[list][scan8[12]] = PART_NOT_AVAILABLE;

why doesnt this suffice to mark them as unavailable?

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Freedom in capitalist society always remains about the same as it was in
ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070724/a1e2351a/attachment.pgp>