On 10/06/2017 10:01 PM, Mark Thompson wrote:
On 06/10/17 20:53, Mark Thompson wrote:
On 06/10/17 08:52, Jorge Ramirez-Ortiz wrote:
It occurs when the codec is closed while buffer references still
exist. This is a regression from the original patchset where support
for this use-case was implemented.
The regression occurred while cleaning the code for the last patchset
(decoding was tested only with ffplay which disposes of the buffer
straightaway hence the feature went in broken/untested)
---
libavcodec/v4l2_m2m.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/libavcodec/v4l2_m2m.c b/libavcodec/v4l2_m2m.c
index bd96a6d..5e85bcb 100644
--- a/libavcodec/v4l2_m2m.c
+++ b/libavcodec/v4l2_m2m.c
@@ -331,8 +331,10 @@ int ff_v4l2_m2m_codec_end(AVCodecContext *avctx)
ff_v4l2_context_release(&s->output);
- if (atomic_load(&s->refcount))
- av_log(avctx, AV_LOG_ERROR, "ff_v4l2m2m_codec_end leaving pending
buffers\n");
+ if (atomic_load(&s->refcount)) {
+ av_log(avctx, AV_LOG_DEBUG, "ff_v4l2m2m_codec_end leaving pending
buffers\n");
+ return 0;
+ }
ff_v4l2_context_release(&s->capture);
sem_destroy(&s->refsync);
Trying to test this, I segfault when decoding finishes with this patch applied
(exynos s5p-mfc):
(gdb) r
Starting program: /home/mrt/ffmpeg/v4l2/build/ffmpeg_g -threads 1 -v 55 -y -c:v
h264_v4l2m2m -i /home/mrt/bbb_1080_264.mp4 -an -frames:v 100 -f null -
...
Output file #0 (pipe:):
Output stream #0:0 (video): 100 frames encoded; 100 packets muxed (40000
bytes);
Total: 100 packets (40000 bytes) muxed
[h264_v4l2m2m @ 0x1403720] ff_v4l2m2m_codec_end leaving pending buffers
100 frames successfully decoded, 0 decoding errors
...
Thread 1 "ffmpeg_g" received signal SIGSEGV, Segmentation fault.
ff_v4l2_context_set_status (ctx=ctx@entry=0x10fc, cmd=1074026003) at
src/libavcodec/v4l2_context.c:489
489 int type = ctx->type;
(gdb) bt
#0 ff_v4l2_context_set_status (ctx=ctx@entry=0x10fc, cmd=1074026003) at
src/libavcodec/v4l2_context.c:489
#1 0x00798c24 in ff_v4l2_m2m_codec_end (avctx=0x1403720) at
src/libavcodec/v4l2_m2m.c:319
#2 0x00835aba in buffer_replace (src=0x0, dst=<optimized out>) at
src/libavutil/buffer.c:120
#3 av_buffer_unref (buf=buf@entry=0x14d8b2c) at src/libavutil/buffer.c:130
#4 0x008417ac in av_frame_unref (frame=frame@entry=0x14d8a30) at
src/libavutil/frame.c:515
#5 0x00841d58 in av_frame_unref (frame=<optimized out>) at
src/libavutil/frame.c:147
#6 av_frame_free (frame=frame@entry=0x1403d9c) at src/libavutil/frame.c:168
#7 0x00082bce in ffmpeg_cleanup (ret=0) at src/fftools/ffmpeg.c:541
#8 0x00079c42 in exit_program (ret=0) at src/fftools/cmdutils.c:138
#9 0x0006efba in main (argc=<optimized out>, argv=<optimized out>) at
src/fftools/ffmpeg.c:4793
(gdb) p ctx
$1 = (V4L2Context *) 0x10fc
(gdb) f 1
#1 0x00798c24 in ff_v4l2_m2m_codec_end (avctx=0x1403720) at
src/libavcodec/v4l2_m2m.c:319
319 ret = ff_v4l2_context_set_status(&s->output, VIDIOC_STREAMOFF);
(gdb) p s
$2 = (V4L2m2mContext *) 0x0
(gdb)
To clarify, it segfaults in the same way without the patch as well.
vow, very strange.
would you mind doing a clean build with the patch applied?
I am asking because that test works fine on my db410c and 820 (and hardware
shouldnt make a difference in this test)
also the team at Kodi also tested the fix on their imx6
- Mark
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
