[FFmpeg-user] libx264 options through FFmpeg

[Thomas Worth]

On Thu, Jun 30, 2011 at 8:39 AM, Thomas Worth <dev at rarevision.com> wrote:
> On Thu, Jun 30, 2011 at 8:19 AM, Tim Nicholson <tim.nicholson at bbc.co.uk> wrote:
>> On 30/06/11 15:30, Thomas Worth wrote:
>>>
>>> On Thu, Jun 30, 2011 at 3:22 AM, Tim Nicholson<tim.nicholson at bbc.co.uk>
>>>  wrote:
>>>>
>>>> On 30/06/11 11:08, Tim Nicholson wrote:
>>>>>
>>>>> On 28/06/11 17:51, Thomas Worth wrote:
>>>>>>
>>>>>> On Tue, Jun 28, 2011 at 8:31 AM, Tim
>>>>>> Nicholson<tim.nicholson at bbc.co.uk>  wrote:
>>>>>>>
>>>>>>> On 22/06/11 06:43, Thomas Worth wrote:
>>>>>>>>
>>>>>>>> While I've historically used a standalone x264 binary to do encoding
>>>>>>>> by piping yuv420p from FFmpeg, I thought I'd try libx264 through
>>>>>>>> FFmpeg since it's certainly more convenient.
>>>>>>>>
>>>>>>>> [....]
>>>>>>>>
>>>>>>>> If I can safely pass all my options via -x264opts then I'll just use
>>>>>>>> that from now on and disregard FFmpeg's x264 interface.
>>>>>>>
>>>>>>> But what about options that require colon delimited parameters
>>>>>>> themselves
>>>>>>> such as "--sar 1:1"?
>>>>>>
>>>>>> If I use a forward slash (sar=16/9), libx264 doesn't complain but it
>>>>>> also doesn't use the supplied ratio. It seems to default to "1/1"
>>>>>> every time.
>>>>>
>>>>> I have tried sar="1:1" and it hasn't complained about that.
>>>>>
>>>>> Howver it doesn't want to accept a profile specification. Using:-
>>>>>
>>>>> ffmpeg -i $in_file -vcodec libx264 -pix_fmt yuv420p -s 1920x1080 -an \
>>>>> -x264opts bitrate=35000:preset=veryslow:tune=$tune:\
>>>>> [...]
>>>>>
>>>>> I get a:-
>>>>> "[libx264 @ 0x12e0960] bad value for 'preset': 'veryslow'"
>>>>>
>>>>> error. replace "veryslow" with whatever you like from the legal list.
>>>>>
>>>>
>>>> Actually its worse than that, it also doesn't accept any of the --tune
>>>> parameters, or seem to handle options that don't have values, e.g --tff
>>>
>>> Yes, I had the same problems. What I found is that libx264 seems to
>>> take all parameters through x264opts except the following:
>>>
>>> preset
>>> profile
>>> tune
>>>
>>> For some reason, it says "bad value for preset..." etc. But, and check
>>> this out, if you supply any random value, you get the same error: "bad
>>> value for 'giggity': 'goo'". So, it doesn't look like it even
>>> recognizes it.
>>>
>>> I do this:
>>>
>>> ffmpeg -i file.mov -an -vcodec libx264 -preset medium -profile
>>> baseline -tune film -x264opts $OPTS out.mp4
>>>
>>> That seems to be working.
>>>
>>
>> Well so it does.... Thanks
>>
>>> I just saw your email about parameters that don't take values, and
>>> you're correct. tff=1 or aud=1 or 8x8dct=0 is the way you turn them on
>>> or off.
>>>
>>
>> Or not quite as it happens.
>>
>> if you set :fake-interlaced=1: the x264 header showing the set parameters
>> reports "interlaced=fake".
>>
>> However if you set tff=1 or bff=1 you get "interlaced=0" suggesting that
>> these are not working.
>>
>> btw I see there is now a "bluray-compat" switch that saves having to
>> explicitly specify a number of others, such as nal_hrd and b_pyramid.
>
> Did you check libx264's output in the terminal during encoding? It
> should show you a transcript of all of the settings passed. That's how
> I was able to confirm the "param=1" trick. I'll go back and test it
> and see if it's choking on options that use hyphens.

Sorry, I misread what you wrote. Disregard that. I tried this just
now, and yep, I can't get libx264 to say it's encoding as interlaced,
either. It just says "interlaced=0" as you mentioned. Perhaps there is
some other check that x264 is doing to ensure the input is actually
interlaced, or perhaps it's influenced by the preset or tune
parameter. You should be warned about this, if that is the case as you
are when you try to encode interlaced with the baseline profile
(baseline doesn't support interlaced, apparently).