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

Submitted by Linjie Fu on Jan. 14, 2019, 12:40 p.m.

Details

Message ID 20190114124037.13267-1-linjie.fu@intel.com
State New
Headers show

Commit Message

Linjie Fu Jan. 14, 2019, 12:40 p.m.
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@intel.com>
---
 libavfilter/qsvvpp.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

Comments

Rostislav Pehlivanov Jan. 14, 2019, 4:48 p.m.
On Mon, 14 Jan 2019 at 12:40, Linjie Fu <linjie.fu@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@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.

>
>
Maxym Dmytrychenko Jan. 14, 2019, 7:12 p.m.
On Mon, Jan 14, 2019 at 5:53 PM Rostislav Pehlivanov <atomnuker@gmail.com>
wrote:

> On Mon, 14 Jan 2019 at 12:40, Linjie Fu <linjie.fu@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@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



> >
> >
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


regards
Maxym Dm
Linjie Fu Jan. 15, 2019, 1:36 a.m.
> -----Original Message-----

> From: ffmpeg-devel [mailto:ffmpeg-devel-bounces@ffmpeg.org] On Behalf

> Of Maxym Dmytrychenko

> Sent: Tuesday, January 15, 2019 03:12

> To: FFmpeg development discussions and patches <ffmpeg-

> devel@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@gmail.com>

> wrote:

> 

> > On Mon, 14 Jan 2019 at 12:40, Linjie Fu <linjie.fu@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@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
Zhong Li Jan. 15, 2019, 4:57 a.m.
> From: ffmpeg-devel [mailto:ffmpeg-devel-bounces@ffmpeg.org] On Behalf

> Of Fu, Linjie

> Sent: Tuesday, January 15, 2019 9:37 AM

> To: FFmpeg development discussions and patches

> <ffmpeg-devel@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@ffmpeg.org] On

> Behalf

> > Of Maxym Dmytrychenko

> > Sent: Tuesday, January 15, 2019 03:12

> > To: FFmpeg development discussions and patches <ffmpeg-

> > devel@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@gmail.com>

> > wrote:

> >

> > > On Mon, 14 Jan 2019 at 12:40, Linjie Fu <linjie.fu@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@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.

Patch hide | download patch | download mbox

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;
         }