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.) > 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.) > 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. _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
