| Message ID | 20190114124037.13267-1-linjie.fu@intel.com |
|---|---|
| State | New |
| Headers | show |
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. > >
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
> -----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
> 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.
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; }
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(-)