[FFmpeg-devel] [FFmpeg-cvslog] pthread_frame: merge the functionality for normal decoder init and init_thread_copy

[James Darnley]

On 2020-04-10 16:53, Anton Khirnov wrote:
> ffmpeg | branch: master | Anton Khirnov <anton at khirnov.net> | Mon Jan  9 18:04:42 2017 +0100| [1f4cf92cfbd3accbae582ac63126ed5570ddfd37] | committer: Anton Khirnov
> 
> pthread_frame: merge the functionality for normal decoder init and init_thread_copy
> 
> 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).
> 
>> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=1f4cf92cfbd3accbae582ac63126ed5570ddfd37

This commit has caused unexpected behavior in one use of the API that I
encountered.

The AVCodecContexts that are used for get_buffer2 calls have different
delay values in them.  Setting 2 threads I see the value alternating
between 0 and 1 for every call.

That constant changing value, from the point of view of the thing
reading it, is what is causing the unexpected behavior.