[FFmpeg-devel] [PATCH] more libx264 parameters

[Michael Niedermayer]

On Thu, Mar 18, 2010 at 12:03:57PM -0700, Baptiste Coudurier 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 ?
>
> -- 
> Baptiste COUDURIER
> Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
> FFmpeg maintainer                                  http://www.ffmpeg.org

>  avcodec.h |   46 +++++++++++++++++++++++++++++++++++++++++++++-
>  libx264.c |   15 ++++++++++++++-
>  options.c |    9 ++++++++-
>  3 files changed, 67 insertions(+), 3 deletions(-)
> 34283027adaef6bd1caa5c0c4c4cfa7601cd49ae  x264_options_2.patch

no objections 

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

He who knows, does not speak. He who speaks, does not know. -- Lao Tsu
-------------- 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/20100323/648a6f30/attachment.pgp>