> On Aug 8, 2024, at 00:27, sfan5 <sf...@live.de> wrote:
>
> Hi all,
>
> attached is a small fix for the MediaCodec code. Tested on Android 14.
> This can free up vital resources in case of using multiple
> decoding instances and there are buffer references left over
> and not immediately cleaned up.
>
> Signed-off-by: sfan5 <sf...@live.de>
> ---
> libavcodec/mediacodecdec_common.c | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/libavcodec/mediacodecdec_common.c
> b/libavcodec/mediacodecdec_common.c
> index d6f91e6e89..c888dea8cf 100644
> --- a/libavcodec/mediacodecdec_common.c
> +++ b/libavcodec/mediacodecdec_common.c
> @@ -841,6 +841,18 @@ int ff_mediacodec_dec_flush(AVCodecContext *avctx,
> MediaCodecDecContext *s)
>
> int ff_mediacodec_dec_close(AVCodecContext *avctx, MediaCodecDecContext *s)
> {
> + if (!s)
> + return 0;
> +
> + if (s->codec) {
> + if (atomic_load(&s->hw_buffer_count) == 0) {
> + ff_AMediaCodec_stop(s->codec);
> + av_log(avctx, AV_LOG_DEBUG, "MediaCodec %p stopped\n", s->codec);
> + } else {
> + av_log(avctx, AV_LOG_DEBUG, "Not stopping MediaCodec (there are
> buffers pending)\n");
> + }
> + }
> +
Could you elaborate on how this resolved the issue?
If hw_buffer_count is zero, isn’t MediaCodecDecContext will be released
immediately?
If hw_buffer_count isn’t zero, the patch make no real change, so how does this
patch work?
> ff_mediacodec_dec_unref(s);
>
> return 0;
> --
> 2.46.0
>
>
> <0001-avcodec-mediacodecdec-call-MediaCodec.stop-on-close.patch>_______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
