On Mon, 13 Mar 2017 16:59:29 +0000
Mark Thompson <[email protected]> wrote:
> On 13/03/17 16:50, Mark Thompson wrote:
> > ---
> > + version bump
> >
> >
> > doc/APIchanges | 3 +++
> > libavfilter/avfilter.c | 2 ++
> > libavfilter/avfilter.h | 13 +++++++++++++
> > 3 files changed, 18 insertions(+)
> >
> > diff --git a/doc/APIchanges b/doc/APIchanges
> > index 835b39bea..abe94640a 100644
> > --- a/doc/APIchanges
> > +++ b/doc/APIchanges
> > @@ -13,6 +13,9 @@ libavutil: 2015-08-28
> >
> > API changes, most recent first:
> >
> > +2017-03-xx - xxxxxxx - lavfi 6.xx.0 - avfilter.h
> > + Add AVFilterContext.extra_hw_frames.
> > +
> > 2017-03-xx - xxxxxxx - lavc 57.xx.0 - avcodec.h
> > Add AVCodecContext.extra_hw_frames.
> >
> > diff --git a/libavfilter/avfilter.c b/libavfilter/avfilter.c
> > index 99531e569..d149e761a 100644
> > --- a/libavfilter/avfilter.c
> > +++ b/libavfilter/avfilter.c
> > @@ -382,6 +382,8 @@ static const AVOption avfilter_options[] = {
> > { "thread_type", "Allowed thread types", OFFSET(thread_type),
> > AV_OPT_TYPE_FLAGS,
> > { .i64 = AVFILTER_THREAD_SLICE }, 0, INT_MAX, FLAGS, "thread_type"
> > },
> > { "slice", NULL, 0, AV_OPT_TYPE_CONST, { .i64 =
> > AVFILTER_THREAD_SLICE }, .unit = "thread_type" },
> > + { "extra_hw_frames", "Number of extra hardware frames to allocate for
> > the user",
> > + OFFSET(extra_hw_frames), AV_OPT_TYPE_INT, { .i64 = 0 }, 0,
> > INT_MAX, FLAGS },
>
> Maybe the default value would be better as a detectable one like -1 or
> INT_MIN? Then the filters which currently have a higher default could used
> their original values in that case, and users wouldn't need to add this
> option in some cases which currently work.
Not sure if I follow. Which original value?
I think there are two cases:
- hw APIs which don't need this, because frames can be allocated
dynamically
- hw APIs which actually need this, because everything is preallocated
In the former case, it should not allocate any extra frames, but simply
allocate as needed. In the latter case, you'd probably have a somewhat
arbitrary default, so it doesn't blow up in the user's face on the
first try. The default would probably be the same for all APIs which
need it? But later, it could use a value based on some sort of
automatic negotiation between the filters.
I'd say you need at least 1 extra frame to produce output by definition
(i.e. it's not really "extra"). So a value 0 doesn't make sense, and
it's suitable as dummy value for whatever default or automagic thing
there is.
Maybe once we figure out whether automagic negotiation works, we'll
add a similar field to buffer src/sink, and nobody would ever touch the
field this patch adds again?
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
