On Mon, 13 Mar 2017 23:32:01 +0000 Mark Thompson <[email protected]> wrote:
> On 13/03/17 21:43, wm4 wrote: > > 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 mean the same value as it is now, in order to avoid changing behaviour. > > > 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. > > The defaults currently vary because some APIs are more frame-hungry than > others. (E.g. the qsv scaler allocates 32, the VAAPI ones allocate 10.) Does that mean a _consumer_ (like a downstream filter or an encoder) might use more frames? > > > 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. > > The extra is above what is needed for normal operation. Specifically, it is > the maximum number of output frames which can still be referenced by > following links / the user when a new filter operation is invoked. (If the > output frame is always freed before filter_frame is run again then it is > zero.) How do you define "normal operation"? If you say that some APIs are more frame-hungry, couldn't this be taken into account as an extra offset? > > 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? > > Yes, that is the best solution if someone wants to write the automagic > negotiation. I have honestly no idea how complex that would be with filter chains that are not just lists. _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
