[MPlayer-DOCS] CVS: main/DOCS/man/en mplayer.1,1.845,1.846

[Loren Merritt]

On Sat, 8 Jan 2005, Guillaume POIRIER wrote:
> Le vendredi 07 janvier 2005 à 17:25 -0800, Loren Merritt a écrit :
>
>> It was originally named "subq" to relate to lavc's "subq", but on closer
>> examination of lavc's code, that doesn't really hold. lavc always uses
>> the same motion estimation quality for all candidate macroblock types,
>> so it doesn't have a really equivalent option. At (x264) subq=1,
>> I do reduce the diamond size (though I think that size 2 hexagon (for
>> subq>=2) is slower than a size 1 diamond only in low motion scenes), but
>> the difference between higher settings is only macroblock decision
>> quality, not eventual motion precision. So you could say that it's most
>> similar in effect to lavc's "mbd", though it shares nothing in
>> implementation.
>
> Ok. I hadn't made the link myself. The man does seem to pretend that mbd
> does what you're saying, except there still is the word "mode" that I'm
> not so sure to understand perfectly. Here's what the man reads about
> mbd:
>
> encode each macro block in all modes and choose the best.
>
> I guess a mode isn't a MB type (I, P or B), and AFAIK, MPEG-4 doesn't
> allow different MB size (like 4x4, 4x8, 8x4...), so I guess I can't
> really see what "mode" is about. Is it related to the different kind of
> predictors available, like what x264's direct_pred does?
> Again, that might seem to be a very dumb question... so I'd really
> appreciate if someone could "enlighten" me.

The "modes" are MB types. It's just that the names I, P, B are 
simplifications of the real set of MB types.
In MPEG-4 ASP, the equivalent set of modes are:
intra, intra with AC prediction, p16x16, p8x8, b16x16, b8x8, direct, skip.

There is only one kind of direct prediction in ASP. (And even in H.264 it 
can only vary per frame, not per MB.)
ASP's b8x8 is also less flexible than H.264's.
p8x8 and b8x8 are enabled by "v4mv".
AC prediction can't be enabled in mencoder's lavc frontend (when I tried
forcing it on, it cost +6% cpu time and improved compression by .2%).

>> Remaining questions?
>
> Yes, one more: given that, AFAIK H.264 stores motion compensation
> informations with a quarter pixel precision, wouldn't it be wise to warn
> the user that a less precise motion (i.e. subq=<1-3>) search wastes
> bits, while allowing a faster search, or did this problem only existed
> with subq=0?

subq=0 was the only one that used worse than qpel precision for the real 
encode of each macroblock.
Anyway, what's the difference between wasting bits due to not considering 
some possibilities, and wasting bits because I considered it using a low 
quality comparison algorithm?

--Loren Merritt