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

[Erik Kaashoek]

Jason Garrett-Glaser schreef:
> On Sun, Dec 14, 2008 at 2:51 AM, Erik Kaashoek <erik at kaashoek.com> wrote:
>   
>> 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?
>>     
>
> By that logic, libavfilter doesn't actually have to support variable
> frame size--it just means the filter chain has to be re-initted at a
> framesize change.
>
> Dark Shikari
>
>   
When a filter is before the scaling to the fixed output size it should 
reinitialize when a different frame size is input, when its after the 
scaler to the fixed output size it does not need reinitialization.
Is that possible?
Erik.