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

Stefano Sabatini stefano.sabatini-lala
Sun Dec 14 00:48:14 CET 2008


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.

A possible solution could be to posticipate the initialization of the
scaler when the first decoded frame arrives, in the start_frame callback,
but then I'm not sure which is the correct behaviour to implement if I
cannot initialize the scaler, as the start_frame/draw_slice/end_frame
callbacks don't seem to be supposed to fail.

So I wonder if we need to extend the API (for example making the
start_frame/draw_slice/end_frame callbacks able to signal a processing
failure), or if there is some other way to manage this scenario with
the current API which I can't see.

[...]

Regards.
-- 
FFmpeg = Friendly & Foolish Magical Philosofic Epic Guru
-------------- next part --------------
A non-text attachment was scrubbed...
Name: implement-avfilter-reconfig-output-links.patch
Type: text/x-diff
Size: 2198 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20081214/b36e7639/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ffplay-rescale.patch
Type: text/x-diff
Size: 1543 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20081214/b36e7639/attachment-0001.patch>



More information about the ffmpeg-devel mailing list