[x264-devel] x264 predictors
Nadir Raimondo
raimondo at ismb.it
Fri Sep 21 15:53:55 CEST 2012
Hi Loren and thanks for your help.
Looking in fuction x264_me_search_ref it seems that the process is
trying to select the lowest cost between mvc and mvp predictors.
The best cost is then saved in bpred_cost and coordinates in bpred_mx,
bpred_my.
Then the selected motion estimation algorithm (DIA, HEX, ...) is
executed trying to find (I think) a better motion vector (with lower cost).
Why at the end of the process the function checks whether bpred_cost is
lower than bcost? I.e.:
/* -> qpel mv */
if( bpred_cost < bcost )
Shouldn't bcost always be lower than (or equal to) bpred_cost?
Is it beacuse of the fact that predictors could not be integers and this
can lead to a mismatch between values calculated with fullpel and
halfpel resolution?
Kind regards
Nadir
On 09/19/2012 07:33 PM, Loren Merritt wrote:
> On Wed, 19 Sep 2012, Nadir Raimondo wrote:
>
>> Is the x264_me_t mvp predictor obtained as a median of MVs of blocks around
>> the current block?
> Yes. mvp is the one that's specified in the standard, as the value that
> whatever mv you finally chose gets delta-coded against. You don't want to
> change this.
>
>> Why are there multiple values for mvc?
> mvc is all the other hypotheses, that motion estimation tries before
> getting into hill-climbing part of the search. If you have some extra
> guess that's probably close to the real motion, you can add it to the mvc
> list. If this guess is much more accurate than any of the other
> predictors, you might also benefit from removing some of the existing
> entries of mvc.
>
> --Loren Merritt
> _______________________________________________
> x264-devel mailing list
> x264-devel at videolan.org
> http://mailman.videolan.org/listinfo/x264-devel
>
More information about the x264-devel
mailing list