[FFmpeg-devel] [PATCH][RFC] avcodec: disallow hwaccel with frame threads

Andy Furniss adf.lists at gmail.com
Wed Jan 20 10:59:12 CET 2016


wm4 wrote:
> On Wed, 20 Jan 2016 00:42:18 +0000 Andy Furniss <adf.lists at gmail.com>
> wrote:
>
>> Hendrik Leppkes wrote:
>>
>>>>> I do not agree that it should be a warning. As outlined in
>>>>> the commit message and this thread, there are serious flaws
>>>>> with frame threading and hwaccel.
>>>>
>>>> I'm fine with it being an error, but since it is an API change,
>>>> it should follow the usual deprecation period to allow
>>>> downstream users time to fix it. Meanwhile it can be a warning
>>>> so that people notice the problem.
>>>
>>> Its fundamentally broken, and making it a warning would
>>> re-introduce known crashes. So no.
>>
>> So are the flaws in ffmpeg or particular drivers?
>>
>> It does seem a shame perf wise, I've been testing my AMD UVD
>> decode recently and for 500 UHD frames in a really high bitrate
>> h264 file it's like -
>>
>> ffmpeg threaded = 16 sec.
>>
>> ffmpeg single thread = 20 sec.
>
> With or without hwaccel?

Both are with hwaccel. ffmpeg 2.8.4 cli

Admittedly a very concocted benchmark with a very high bitrate sample.

I know on normal x264 stuff my CPU could beat GPU anyway as the copy
back seems to hurt quite a lot/UVD is for playing.

For future GPUs that will do hevc I guess it could be more relevant.

>> gstreamer vaapi 14 sec.
>>
>> gstreamer omx 10 sec.
>>
>> the omx is a faster as the others do nv12 -> I420 on cpu (AFAICT)
>>
>> Maybe -threads 1 hurts perf by limiting the format conversion as
>> well?
>>
>> Is there a way to get whatever the h/w spits out (nv12) directly?
>> Trying to ask for nv12 seemed to get a double conversion.
>
> Both vdpau and vaapi can retrieve image data as nv12.

With ffmpeg cli?


More information about the ffmpeg-devel mailing list