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

[Stefano Sabatini]

On date Friday 2008-12-12 16:54:26 -0800, Jason Garrett-Glaser encoded:
> > 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.

My only problem with this is that this way we cannot support video
stream such as VP6, where the size is detected just when we parse the
first decoded frame:
http://thread.gmane.org/20080830132832.GA6663 at geppetto

And when this feature is too difficult to implement in some particular
filter (e.g. temporal filters with a buffer), we could simply break
the processing.

I'm thinking about some mechanism for which an input filter may detect
that the input size changed, and notify the output filter of that.

Let's consider this simple scenario (ffplay with scale filter):

input --(0, 0)--> scale --(0, 0)--> output

The output filter calls the request_frame callback on the output scale
pad, which will call the request_frame callback on the input filter
output pad.

At this point the input filter should be able to recognise that the
frame w/h has changed, and change accordingly the w/h in the link,
*and* make the scale filter reset its internal state, this before to
call the start_frame callback (or maybe in the start_frame itself). So
we'll end up with this situation:

input --(w, h)--> scale --(0, 0)--> output

Then the same will happen before the start_frame of the output is
called.

During the resetting stage some filter may fail to reset itself, in
this case it should notify somehow to the output filter of this, for
example passing a null picture to the output.

It is still very confused, but maybe something similar to what I
described may work (if still we want to support such thing).

Regards.
-- 
FFmpeg = Forgiving and Freak Murdering Proud Embarassing Guru