[FFmpeg-devel] [PATCH 2/2] lavf/qsvvpp: cope with MFX_ERR_MORE_DATA condition in VPP pipeline

[Li, Zhong]

> From: ffmpeg-devel [mailto:ffmpeg-devel-bounces at ffmpeg.org] On Behalf
> Of Fu, Linjie
> Sent: Tuesday, January 15, 2019 9:37 AM
> To: FFmpeg development discussions and patches
> <ffmpeg-devel at ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 2/2] lavf/qsvvpp: cope with
> MFX_ERR_MORE_DATA condition in VPP pipeline
> 
> > -----Original Message-----
> > From: ffmpeg-devel [mailto:ffmpeg-devel-bounces at ffmpeg.org] On
> Behalf
> > Of Maxym Dmytrychenko
> > Sent: Tuesday, January 15, 2019 03:12
> > To: FFmpeg development discussions and patches <ffmpeg-
> > devel at ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] [PATCH 2/2] lavf/qsvvpp: cope with
> > MFX_ERR_MORE_DATA condition in VPP pipeline
> >
> > On Mon, Jan 14, 2019 at 5:53 PM Rostislav Pehlivanov
> > <atomnuker at gmail.com>
> > wrote:
> >
> > > On Mon, 14 Jan 2019 at 12:40, Linjie Fu <linjie.fu at intel.com> wrote:
> > >
> > > > Returning AVERROR(EAGAIN) when libmfx needs more data will cause
> > the
> > > > failure
> > > > of requesting the next frame and lead to an infinite loop.
> > > >
> > > > Sleep for a while to release the resources before calling
> > > > MFXVideoCORE_SyncOperation in hwupload to avoid the crash (in
> MCTF
> > > > for example).
> > > >
> > > > Signed-off-by: Linjie Fu <linjie.fu at intel.com>
> > > > ---
> > > >  libavfilter/qsvvpp.c | 6 ++++--
> > > >  1 file changed, 4 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/libavfilter/qsvvpp.c b/libavfilter/qsvvpp.c index
> > > > 06efdf5089..1a10d16788 100644
> > > > --- a/libavfilter/qsvvpp.c
> > > > +++ b/libavfilter/qsvvpp.c
> > > > @@ -714,8 +714,10 @@ int ff_qsvvpp_filter_frame(QSVVPPContext
> *s,
> > > > AVFilterLink *inlink, AVFrame *picr
> > > >
> > > >          if (ret < 0 && ret != MFX_ERR_MORE_SURFACE) {
> > > >              /* Ignore more_data error */
> > > > -            if (ret == MFX_ERR_MORE_DATA)
> > > > -                ret = AVERROR(EAGAIN);
> > > > +            if (ret == MFX_ERR_MORE_DATA) {
> > > > +                ret = MFX_ERR_NONE;
> > > > +                av_usleep(100000);
> > > > +            }
> > > >              break;
> > > >          }
> > > >
> > > > --
> > > > 2.17.1
> > > >
> > >
> > > This seems like its an ugly hack.
> > >
> > >
> >
> > totally agree here, it should not be time dependent
> >
> I agree it's hacked and it's a work around method for discussion.
> 
> The ideal way in FFmpeg level is to check the hardware status before calling
> MFXVideoCORE_SyncOperation() rather than setting a hardcode sleep time
> to wait for its release.
> 
> Another possible method may be in the driver level. (deinterlace needs
> reference frames too like MCTF does, but it doesn't report More Data)

Please file a bug to driver instead of hack here.