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 <t...@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, seehttps://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.xi...@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.cThis 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).
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
