On 12/1/17, Nicolas George <geo...@nsup.org> wrote:
> Paul B Mahol (2017-11-30):
>> +static int reset_links(AVFilterContext *filter)
>> +{
>> + int i, ret;
>> +
>> + if (!filter)
>> + return 0;
>> +
>> + for (i = 0; i < filter->nb_outputs; i++) {
>> + AVFilterLink *link = filter->outputs[i];
>> +
>> + link->init_state = AVLINK_UNINIT;
>> + link->frame_rate.num = link->frame_rate.den = 0;
>> + link->w = link->h = 0;
>> +
>> + ret = reset_links(link->dst);
>> + if (ret < 0)
>> + return ret;
>> + }
>> +
>> + if (!i)
>> + return avfilter_config_links(filter);
>> +
>> + return 0;
>> +}
>
> Sorry, but no. All filters are currently written with the assumption
> that config_props is called only once. Not all of them actually rely on
> this assumption, but some do, and expect the fields of the private
> context to be in their initial state. Violating that assumption would
> result in a lot of memory leaks and probably a few crashes, some of them
> security relevant.
Not all filters are written with such assumption. And I would like to fix those
who rely on this assumption.
>
> Plus, the public API of buffersink does not document params changes and
> does not provide a good way of reacting to it, so enabling params
> changes like that would have problematic results on applications that
> expect frames with all the same size.
Well for that point one can always autoinsert scale filter if user does
not set some flag when calling buffersink function.
>
> (By the way, I am quite worried to see that Michael weakened the
> protections for that last point in 5d859e59809.)
>
> Filters reconfiguration has been wanted for a lot of time. If it was
> that simple, it would have been done already. If you want to implement
> it, please go ahead, but it will not be an easy task.
I would like to proceed but I can't guess what is in your mind.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
