Frame threading -
* Restrictions with slice threading also apply.
-* For best performance, the client should set thread_safe_callbacks if it
- provides a thread-safe get_buffer() callback.
+* Custom get_buffer2() and get_format() callbacks must be thread-safe.
* There is one frame of delay added for every thread beyond the first one.
Clients must be able to handle this; the pkt_dts and pkt_pts fields in
AVFrame will work as usual.
some code can't be moved, have update_thread_context() run it in the next
thread.
-If the codec allocates writable tables in its init(), add an init_thread_copy()
-which re-allocates them for other threads.
-
Add AV_CODEC_CAP_FRAME_THREADS to the codec capabilities. There will be very little
speed gain at this point but it should work.
If there are inter-frame dependencies, so the codec calls
-ff_thread_report/await_progress(), set AVCodecInternal.allocate_progress. The
+ff_thread_report/await_progress(), set FF_CODEC_CAP_ALLOCATE_PROGRESS in
+AVCodec.caps_internal and use ff_thread_get_buffer() to allocate frames. The
frames must then be freed with ff_thread_release_buffer().
-Otherwise leave it at zero and decode directly into the user-supplied frames.
+Otherwise decode directly into the user-supplied frames.
Call ff_thread_report_progress() after some part of the current picture has decoded.
A good place to put this is where draw_horiz_band() is called - add this if it isn't