[FFmpeg-devel] [RFC] Specifying KEYINT (-g) has no effect in libx264

Baptiste Coudurier baptiste.coudurier at gmail.com
Mon May 23 10:32:15 CEST 2011

On 5/22/11 8:33 PM, Michael Niedermayer wrote:
> On Sun, May 22, 2011 at 10:40:07PM +0200, Stefano Sabatini wrote:
>> Hi,
>> see issue #157.
>> The problem was possibly introduced in:
>> commit 0140d3f0921e5cbb6ea8706acb0307f7ff57a133
>> Author: Baptiste Coudurier <baptiste.coudurier at gmail.com>
>> Date:   Sat Apr 16 16:50:50 2011 -0700
>>     In libx264 wrapper, add -preset and -tune options
>> and depends on the fact that x264_param_default_preset() which is
>> called in x264_init(), calls x264_param_default() which defaults the
>> already set options.
>> Indeed order of options matters, with the current mechanism options
>> are set in the relevant contexts, and globally processed in the object
>> initialization, so the order specified on the commandline is basically
>> ignored.
>> In the case of libx264 we may process profile/preset *before* the
>> other options set in the context, so that specific settings will
>> override profile/preset information.

No, order doesn't matter, as long as a preset is specified, it will
override other options.

>> This has the problem that most of the times user-set options are
>> changed to medium profile or libx264 will complain&exit, see:
>> thus making fine-tuned user options pointless (since they are changed
>> to medium preset and/or will be rejected by libx264).

No, you can still specify fine-tuned options without a preset.

> I see 3 obvious solutions
> A. is mplayers to just use -x264opts which ive added
> B. keep track of which options have been set by the user and which are
>    default.

'B' is how it should be done. It's trivial, just remap "g" in the
libx264.c the way weightp was mapped.

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

More information about the ffmpeg-devel mailing list