[XviD-devel] direct mode predictor error

[Christoph Lampert]

On Mon, 9 Sep 2002, peter ross wrote:

> hello,
> 
> this is more a 'todo' than a bug.
> the direct-mode motion search performs a +/-16 pixel search arround
> the reference block location. this is incorrect, and causes purple
> (offscreen) artifacts arround the edge of the image when the motion
> search is FORCED to alway use direct-mode.

Are you sure? I though I did the following: Allow +/-16 for
"delta" vector (which is checked in CHECK_MV16_DIRECT macro) and apart
from that check only for image boundaries (which is done using
max_dx,... and the indeed ugly hack to call get_range with fcode value of
19, which should cover the whole picture).  

The problem you mention might be that it's sometimes simply not _possible_
to use direct mode (and forcing it leads to image errors), because 
the scaled vectors used a basis for delta vector may lie out of
image bounds (even +/-16 might not help). Current search returns a very
large SAD 65535 for that, but if the mode is still chosen, decoded image
breaks. 

> i think the +/-16 search should be made arround the direct-mode
> motion-vector-predictor.

You mean the scaled version of following collocated backward MVs? Then I
agree. 

> also whilst browsing the REALmagic source codes, i noticed this:
> 
> // The hardware decoder is compliant to MPEG-4 definition,
> // which only allows direct mode when co-located MB is not coded as INTRA

Since the standard allowed referencing I-frames as backward and even GOPs
like IBI, I find this rather hard to believe. I'd rather consider it a bug
in REALmagic hardware until somebody shows me where this stands in the
standard. 

> it sounds like another silly mpeg-4 limitations, like the every
> 132 frame i-frame rule & edged blocks must not be field-dct coded.

There also is no 132 frame i-frame rule. There is a "132 frame INTRA-block
rule". Every macroblock must not be INTER encoded for more than 131 blocks
in a row. Then it has to be INTRA coded. But if the INTRA block is in
INTER or INTRA frame doesn't matter. At least that's how I read the
standard:

"Every macroblock is required to be refreshed before it is coded 132 times
as predictive macroblocks. Macroblocks in B-pictures (and skipped
macroblocks in P-pictures) are excluded from the counting because they do
not lead to the accumulation of mismatch errors." 

gruel