[FFmpeg-devel] [RFC] Specifying KEYINT (-g) has no effect in libx264
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:
>> 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
>> 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
'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