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

[Guillaume POIRIER]

Hi,
Le vendredi 07 janvier 2005 à 17:25 -0800, Loren Merritt a écrit :
> On Fri, 7 Jan 2005, Guillaume Poirier wrote:
> > On Fri,  7 Jan 2005 12:11:24 +0100 (CET), Loren Merritt CVS wrote:
> >> CVS change done by Loren Merritt CVS
> >>
> >> -1: 1 iteration of qpel on the winning candidate
> >> +1: fullpixel mode decision, 1 iteration of qpel on the winner (fastest)
> >
> > Given my limited knowledge regarding video processing, I'm not sure I
> > fully understand what's meant here.
> > Does that mean: "fullpixel precision motion estimation, and
> > qpel-precision motion estimation on the winner macro-block?"
> > [...]
> > And finally: "quarter pixel precision motion estimation, and more
> > iterations around the winner macro-block" (maybe like increasing
> > libavcodec "dia" option?)
> >
> > All that might be very brain dead questions, but I guess if I'm
> > puzzled regarding this kind of process, so are our dear "Joe Users"
> 
> 1: Runs fullpixel precision motion estimation on all candidate macroblock 
> types. Then selects the best type. Then refines the motion of that type to 
> fast quarterpixel precision.
> 2: As 1, but uses a slightly slower fullpixel search and a slightly 
> slower quarterpixel refinement.
> 3: Runs halfpixel precision motion estimation on all candidate macroblock
> types. Then selects the best type. Then refines the motion of that type to
> quarterpixel precision.
> 4: Runs fast quarterpixel precision motion estimation on all candidate 
> macroblock types. Then selects the best type. Then finishes the 
> quarterpixel refinement for that type.
> 5: Runs best quality quarterpixel precision motion estimation on all 
> candidate macroblock types. Then selects the best type.

What can I say? Thanks a lot! Now this explanation of this option is
cristal-clear... I guess this is what the man should read.


> When I say "all candidate" I don't exactly mean all enabled types.
> 4x4, 4x8, 8x4 are tried only if 8x8 is better than 16x16.

Ok, that makes sense.


> 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.


> Of course, this all will change. I am playing with rate-distorion 
> comparison, which should eventually be equivalent to lavc's mbd=2,subcmp=6.

Humm. Yes I think I read on Doom9's forum that you where planning to do
that.


> Also, SysKin (from XviD) has proposed some optimizations which might make 
> the lower quality modes irrelevant, or at least could change the details 
> of what's done when.
> 
> 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?

Again, thanks a lot for your enlightenment, I really appreciate it.

Regards,
Guillaume