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

[Loren Merritt]

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.

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.


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

--Loren Merritt