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

[Michael Niedermayer]

On Fri, Dec 01, 2017 at 06:10:02PM +0100, wm4 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.

This sounds unlikely but
Which ticket on trac is that ?
And what part of which API do you speak about ?

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20171201/b0a14fad/attachment.sig>