[FFmpeg-devel] [RFC] ffmpeg: default to single thread when hwaccel is active

[Timo Rothenpieler]

On 30.09.2021 02:02, Andreas Rheinhardt wrote:
> Timo Rothenpieler:
>> On 29.09.2021 19:31, Dennis Mungai wrote:
>>> On Wed, 29 Sept 2021 at 20:22, Timo Rothenpieler <timo at rothenpieler.org>
>>> wrote:
>>>
>>>> On 29.09.2021 19:17, Dennis Mungai wrote:
>>>>> A potential downside to this would be on QSV's side, which needs at
>>>>> least
>>>>> 2  threads to prevent dead-locking, see
>>>>>
>>>> https://github.com/Intel-Media-SDK/MediaSDK/blob/master/_studio/mfx_lib/scheduler/linux/src/mfx_scheduler_core_ischeduler.cpp#L90-L93
>>>>
>>>>
>>>> Is that even controlled by the avcodec threads parameter?
>>>> I can't find any occurrence of "numberOfThreads" anywhere in the entire
>>>> codebase.
>>>>
>>>>
>>> See this patchwork:
>>> https://patchwork.ffmpeg.org/project/ffmpeg/patch/20210408070929.860244-1-haihao.xiang@intel.com/
>>>
>>> Submitted  by Haihao Xiang, CC'ed herein.
>>
>> That almost makes me think we'd need a per-hwaccel default of the thread
>> count.
>> Preferably not hacked as hard coded list into ffmpeg.c
>>
> 
> This can be done via AVCodecDefaults: The qsv codecs should use a thread
> default of "auto" and ffmpeg.c should check whether the threads
> parameter has been overridden by an AVCodecDefault (by checking whether
> it is set to its default value) before overriding it in case the user
> did not explicitly set something.

Does that also work for hwaccels though?
For the most part, the codec is always the native hevc/h264/... decoder.

> - Andreas
> 
> PS: The qsv patch also needs to check the AV_CODEC_CAP_OTHER_THREADS cap
> (so that user know that setting the threads option makes sense).

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4494 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20210930/2f466922/attachment.bin>