On Tue, 10 Jan 2017 15:42:33 +0100 Anton Khirnov <[email protected]> wrote:
> This is a constant codec property, so a capability flag is more appropriate. > --- > doc/multithreading.txt | 5 +++-- > libavcodec/h264dec.c | 4 +--- > libavcodec/hevcdec.c | 3 +-- > libavcodec/internal.h | 20 +++++--------------- > libavcodec/mimic.c | 3 +-- > libavcodec/mpeg4videodec.c | 2 +- > libavcodec/pthread_frame.c | 4 ++-- > libavcodec/rv30.c | 1 + > libavcodec/rv34.c | 2 -- > libavcodec/rv40.c | 1 + > libavcodec/vp3.c | 6 +++--- > libavcodec/vp8.c | 2 +- > libavcodec/vp9.c | 3 +-- > 13 files changed, 21 insertions(+), 35 deletions(-) > > diff --git a/doc/multithreading.txt b/doc/multithreading.txt > index 9b27b10..df9cd4e 100644 > --- a/doc/multithreading.txt > +++ b/doc/multithreading.txt > @@ -58,9 +58,10 @@ Add 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 The sentence doesn't look like proper English (both before and after your change) - maybe that could be fixed too? > 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. _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
