FFmpeg
Typedefs | Functions | Variables
doc/multithreading.txt File Reference

Typedefs

using clients = =============================================Slice threading - *The client 's draw_horiz_band() must be thread-safe according to the comment in avcodec.h. Frame threading - *Restrictions with slice threading also apply. *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
 

Functions

the pkt_dts and pkt_pts fields in AVFrame will work as usual Restrictions on codec whose streams don t reset across will not work because their bitstreams cannot be decoded in parallel *The contents of buffers must not be read before ff_progress_frame_await () has been called on them. reget_buffer() and buffer age optimizations no longer work. *The contents of buffers must not be written to after ff_progress_frame_report() has been called on them. This includes draw_edges(). Porting codecs to frame threading
 
the pkt_dts and pkt_pts fields in AVFrame will work as usual Restrictions on codec whose streams don t reset across will not work because their bitstreams cannot be decoded in parallel *The contents of buffers must not be read before as well as code calling get_buffer ()
 
the pkt_dts and pkt_pts fields in AVFrame will work as usual Restrictions on codec whose streams don t reset across will not work because their bitstreams cannot be decoded in parallel *The contents of buffers must not be read before as well as code calling up to before the decode process starts Call ff_thread_finish_setup () afterwards. If some code can 't be moved
 
the pkt_dts and pkt_pts fields in AVFrame will work as usual Restrictions on codec whose streams don t reset across will not work because their bitstreams cannot be decoded in parallel *The contents of buffers must not be read before as well as code calling up to before the decode process starts Call have update_thread_context () run it in the next thread. Add AV_CODEC_CAP_FRAME_THREADS to the codec capabilities. There will be very little speed gain at this point but it should work. Use ff_thread_get_buffer()(or ff_progress_frame_get_buffer() in case you have inter-frame dependencies and use the ProgressFrame API) to allocate frame buffers. Call ff_progress_frame_report() 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 called anywhere
 
the pkt_dts and pkt_pts fields in AVFrame will work as usual Restrictions on codec whose streams don t reset across will not work because their bitstreams cannot be decoded in parallel *The contents of buffers must not be read before as well as code calling up to before the decode process starts Call have as it s useful too and the implementation is trivial when you re doing this Note that draw_edges () needs to be called before reporting progress. Before accessing a reference frame or its MVs
 

Variables

FFmpeg multithreading methods
 
the pkt_dts and pkt_pts fields in AVFrame will work as usual Restrictions on codec implementations
 
the pkt_dts and pkt_pts fields in AVFrame will work as usual Restrictions on codec whose streams don t reset across frames
 

Typedef Documentation

◆ clients

using clients = ============================================= Slice threading - * The client's draw_horiz_band() must be thread-safe according to the comment in avcodec.h. Frame threading - * Restrictions with slice threading also apply. * 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

Definition at line 25 of file multithreading.txt.

Function Documentation

◆ ff_progress_frame_await()

the pkt_dts and pkt_pts fields in AVFrame will work as usual Restrictions on codec whose streams don t reset across will not work because their bitstreams cannot be decoded in parallel* The contents of buffers must not be read before ff_progress_frame_await ( )

◆ get_buffer()

the pkt_dts and pkt_pts fields in AVFrame will work as usual Restrictions on codec whose streams don t reset across will not work because their bitstreams cannot be decoded in parallel* The contents of buffers must not be read before as well as code calling get_buffer ( )

◆ ff_thread_finish_setup()

the pkt_dts and pkt_pts fields in AVFrame will work as usual Restrictions on codec whose streams don t reset across will not work because their bitstreams cannot be decoded in parallel* The contents of buffers must not be read before as well as code calling up to before the decode process starts Call ff_thread_finish_setup ( )

◆ update_thread_context()

the pkt_dts and pkt_pts fields in AVFrame will work as usual Restrictions on codec whose streams don t reset across will not work because their bitstreams cannot be decoded in parallel* The contents of buffers must not be read before as well as code calling up to before the decode process starts Call have update_thread_context ( )

◆ draw_edges()

the pkt_dts and pkt_pts fields in AVFrame will work as usual Restrictions on codec whose streams don t reset across will not work because their bitstreams cannot be decoded in parallel* The contents of buffers must not be read before as well as code calling up to before the decode process starts Call have as it s useful too and the implementation is trivial when you re doing this Note that draw_edges ( )

Variable Documentation

◆ methods

FFmpeg multithreading methods
Initial value:
==============================================
FFmpeg provides two methods for multithreading codecs.
Slice threading decodes multiple parts of a frame at the same time

Definition at line 2 of file multithreading.txt.

◆ implementations

the pkt_dts and pkt_pts fields in AVFrame will work as usual Restrictions on codec implementations
Initial value:
==============================================
Slice threading -
None except that there must be something worth executing in parallel.
Frame threading -
* Codecs can only accept entire pictures per packet.
* Codecs similar to ffv1

Definition at line 29 of file multithreading.txt.

◆ frames

the pkt_dts and pkt_pts fields in AVFrame will work as usual Restrictions on codec whose streams don t reset across frames

Definition at line 36 of file multithreading.txt.

be
it s the only field you need to keep assuming you have a context There is some magic you don t need to care about around this just let it be(in the first position) for now. Options ------- Then comes the options array. This is what will define the user accessible options. For example
to
const char * to
Definition: webvttdec.c:35
Slice
Definition: magicyuv.c:40
codecs
static const struct codec_string codecs[]
methods
FFmpeg multithreading methods
Definition: multithreading.txt:2
a
The reader does not expect b to be semantically here and if the code is changed by maybe adding a a division or other the signedness will almost certainly be mistaken To avoid this confusion a new type was SUINT is the C unsigned type but it holds a signed int to use the same example SUINT a
Definition: undefined.txt:41
that
if it could not because there are no more it should return AVERROR_EOF The typical implementation of request_frame for a filter with several inputs will look like that
Definition: filter_design.txt:273
frame
these buffered frames must be flushed immediately if a new input produces new the filter must not call request_frame to get more It must just process the frame or queue it The task of requesting more frames is left to the filter s request_frame method or the application If a filter has several the filter must be ready for frames arriving randomly on any input any filter with several inputs will most likely require some kind of queuing mechanism It is perfectly acceptable to have a limited queue and to drop frames when the inputs are too unbalanced request_frame For filters that do not use the this method is called when a frame is wanted on an output For a it should directly call filter_frame on the corresponding output For a if there are queued frames already one of these frames should be pushed If the filter should request a frame on one of its repeatedly until at least one frame has been pushed Return or at least make progress towards producing a frame
Definition: filter_design.txt:264