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

[Andreas Öman]

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.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: h264-mbc.diff
Type: text/x-patch
Size: 1718 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070724/a9fb18a6/attachment.bin>