[FFmpeg-devel] [PATCH] avfilter/vf_stereo3d: implement auto detection by using frame side data

[Paul B Mahol]

On 12/1/17, wm4 <nfxjfg at googlemail.com> wrote:
> On Fri, 1 Dec 2017 18:02:52 +0100
> Michael Niedermayer <michael at niedermayer.cc> wrote:
>
>> On Fri, Dec 01, 2017 at 10:01:42AM +0100, Nicolas George 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.
>> >
>> > 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.
>> >
>> > (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.
>>
>> As the one who tried implementing changing frame parameters like
>> dimension long time ago, the only real problem i encountered was
>> bikeshedding, i dont rememer a technical problem. The bikeshedding in
>> fact resolved itself but by the time i had lost interrest ...
>>
>> And in fact many filters should just be able to handle changing frame
>> parameters as they are or with minimal changes.
>
> Well, the result is that at least the vf_scale filter appears to
> blatantly violate the API and crashes my software.

How?

The current "support" works only with some filters and when input itself
have parameter changes, using other filters in same filtergraph will just
crash.