[FFmpeg-devel] [RFC] libavfilter-soc and variable-frame-size video streams

[Michael Niedermayer]

On Sun, Dec 14, 2008 at 12:48:14AM +0100, Stefano Sabatini wrote:
> On date Saturday 2008-12-13 17:45:42 +0100, Stefano Sabatini encoded:
> > 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.
> 
> In attachment some sketches developing this idea.
> 

> Now my problem is that the config_props of the scale filter will fail
> when called the first time during configuration in the case the input
> filter set values of w and h to 0 in the input link, which happens in
> the already mentioned case (VP6), and the scaler cannot be initialized
> with meaningful values.

what exactly are you doing?
by the time the filter layer is initialized some width&height should be
available. I mean av_find_stream_info() will not return before this is
available.

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

I count him braver who overcomes his desires than him who conquers his
enemies for the hardest victory is over self. -- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20081214/11c1e804/attachment.pgp>