Blender Git Commit Log

FFmpeg: improve threading settings

Generalize threading settings in proxy building and use them for encoding/decoding in general.
Check codec capabilities, prefer FF_THREAD_FRAME threading over FF_THREAD_SLICE and automatic thread count over setting it explicitly.

ffmpeg-codecs man page suggests that `threads` option is global and used by codecs, that supports this option.
Form some tests I have done, it seems that `av_dict_set_int(&codec_opts, "threads", BLI_system_thread_count(), 0);` has same effect as
```
pCodecCtx->thread_count = BLI_system_thread_count();
pCodecCtx->thread_type = FF_THREAD_FRAME;
```

Looking at `ff_frame_thread_encoder_init()` code, these cases are not equivalent. It is probably safer to leave threading setup on libavcodec than setting up each codec threading individually.

From what I have read so far, frame multithreading should be faster than slice multithreading. Slice multithreading is mainly used for low latency streaming.

When running Blender with `--debug-ffmpeg` it complains about `pCodecCtx->thread_count = BLI_system_thread_count()` that using thread count above 16 is not recommended. Using too many threads can negatively affect image quality, but I am not sure if this is the case for decoding as well - see https://streaminglearningcenter.com/blogs/ffmpeg-command-threads-how-it-affects-quality-and-performance.html This is fine for proxies but may be undesirable for final renders.

Number of threads is limited by image size, because of size of motion vectors, so if it is possible let libavcodec determine optimal thread count.

-----------

Performance difference:
Proxy building: None
Playback speed: 2x better on 1920x1080 sample h264 file
Rendering speed: None on 1920x1080 sample h264 file, there is improvement with codecs that do support FF_THREAD_FRAME for encoding like MPNG