[FFmpeg-devel] dia, dia_size and the rest
vmrsss
vmrsss
Fri Jan 23 18:58:18 CET 2009
On 23 Jan 2009, at 16:56, Michael Niedermayer wrote:
> On Fri, Jan 23, 2009 at 03:47:44PM +0000, vmrsss wrote:
>> I have tried to use me_method hex with mpeg2video and got:
>>
>>> [mpeg2video @ 0x101005800]me_method is only allowed to be set to
>>> zero and epzs; for hex,umh,full and others see dia_size
>>
>> I suppose there are precise rules on which video codecs support which
>> motion estimation algorithms. What are they?
>
> the rule is above, what part of it is unclear?
> Do you have some suggestion how to make it clearer?
It refers to dia_size, but dia_size has no documentation at all. It
would be clearer if one explained the way the value of dia_size
activates hex/uhm/full and the several variations of dia, and how it
influences the range of the search. At least one could replace
"for hex .... dia_size"
with something like
"hex/umh/full motion evaluation can be enabled by choosing an
appropriate value for dia_size; see motion_estimation_template.c for
the details".
But then of course one would still like to know what is SAB, L2S, VAR
and FUNNY diamond search (I guess SMALL is rather self-explanatory),
and how change the range.
> The rule is not dependant on the used codec.
what do you mean, if I use external codecs (lidirac, libx264,
libxvid, ...) I can specify -me_method hex,umh, tesa, ... It appears I
can't for the lavc codecs. I didn't know that.
>> I have looked for documentation or exchanges on this list about epzs/
>> dia, there is almost none (except one from 2004). In
>> motion_estimation_template.c I found this relevant branching.
>>
>>> if(c->dia_size==-1) ==> funny_diamond_search
>>> else if(c->dia_size<-1) ==> sab_diamond_search
>>> else if(c->dia_size<2) ==> small_diamond_search
>>> else if(c->dia_size>1024) ==> full_search
>>> else if(c->dia_size>768) ==> umh_search
>>> else if(c->dia_size>512) ==> hex_search
>>> else if(c->dia_size>256) ==> l2s_dia_search
>>> else ==> var_diamond_search
>>
>> Can anybody explain schematically the differences between the
>> "funny_", "sab_", "ls2_" and "var_" algorithms are and how the values
>> of dia_size affect them?
>
> IIRC the mplayer docs might contain some more info ...
I couldn't find anything more than:
> dia: motion search range. Bigger is better and slower. Negative
> values are a completely different scale. Good values are -1 for a
> fast encode, or 2-4 for slower.
which isn't particular informative.
>> A few more questions: with abs( dia_size ) > 4 I get
>>
>>> [mpeg2video @ 0x101005800]ME_MAP size may be a little small for the
>>> selected diamond size
>>
>> Is this something to worry about? ME_MAP is the constant 64 (so this
>> is not easily dealt with from the command line). In fact,
>>
>> with -dia_size -65
>>
>>> mpeg2video @ 0x101005800]ME_MAP size is too small for SAB diamond
>>> Video encoding failed
>>
>> Also, with -dia_size 7 and -cmp satd (as well as with other
>> combinations) I get:
>>
>>> [mpeg2video @ 0x101005800]ME_MAP size may be a little small for the
>>> selected diamond size
>>> Assertion failed: (map[(index-(1<<ME_MAP_SHIFT))&(ME_MAP_SIZE-1)] ==
>>> key), function hpel_motion_search, file libavcodec/
>>> motion_est_template.c, line 168.
>>> Abort trap
>>
>>
>> Is this something to worry about? Below is my full ouput.
>
> nothing to worry here, you just used parameters that are not
> compatible
> with the ME_MAP value, lavc warned you and encoding failed
> Ideally lavc should of course fail cleanly, not by assert() of course
Well, it's not quite "incompatible parameters", it's exceeding some
limit value which appears not to be documented, because
"-dia_size 6 -cmp satd" works well, while "-dia_size 7 -cmp satd"
fails.
I guess I was interested in understanding how these parameters
interrelate and how to use them. In the case above, for instance,
there is a range 2 < dia_size < 256 in which var_diamond search is
activated, yet using any comparison function other than "sad" and
"zero" is only "compatible" with the first 4 values in the range.
Regards.
More information about the ffmpeg-devel
mailing list