Commit | Line | Data |
---|---|---|
2ba45a60 DM |
1 | FFmpeg multithreading methods |
2 | ============================================== | |
3 | ||
4 | FFmpeg provides two methods for multithreading codecs. | |
5 | ||
6 | Slice threading decodes multiple parts of a frame at the same time, using | |
7 | AVCodecContext execute() and execute2(). | |
8 | ||
9 | Frame threading decodes multiple frames at the same time. | |
10 | It accepts N future frames and delays decoded pictures by N-1 frames. | |
11 | The later frames are decoded in separate threads while the user is | |
12 | displaying the current one. | |
13 | ||
14 | Restrictions on clients | |
15 | ============================================== | |
16 | ||
17 | Slice threading - | |
18 | * The client's draw_horiz_band() must be thread-safe according to the comment | |
19 | in avcodec.h. | |
20 | ||
21 | Frame threading - | |
22 | * Restrictions with slice threading also apply. | |
23 | * For best performance, the client should set thread_safe_callbacks if it | |
24 | provides a thread-safe get_buffer() callback. | |
25 | * There is one frame of delay added for every thread beyond the first one. | |
26 | Clients must be able to handle this; the pkt_dts and pkt_pts fields in | |
27 | AVFrame will work as usual. | |
28 | ||
29 | Restrictions on codec implementations | |
30 | ============================================== | |
31 | ||
32 | Slice threading - | |
33 | None except that there must be something worth executing in parallel. | |
34 | ||
35 | Frame threading - | |
36 | * Codecs can only accept entire pictures per packet. | |
37 | * Codecs similar to ffv1, whose streams don't reset across frames, | |
38 | will not work because their bitstreams cannot be decoded in parallel. | |
39 | ||
40 | * The contents of buffers must not be read before ff_thread_await_progress() | |
41 | has been called on them. reget_buffer() and buffer age optimizations no longer work. | |
42 | * The contents of buffers must not be written to after ff_thread_report_progress() | |
43 | has been called on them. This includes draw_edges(). | |
44 | ||
45 | Porting codecs to frame threading | |
46 | ============================================== | |
47 | ||
48 | Find all context variables that are needed by the next frame. Move all | |
49 | code changing them, as well as code calling get_buffer(), up to before | |
50 | the decode process starts. Call ff_thread_finish_setup() afterwards. If | |
51 | some code can't be moved, have update_thread_context() run it in the next | |
52 | thread. | |
53 | ||
54 | If the codec allocates writable tables in its init(), add an init_thread_copy() | |
55 | which re-allocates them for other threads. | |
56 | ||
57 | Add CODEC_CAP_FRAME_THREADS to the codec capabilities. There will be very little | |
58 | speed gain at this point but it should work. | |
59 | ||
60 | If there are inter-frame dependencies, so the codec calls | |
61 | ff_thread_report/await_progress(), set AVCodecInternal.allocate_progress. The | |
62 | frames must then be freed with ff_thread_release_buffer(). | |
63 | Otherwise leave it at zero and decode directly into the user-supplied frames. | |
64 | ||
65 | Call ff_thread_report_progress() after some part of the current picture has decoded. | |
66 | A good place to put this is where draw_horiz_band() is called - add this if it isn't | |
67 | called anywhere, as it's useful too and the implementation is trivial when you're | |
68 | doing this. Note that draw_edges() needs to be called before reporting progress. | |
69 | ||
70 | Before accessing a reference frame or its MVs, call ff_thread_await_progress(). |