[FFmpeg-devel] [RFC] libavfilter-soc and variable-frame-size video streams
Sat Dec 13 17:45:42 CET 2008
On date Saturday 2008-12-13 16:26:54 +0100, Stefano Sabatini encoded:
> On date Saturday 2008-12-13 14:23:40 +0100, Michael Niedermayer encoded:
> > On Fri, Dec 12, 2008 at 04:54:26PM -0800, Jason Garrett-Glaser wrote:
> > > > But maybe I'm just confused and there is a far simpler solution, or
> > > > maybe we could just decide that supporting variable-frame-size video
> > > > streams is not worth that hassle.
> > >
> > > This sounds reasonable to me: thinking through what every filter would
> > > have to do to support such a thing, it sounds completely
> > > unmaintainable, especially for filters that act temporally: how will
> > > they deal with the fact that cached temporal data from previous frames
> > > (such as for temporal denoisers) is no longer the correct size
> > > matching the current frame?!
> > >
> > > Avisynth gets away just fine without variable frame size support: I
> > > have actually never seen such a thing as a feature request either. I
> > > don't think libavfilter needs it either.
> > I think variable size is pretty much a requirement for libavfilter.
> > I dont remember exactly how/if this was discussed during lavfi development
> > but it surly is not ok to drop it. Also lack of support of it in Avisynth
> > is not an argument not to support it in lavfi.
> > About individual filters, variable size support is surely optional and
> > that way its no burden on a per filter level.
> > Filters that are "stateless" should be able to very easily support it,
> > the scale filter has to support it for the obvious reason to remove
> > size changes at the begin of a filter chain when that is wanted.
> > and temporal filters may or may not be able to easily support it, after
> > all they dont have to do much more than free their stuff and pretend its
> > the start of a stream.
> I'm thinking about something like avfilter_config_output_links(),
> which should work in a way very similar to avfilter_config_links, and
> maybe will share some code with it.
> It may work like this: when the request_frame callback of a filter
> recognize that the frame to output changed its size, it will call
> avfilter_config_output_links(), which will run all the config_props of
> the *input* pads of the following filters in the chain.
One problem with this is that when "forward" configuring all the
links, after the filter chain has been already set up, they are
already in an inited state.
I'm thinking about to implement a function which will "uninit" all the
links in the chain after a given filter
(avfilter_reset_output_links?), *then* call avfilter_config_links().
FFmpeg = Fiendish and Faboulous Maxi Problematic Eager Goblin
More information about the ffmpeg-devel