[FFmpeg-devel] MPEG-4 ASP motion vector clamping correct?

[Reimar Döffinger]

On Fri, Dec 16, 2011 at 10:11:58PM +0100, Michael Niedermayer wrote:
> On Fri, Dec 16, 2011 at 09:45:59PM +0100, Reimar Döffinger wrote:
> > Hello,
> > I have a question about mpegvideo_common.h
> > There is a lot of code like:
> > av_clip(src_x, -16, s->width);
> > However on the other hand we have the FF_BUG_EDGE flag that changes
> > where we start the border extension.
> > Why shouldn't this be using s->h_edge_pos instead to follow that?
> > Even more so since I think this is also used for H.263
> > for which the spec seems quite clear that the decoder should only
> > ever care about the rounded-up width, not the non-mod16 part.
> 
> I think you are correct, it should use h/v_edge_pos according to the
> h263+ spec. I dont know though if this will fix or break real world
> samples.
> it would only make a difference for h263+UMV with %16!=0 and 4mv and
> only if the further outside area is sufficiently different and the
> encoder actually used such motion vectors.

More specifically the motion vector must point exactly into the mod-16
extended area - a bit outside in either direction is ok.
As is decoding with FF_BUG_EDGE.
However I think GMC is affected as well, not just 4mv.
Question is: what should we do? Change it? Make it a "bug" option?
...?
Do you know what our encoder will have used as reference? If our
encoder did "the right thing" making the decoder match seems
advisable even if it hurts quality a bit for some existing files.

> this could be why it hasnt been noticed before

Probably combined with that everyone strongly recommended against non-mod16
encodes due to quality issues.
I can't help starting to thing that maybe more of that quality issue
that thought might be to blame on bugs...