[FFmpeg-devel] [PATCH 03/14] pthread_frame: merge the functionality for normal decoder init and init_thread_copy

David Bryant david at wavpack.com
Sat Mar 28 00:51:19 EET 2020


On 3/27/20 5:57 AM, Anton Khirnov wrote:
> The current design, where
> - proper init is called for the first per-thread context
> - first thread's private data is copied into private data for all the
>   other threads
> - a "fixup" function is called for all the other threads to e.g.
>   allocate dynamically allocated data
> is very fragile and hard to follow, so it is abandoned. Instead, the
> same init function is used to init each per-thread context. Where
> necessary, AVCodecInternal.is_copy can be used to differentiate between
> the first thread and the other ones (e.g. for decoding the extradata
> just once).
> ---

I'm not sure I fully understand this change. You mention that AVCodecInternal.is_copy can be used where different treatment
might be necessary for subsequent threads, and I see that done in a couple places, but in most cases you have simply deleted the
init_thread_copy() function even when it's not at all obvious (to me anyway) that that won't break the codec.

Specifically this will break WavPack because now it will be allocating a new dsdctx for every thread instead of sharing one
between all threads. I am happy to fix and test this case once the patch goes in, but is the intent of this patch that the
respective authors will find and fix all the breakages? Or did I just happen to catch the one case you missed?

Cheers!

-David



More information about the ffmpeg-devel mailing list