[FFmpeg-devel] Regression: r20954-5 broke threads auto in libx264

Baptiste Coudurier baptiste.coudurier
Wed Jan 20 23:56:48 CET 2010

On 01/20/2010 02:53 PM, Michael Niedermayer wrote:
> On Wed, Jan 20, 2010 at 11:46:05PM +0100, Michael Niedermayer wrote:
>> On Wed, Jan 20, 2010 at 01:27:34PM -0800, Jason Garrett-Glaser wrote:
>>> On Wed, Jan 20, 2010 at 1:25 PM, Baptiste Coudurier
>>> <baptiste.coudurier at gmail.com>  wrote:
>>>> On 01/20/2010 01:13 PM, Jason Garrett-Glaser wrote:
>>>>> -threads 0 now no longer works to specify auto threads in libx264.  We
>>>>> have received a ton of complaints from users already about ffmpeg
>>>>> performance going down massively in the past few weeks.
>>>>> This is a serious regression.
>>>>> If nobody can come up with a reasonable fix for this in the next day
>>>>> or two, I will disconnect the threads option in libx264.c, forcing it
>>>>> to auto in all cases.
>>>> I very strongly object to using auto in all cases.
>>> I would too.  Here's my order of preference:
>>> 1) Auto is default, user can specify if he wants something else.
>> i agree but until ffmpeg itself supports auto there can be no
>> default=auto
>> because the default should match between encoders and the default
>> should work.
>> This needs a volunteer to implement auto thread support in ffmpeg.
> Iam really not happy about libx264 and the rest of ffmpeg behaving
> quite differently. I dont mind seriously on a temporary scale but i
> definitly would prefer that we work toward keeping their defaults
> the same and not making them more different

Well, maybe it's the right time to improve ffmpeg defaults ?

I would be ok with that.

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

More information about the ffmpeg-devel mailing list