[FFmpeg-devel] [PATCH] more libx264 parameters

Jason Garrett-Glaser darkshikari
Fri Mar 19 05:38:03 CET 2010


On Thu, Mar 18, 2010 at 12:03 PM, Baptiste Coudurier
<baptiste.coudurier at gmail.com> wrote:
> On 03/18/2010 11:50 AM, Michael Niedermayer wrote:
>>
>> On Thu, Mar 18, 2010 at 04:50:31PM +0000, Loren Merritt wrote:
>>>
>>> On Thu, 18 Mar 2010, Michael Niedermayer wrote:
>>>>
>>>> On Wed, Mar 17, 2010 at 05:06:59PM -0700, Baptiste Coudurier wrote:
>>>>>
>>>>> -flags2 +psy (activated by default)
>>>>
>>>> but first, do we need a psy flag, is not setting some of the float
>>>> parameters
>>>> to 0 naturally disabling it? no i am not upto date with x264 encoding
>>>> options
>>>
>>> The psy flag also affects a number of minor psy optimizations that don't
>>> have their own strength variables.
>>
>> ok then
>>
>>
>>>
>>>>> +#define CODEC_FLAG2_SSIM ? ? ? ? ?0x00100000 ///< ?Compute SSIM during
>>>>> encoding
>>>>
>>>> is the value made available through AVFrame.error[] or just printed
>>>> to the terminal, printf would be a bit annoying, in light of av_log()
>>>> expectance of applications.
>>>
>>> Only printed, though libx264 supports an av_log callback to replace
>>> printf.
>>
>> i guess some GUIs (and us too for consistency to how we handle psnr)
>> would love to have this accessable per frame and overall at the end
>> in some struct
>>
>> for now we could just add a note to
>> CODEC_FLAG2_SSIM that the error[] values are undefined if this flag is set
>> if we plan to i the future store them there or maybe we could use a
>> seperate
>> ssim[] for that dunno?
>>
>>
>>>
>>>>> + ? ?/**
>>>>> + ? ? * AQ strength
>>>>> + ? ? * Reduces blocking and blurring in flat and textured areas. [1.0]
>>>>> + ? ? */
>>>>> + ? ?float aq_strength;
>>>>
>>>> is this semantically different from our *cplx_mask fields?
>>>
>>> It's a different algorithm, has a different range of valid inputs, and I
>>> recommend that people do use x264's aq but not use spatial_cplx_masking.
>>> Other than that, no.
>>
>> i wont reject this extra field but i would prefer if someone could just
>> port x264s algorithm (if its better which i assume) so that we have just
>> one field. This would keep the API from exploding into many codec specific
>> fields that will confuse everyone.
>> We could call that field aq_strength and put the old under #if version<...
>>
>
> Patch updated.
> Btw, I propose to enable mbtree flag by default since it works with all
> features now. Any objections ?

No objections, but remove +mbtree from all the preset files when you
do that (and make sure to add -mbtree to the fastest presets, the ones
without it).  You can check which ones are supposed to have
--no-mbtree using x264 --fullhelp.

Dark Shikari



More information about the ffmpeg-devel mailing list