Re: [FFmpeg-devel] [PATCH 2/2] lavf/qsvvpp: cope with MFX_ERR_MORE_DATA condition in VPP pipeline
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Fu, Linjie
> Sent: Tuesday, January 15, 2019 9:37 AM
> To: FFmpeg development discussions and patches
>
> 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-boun...@ffmpeg.org] On
> Behalf
> > Of Maxym Dmytrychenko
> > Sent: Tuesday, January 15, 2019 03:12
> > To: FFmpeg development discussions and patches > de...@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
> >
> > wrote:
> >
> > > On Mon, 14 Jan 2019 at 12:40, Linjie Fu 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
> > > > ---
> > > > 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(10);
> > > > +}
> > > > 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.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
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-boun...@ffmpeg.org] On Behalf
> Of Maxym Dmytrychenko
> Sent: Tuesday, January 15, 2019 03:12
> To: FFmpeg development discussions and patches de...@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
>
> wrote:
>
> > On Mon, 14 Jan 2019 at 12:40, Linjie Fu 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
> > > ---
> > > 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(10);
> > > +}
> > > 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
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
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
wrote:
> On Mon, 14 Jan 2019 at 12:40, Linjie Fu 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
> > ---
> > 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(10);
> > +}
> > 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
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] lavf/qsvvpp: cope with MFX_ERR_MORE_DATA condition in VPP pipeline
On Mon, 14 Jan 2019 at 12:40, Linjie Fu 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
> ---
> 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(10);
> +}
> break;
> }
>
> --
> 2.17.1
>
This seems like its an ugly hack.
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
