On 01/02/16 16:14, wm4 wrote:
> On Sat, 30 Jan 2016 22:15:04 +0000
> Mark Thompson <s...@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
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
