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 _______________________________________________ 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".
