[x264-devel] Preset parameter for x264

[Tran Minh Son]

Dear Loren Merritt,
Thank you for your prompt answer.

Loren Merritt a écrit :
> On Wed, 29 Aug 2007, Son Minh Tran wrote:
>
>   
>> Concerning the condition of the comparison, I wonder how one can provide
>> the setting of x264 in order to obtain the "High Quality" / "High Speed"
>> compression. It is a complex question isn't it? We have a combination of
>> a lot of parameters thanks to the flexibility of x264, then how can we
>> choose the right/suboptimal combination in order to achieve the
>> target, and especially to in order to submit to a competition, where
>> other models of H264 can choose some settings totally difference?
>>     
>
> Optimizing for real quality is tricky. But for a comparison that mostly 
> considers objective metrics, it's easy, and just takes lots of cpu time. 
> Just try all possible combinations of settings on a variety of content. Or 
> if you want to spend some extra human time to save a lot of cpu time, 
> elimintate a few of the insane options, and apply an iterative search on 
> the remainder.
>   

It is really a huge work. I imagine that I have to create a script to 
select iteratively  the options  and then check the statistic  data of 
the output  to choose the best one that fits  the given constraint. If 
you already made that, could you please send me the preset for this year 
and last year (if you still remember) :-)
In fact, I made a modification on the way of how one can choose the 
intra mode / block size for inter mode of  macroblock to be encoded.  
The original algorithm of x264 is to perform an exhaustive  search 
throughout all possible modes .  You improve this full search with 
b_merged_satd in the current version of x264. Based on the core of x264 
(the one from the beginning of last year), I propose reusing  the mode 
of the neighbour blocks to make an "early stop". As you can hint, with 
that I can save time at the cost of quality. The gain seems to be more 
than the lost (15-20% in time again 3-8% in PSNR). Unluckily you 
improved  you code quickly (frame based multithread, check 3 modes at 
the same time...), that I can not update my technique into your current 
x264. And with a lot of changes in the current x264, the gain of my 
technique becomes less important . But I do think that if I again apply 
the proposed technique to new core of x264, again I can speed it up :-).
The comparison of MSU is an occasion for me to really verify the 
performance of the proposed technique . We do not provide the full 
implementation of h264 (the core is x264) but at least we would like to 
see if really the fast mode decision bring some benefits in comparison 
with the core of x264, from where I started. That is why I need the 
presets of x264 (for the last year version) to provide the High Quality 
/ High speed.
Best regards
Son TRAN

> The different h264 implementations don't really affect anything. MSU 
> provides a cpu quota and a bitrate quota to be used for each encode, I 
> provide settings that maximize metrics within that quota, and all the 
> other encoders optimize with the same constraints.
> If one implementation has a feature that another doesn't, there's no 
> unfairness. Just one is better than the other.
>
> --Loren Merritt
> _______________________________________________
> x264-devel mailing list
> x264-devel at videolan.org
> http://mailman.videolan.org/listinfo/x264-devel
>