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

Erik Kaashoek erik
Sun Dec 14 11:51:44 CET 2008

Aurelien Jacobs schreef:
> On Sat, 13 Dec 2008 12:45:21 +0100
> Stefano Sabatini <stefano.sabatini-lala at poste.it> wrote:
>> 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
> If this really helps avfilter, I can modify the VP6 decoder so that
> it don't zero out the container width/height before decoding first
> frame. But that won't change the fact that width/height can change
> later.
>> 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.
> Without knowing libavfilter very well, I can imagine a simple
> solution to resolution change.
> Every filter should have a flag to declare wether it supports resolution
> change or not. Then when a resolution change happens, the whole filter
> chain is inspected. As soon as a filter which don't support resolution
> change is detected, a scale filter is automatically inserted before
> it. Some people may not like automagic stuff, so this feature could be
> optionnal, and when not enabled, automatic insertion of the scale
> filter would be replaced by a hard failure.
> Aurel
What is conceptually the difference between the very first valid frame received at a temporal filter and the first frame received at a temporal filter after a resolution change?

Both can not be filtered against a relevant history of frames.

More information about the ffmpeg-devel mailing list