Generalize threading settings in proxy building and use them for encoding and 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 all over the internet, 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 Scrubbing: Hard to quantify, but it's much more responsive Rendering speed: None on 1920x1080 sample h264 file, there is improvement with codecs that do support FF_THREAD_FRAME for encoding like MPNG Reviewed By: sergey Differential Revision: https://developer.blender.org/D10791
The following 4 steps to adding a new image format to blender, its probably easiest to look at the png code for a clean clear example, animation formats are a bit more complicated but very similar: Step 1: create a new file named after the format for example lets say we were creating an openexr read/writer use openexr.c It should contain functions to match the following prototypes: struct ImBuf *imb_loadopenexr(unsigned char *mem,int size,int flags); /* Use one of the following depending on what's easier for your file format */ short imb_saveopenexr(struct ImBuf *ibuf, FILE myfile, int flags); short imb_saveopenexr(struct ImBuf *ibuf, char *myfile, int flags); /* Used to test if its the correct format int IMB_is_openexr(void *buf); Step 2: Add your hooks to read and write the image format these go in writeimage.c and readimage.c just look at how the others are done Step 3: Add in IS_openexr to blender/source/blender/imbuf/IMB_imbuf_types.h Add in R_openexr to source/blender/makesdna/DNA_scene_types.h Step 4: Add your hooks to the gui. source/blender/src/buttons_scene.c source/blender/src/toets.c source/blender/src/writeimage.c Step 5: edit the following files: blender/source/blender/imbuf/intern/util.c blender/source/blender/src/filesel.c blender/source/blender/src/screendump.c and add your extension so that your format gets recognized in the thumbnails. Step 6: Alter the build process: For cmake you need to edit blender/source/blender/imbuf/CMakeLists.txt and add in your additional files to source_files. If you have any external library info you will also need to add that to the various build processes. Step 7: Its also good to add your image format to: makepicstring in blender/source/blender/blenkernel/intern/image.c