On Wed, 2012-01-18 at 06:35 -0800, Ronald S. Bultje wrote: > On Wed, Jan 18, 2012 at 5:52 AM, Janne Grunau <[email protected]> wrote: > > On 2012-01-18 12:46:28 +0000, Måns Rullgård wrote: > >> "Ronald S. Bultje" <[email protected]> writes: > >> > On Wed, Jan 18, 2012 at 2:46 AM, Janne Grunau <[email protected]> > >> > wrote: > >> >> Users of libavcodec could break if they do not threadsafe callbacks. > >> >> Avconv and avplay still use -threads auto if not specified. > >> > > >> > What callbacks? > >> > >> get_buffer() and friends I presume, since there are no others.
get_buffer, draw_horiz_band, av_log at least. > > > > get/release_buffer are safe since we call them only from the calling > > thread when thread_safe_callbacks is not set. > > > > Uoti was worrying about draw_horiz_band. A custom av_log cb might be > > problematic too although would suspect that it'll just cause message > > corruption. > > I wonder how draw_horiz_band is used in this context? Uoti? Setting a thread-unsafe draw_horiz_band() was perfectly valid as long as you did not explicitly set a thread count greater than 1. Suddenly automatically enabling threads without warning breaks API/ABI in this case (now the application may get callbacks from different threads, and outside of the times it calls libavcodec). I tested this and found a case where it was actually possible to trigger a crash in mplayer code due to this issue. There's a draw_horiz_band() callback which must be disabled when threading is used; the code calling libavcodec disabled it when it explicitly requested multiple threads. But if libavcodec enables threading behind the application's back when the application thinks threads are not used this triggers a crash. AFAIK it was never an API requirement to explicitly change thread count from the default 0 to 1 if you want single-threaded semantics. _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
