> -----Original Message-----
> From: libav-devel [mailto:[email protected]] On Behalf Of Mark
> Thompson
> Sent: Sunday, February 4, 2018 10:27 PM
> To: [email protected]
> Subject: Re: [libav-devel] [PATCH 08/12] vf_hwupload/hwmap: Support setting a
> fixed pool size
> 
> On 30/01/18 05:34, wm4 wrote:
> > On Mon, 29 Jan 2018 23:01:25 +0000
> > Mark Thompson <[email protected]> wrote:
> >
> >> These filters do not directly know whether the API they are using will
> >> support dynamic frame pools, so this is somewhat tricky.  If the user
> >> set extra_hw_frames, we assume that they are aware of the problem and
> >> set a fixed size based on that.  If not, most cases use dynamic sizing
> >> just like they did previously.  The hardware-reverse-mapping case for
> >> hwmap previously had a large fixed size (64) here, primarily as a hack
> >> for QSV use - this is removed and extra_hw_frames will need to be set
> >> for QSV to work since it requires fixed-size pools (as the other cases
> >> do, and which didn't work before).
> >> ---
> >>  libavfilter/vf_hwmap.c    | 7 ++++++-
> >>  libavfilter/vf_hwupload.c | 3 +++
> >>  2 files changed, 9 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/libavfilter/vf_hwmap.c b/libavfilter/vf_hwmap.c
> >> index b28cb2145..d5ad2768f 100644
> >> --- a/libavfilter/vf_hwmap.c
> >> +++ b/libavfilter/vf_hwmap.c
> >> @@ -138,7 +138,9 @@ static int hwmap_config_output(AVFilterLink *outlink)
> >>              frames->sw_format = hwfc->sw_format;
> >>              frames->width     = hwfc->width;
> >>              frames->height    = hwfc->height;
> >> -            frames->initial_pool_size = 64;
> >> +
> >> +            if (avctx->extra_hw_frames >= 0)
> >> +                frames->initial_pool_size = 2 + avctx->extra_hw_frames;
> >>
> >>              err = av_hwframe_ctx_init(ctx->hwframes_ref);
> >>              if (err < 0) {
> >> @@ -218,6 +220,9 @@ static int hwmap_config_output(AVFilterLink *outlink)
> >>          hwfc->width     = inlink->w;
> >>          hwfc->height    = inlink->h;
> >>
> >> +        if (avctx->extra_hw_frames >= 0)
> >> +            hwfc->initial_pool_size = 2 + avctx->extra_hw_frames;
> >> +
> >>          err = av_hwframe_ctx_init(ctx->hwframes_ref);
> >>          if (err < 0) {
> >>              av_log(avctx, AV_LOG_ERROR, "Failed to create frame "
> >> diff --git a/libavfilter/vf_hwupload.c b/libavfilter/vf_hwupload.c
> >> index 8cca9f42e..af4ff9b81 100644
> >> --- a/libavfilter/vf_hwupload.c
> >> +++ b/libavfilter/vf_hwupload.c
> >> @@ -133,6 +133,9 @@ static int hwupload_config_output(AVFilterLink
> *outlink)
> >>      ctx->hwframes->width     = inlink->w;
> >>      ctx->hwframes->height    = inlink->h;
> >>
> >> +    if (avctx->extra_hw_frames >= 0)
> >> +        ctx->hwframes->initial_pool_size = 2 + avctx->extra_hw_frames;
> >> +
> >>      err = av_hwframe_ctx_init(ctx->hwframes_ref);
> >>      if (err < 0)
> >>          goto fail;
> >
> > Should we have a hwcontext flag that informs the API user whether the
> > frame pools require a fixed size?
> 
> That would work for users, but I think you still need something for the 
> default
> value in this particular case.
> 
> Suppose the hwcontext definition also included a suggested default pool size -
> that would allow libmfx to have a suggested size of 9001 for hwupload to work
> with qsvenc while others can set more sensible values?
I think before we figure out a more smart way to handle the buffer pool size,
it sounds a practical way to allow different targets to set different suggested 
value.
But I am not sure if there will be objection from the community.

I am also thinking about implementing on-demand buffer allocation for qsv.
Is there anybody else ever think it over? Does is sound possible?

Ruiling
> 
> - Mark
> _______________________________________________
> libav-devel mailing list
> [email protected]
> https://lists.libav.org/mailman/listinfo/libav-devel
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to