[FFmpeg-devel] [PATCH] more libx264 parameters

[Baptiste Coudurier]

On 03/18/2010 09:38 PM, Jason Garrett-Glaser wrote:
> 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.

Great, applied and removed from presets.

-- 
Baptiste COUDURIER
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer                                  http://www.ffmpeg.org