[FFmpeg-devel] dia, dia_size and the rest

Michael Niedermayer michaelni
Sat Jan 24 20:55:07 CET 2009

On Fri, Jan 23, 2009 at 05:58:18PM +0000, vmrsss wrote:
> 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".

missing attachment, cant review

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

hmm, indeed, i meant its the same for all internal codecs

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

hmpf i thought it was documented somewhere 

anyway, from what i remember&RTFS
l2s is a large 2 small 8 point diamond search, that is
start with the given size and cut to half once a local minimum is hit
at the and a small 4 point diamond search is used
the whole is similar to hex_search

funny_diamond_search is some kind of zonal diamond search that only
considers diamonds of 2^x sizes

sab stands for shape adaptive, it pretty much should behave like
pouring water onto the error surface the "diamond" size is the
amount of it

var is the common zonal diamond search, that is start with a small diamond
and increase its size every time you didnt find a better point and reset
once you found a better point

doc patches and a code cleanup is welcome of cours e...

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090124/4e0b7029/attachment.pgp>

More information about the ffmpeg-devel mailing list