diff options
author | Andreas Rheinhardt <andreas.rheinhardt@outlook.com> | 2023-10-15 21:34:43 +0200 |
---|---|---|
committer | Andreas Rheinhardt <andreas.rheinhardt@outlook.com> | 2024-06-12 11:47:49 +0200 |
commit | 9ce56f91c0e74b7cc34985fdb15050aa98aeded6 (patch) | |
tree | db85ee0adb0952c536b3fb30c80f4fc507856e79 /libavcodec/rv34.c | |
parent | 99d26939af3f0ef80f56debe458006abec3cbc71 (diff) | |
download | ffmpeg-9ce56f91c0e74b7cc34985fdb15050aa98aeded6.tar.gz |
avcodec/mpegpicture: Make MPVPicture refcounted
Up until now, an initialized MpegEncContext had an array of
MPVPictures (way more than were ever needed) and the MPVPicture*
contained in the MPVWorkPictures as well as the input_picture
and reordered_input_picture arrays (for the encoder) pointed
into this array. Several of the pointers could point to the
same slot and because there was no reference counting involved,
one had to check for aliasing before unreferencing.
Furthermore, given that these pointers were not ownership pointers
the pointers were often simply reset without unreferencing
the slot (happened e.g. for the RV30 and RV40 decoders) or
there were moved without resetting the src pointer (happened
for the encoders where the entries in the input_picture
and reordered_input_picture arrays were not reset).
Instead actually releasing these pictures was performed by looping
over the whole array and checking which one of the entries needed
to be kept. Given that the array had way too many slots (36),
this meant that more than 30 MPVPictures have been unnecessarily
unreferenced in every ff_mpv_frame_start(); something similar
happened for the encoder.
This commit changes this by making the MPVPictures refcounted
via the RefStruct API. The MPVPictures itself are part of a pool
so that this does not entail constant allocations; instead,
the amount of allocations actually goes down, because the
earlier code used such a large array of MPVPictures (36 entries) and
allocated an AVFrame for every one of these on every
ff_mpv_common_init(). In fact, the pool is only freed when closing
the codec, so that reinitializations don't lead to new allocations
(this avoids having to sync the pool in update_thread_context).
Making MPVPictures refcounted also has another key benefit:
It makes it possible to directly share them across threads
(when using frame-threaded decoding), eliminating ugly code
with underlying av_frame_ref()'s; sharing these pictures
can't fail any more.
The pool is allocated in ff_mpv_decode_init() for decoders,
which therefore can fail now. This and the fact that the pool
is not unreferenced in ff_mpv_common_end() also necessitated
to mark several mpegvideo-decoders with the FF_CODEC_CAP_INIT_CLEANUP
flag.
*: This also means that there is no good reason any more for
ff_mpv_common_frame_size_change() to exist.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Diffstat (limited to 'libavcodec/rv34.c')
-rw-r--r-- | libavcodec/rv34.c | 6 |
1 files changed, 4 insertions, 2 deletions
diff --git a/libavcodec/rv34.c b/libavcodec/rv34.c index 9e087cb16c..861c533d06 100644 --- a/libavcodec/rv34.c +++ b/libavcodec/rv34.c @@ -1510,7 +1510,9 @@ av_cold int ff_rv34_decode_init(AVCodecContext *avctx) MpegEncContext *s = &r->s; int ret; - ff_mpv_decode_init(s, avctx); + ret = ff_mpv_decode_init(s, avctx); + if (ret < 0) + return ret; s->out_format = FMT_H263; avctx->pix_fmt = AV_PIX_FMT_YUV420P; @@ -1632,7 +1634,7 @@ int ff_rv34_decode_frame(AVCodecContext *avctx, AVFrame *pict, if (s->next_pic.ptr) { if ((ret = av_frame_ref(pict, s->next_pic.ptr->f)) < 0) return ret; - s->next_pic.ptr = NULL; + ff_mpv_unref_picture(&s->next_pic); *got_picture_ptr = 1; } |