Am 08.08.24 um 17:29 schrieb Zhao Zhili:
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?
Sure.
here's the original report:
https://github.com/mpv-android/mpv-android/issues/966
summary:
mpv's hwdec code uses a single surface to facilitate zero-copy video
playback. Keeping an active MediaCodec instance connected to the surface
blocks the same surface from being used with a different MediaCodec
instance.
However mpv also keeps a reference to the last rendered frame alive even
when switching between files. It also flushes the codec when it's done
with a file. This leads to a situation where hw_buffer_count == 0 &&
refcount > 1.
If you were to say that this should be fixed in mpv I would agree and I
have indeed proposed a PR for this. But I noticed we're never calling
stop() in mediacodecdec and it's a very simple remedy.
_______________________________________________
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".
