On Fri, Dec 01, 2017 at 06:10:02PM +0100, wm4 wrote:
> On Fri, 1 Dec 2017 18:02:52 +0100
> Michael Niedermayer <mich...@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
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
