[FFmpeg-devel] [PATCH v5 5/5] libavfilter: VAAPI surface scaler

Mark Thompson sw at jkqxz.net
Tue Feb 2 21:26:17 CET 2016


On 01/02/16 16:14, wm4 wrote:
> On Sat, 30 Jan 2016 22:15:04 +0000
> Mark Thompson <sw at jkqxz.net> wrote:
>> +    { "hardware_context", "VAAPI hardware context",
>> +      OFFSET(hardware_context), AV_OPT_TYPE_INT64,
>> +      { .i64 = 0 }, INT64_MIN, INT64_MAX, AV_OPT_FLAG_VIDEO_PARAM },
> 
> Most of it is probably ok. But before it gets ready to be applied, I
> think we should find a semi-elegant way to populate the filter graph
> with the hw context. The "hardware_context" option is just a void*
> pointer, and there isn't anything that would prevent a big mess if e.g.
> vaapi support is introduced later.
> 
> Seems like the Libav patch does provide something of value here with
> its generic hw context. It could be a field in AVFilterGraph itself.

Yeah, the libav patch does let you solve that problem by putting the information generically in more places.

My rather inelegant thought was to add another function (and associated fields) on the filter graph which applies options to all filters if the option is present for them, something like:

int avfilter_graph_set_options_on_everything(AVFilterGraph *graph, AVDictionary **options);

(Run before adding anything to the graph, because the options need to be present at filter init time.)  Unclear if it has any other use to justify its existence, though.  Also necessitates making the naming a bit more specific to avoid possible collisions ("vaapi_hardware_context", I guess), and then being careful with it in future.

The other way I can see to do it in ffmpeg is to know the set of filter names and run through the whole graph to add the option to them, but there isn't really a time which works to do it.  In any case, it doesn't help lav* users.

- Mark



More information about the ffmpeg-devel mailing list