| Message ID | 20210819085533.1174-3-ming.qian@nxp.com |
|---|---|
| State | New |
| Headers | show |
| Series | [FFmpeg-devel,v4,1/3] avcodec/v4l2_context: don't reinit output queue when dynamic resolution change | expand |
| Context | Check | Description |
|---|---|---|
| andriy/x86_make | success | Make finished |
| andriy/x86_make_fate | success | Make fate finished |
| andriy/PPC64_make | success | Make finished |
| andriy/PPC64_make_fate | success | Make fate finished |
On Thu, 19. Aug 16:55, Ming Qian wrote: > there are two proper ways to setup capture queue. > 1. client wait the source change event, > then setup the capture queue and streamon > 2. client setup the capture queue in advance, > but to avoid time issues, client should start > the capture queue before it enqueue the sequence > header to decoder driver through output queue. > and the sequence header is always in the first > frame, so client should start capture before > enqueue the first frame. > > ffmpeg use the method 2 to setup capture queue, > but currently ffmpeg enqueue the first frame > before starting the capture queue. > so in driver side, there are time issues. > when driver has parsed the resolution from sequence header, > but the client may not finished setup the capture. > so driver can't decide whether to notify a source change event to > client. and the following flow may be chaotic. > > And it's OK that client setup capture queue first, then enqueue the > first frame. > > Signed-off-by: Ming Qian <ming.qian@nxp.com> > --- > libavcodec/v4l2_m2m_dec.c | 18 ++++++++---------- > 1 file changed, 8 insertions(+), 10 deletions(-) > > diff --git a/libavcodec/v4l2_m2m_dec.c b/libavcodec/v4l2_m2m_dec.c > index 224eb3d5e7be..6b936b6df2a9 100644 > --- a/libavcodec/v4l2_m2m_dec.c > +++ b/libavcodec/v4l2_m2m_dec.c > @@ -149,6 +149,14 @@ static int v4l2_receive_frame(AVCodecContext *avctx, AVFrame *frame) > if (s->draining) > goto dequeue; > > + ret = v4l2_try_start(avctx); > + if (ret) { > + /* can't recover */ > + if (ret != AVERROR(ENOMEM)) > + ret = 0; > + goto fail; > + } > + > ret = ff_v4l2_context_enqueue_packet(output, &s->buf_pkt); > if (ret < 0 && ret != AVERROR(EAGAIN)) > goto fail; > @@ -157,16 +165,6 @@ static int v4l2_receive_frame(AVCodecContext *avctx, AVFrame *frame) > if (ret != AVERROR(EAGAIN)) > av_packet_unref(&s->buf_pkt); > > - if (!s->draining) { > - ret = v4l2_try_start(avctx); > - if (ret) { > - /* cant recover */ > - if (ret != AVERROR(ENOMEM)) > - ret = 0; > - goto fail; > - } > - } > - > dequeue: > return ff_v4l2_context_dequeue_frame(capture, frame, -1); > fail: Unfortunately this does not work on odroid xu4. It needs to parse the parameter sets before VIDIOC_G_FMT ioctl is called on the capture queue: https://github.com/hardkernel/linux/blob/odroid-5.4.y/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c#L317 Thanks,
diff --git a/libavcodec/v4l2_m2m_dec.c b/libavcodec/v4l2_m2m_dec.c index 224eb3d5e7be..6b936b6df2a9 100644 --- a/libavcodec/v4l2_m2m_dec.c +++ b/libavcodec/v4l2_m2m_dec.c @@ -149,6 +149,14 @@ static int v4l2_receive_frame(AVCodecContext *avctx, AVFrame *frame) if (s->draining) goto dequeue; + ret = v4l2_try_start(avctx); + if (ret) { + /* can't recover */ + if (ret != AVERROR(ENOMEM)) + ret = 0; + goto fail; + } + ret = ff_v4l2_context_enqueue_packet(output, &s->buf_pkt); if (ret < 0 && ret != AVERROR(EAGAIN)) goto fail; @@ -157,16 +165,6 @@ static int v4l2_receive_frame(AVCodecContext *avctx, AVFrame *frame) if (ret != AVERROR(EAGAIN)) av_packet_unref(&s->buf_pkt); - if (!s->draining) { - ret = v4l2_try_start(avctx); - if (ret) { - /* cant recover */ - if (ret != AVERROR(ENOMEM)) - ret = 0; - goto fail; - } - } - dequeue: return ff_v4l2_context_dequeue_frame(capture, frame, -1); fail:
there are two proper ways to setup capture queue. 1. client wait the source change event, then setup the capture queue and streamon 2. client setup the capture queue in advance, but to avoid time issues, client should start the capture queue before it enqueue the sequence header to decoder driver through output queue. and the sequence header is always in the first frame, so client should start capture before enqueue the first frame. ffmpeg use the method 2 to setup capture queue, but currently ffmpeg enqueue the first frame before starting the capture queue. so in driver side, there are time issues. when driver has parsed the resolution from sequence header, but the client may not finished setup the capture. so driver can't decide whether to notify a source change event to client. and the following flow may be chaotic. And it's OK that client setup capture queue first, then enqueue the first frame. Signed-off-by: Ming Qian <ming.qian@nxp.com> --- libavcodec/v4l2_m2m_dec.c | 18 ++++++++---------- 1 file changed, 8 insertions(+), 10 deletions(-)