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

Fu, Linjie linjie.fu at intel.com
Tue Jan 15 03:36:52 EET 2019


> -----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)

Thanks for the comments.

- Linjie


More information about the ffmpeg-devel mailing list