[FFmpeg-soc] libavfilter: fps ignored in ffmpeg command line

[Vitor Sessak]

Hi

Bobby Bingham wrote:
> On Mon, 31 Dec 2007 17:51:48 +0100
> Vitor Sessak <vitor1001 at gmail.com> wrote:
>> Víctor Paesa wrote:
>>> On Dec 31, 2007 12:03 PM, Vitor Sessak <vitor1001 at gmail.com> wrote:
>>>> Víctor Paesa wrote:
>>>>> On Dec 31, 2007 9:04 AM, Vitor Sessak <vitor1001 at gmail.com> wrote:
>>>>>> Víctor Paesa wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> The filter fps seems ignored in the ffmpeg command line.
>> [...]
>>
>>>> If you do
>>>>
>>>> ffmpeg -i input.avi -vfilters fps=1 output.avi
>>>>
>>>> where input.avi has a rate of 25 fps, you'll have
>>>>
>>>> Input -> 25 fps
>>>> Filtered input -> 1 fps
>>>> Output -> 25 fps
>>>>
>>>> The only problem is that the output rate (set in ffmpeg.c) is
>>>> equal by default to the unfiltered input rate. The filter does its
>>>> job, but I agree it would be more reasonable to set the default
>>>> output rate to the filtered input rate. That would unfortunately
>>>> have a small problem: imagine for example overlaying a 20 fps and
>>>> a 30 fps movie together. The filter output will not have a fixed
>>>> frame rate, so creating and setting a frame_rate field in the
>>>> AVFilterLink structure will not make a lot of sense. A second
>>>> problem would be to allow broken filters to set frame_rate to a
>>>> value not coherent with the interval between timestamps.
>>> Yeah, I was thinking of patching vf_overlay.c as attached:
>> I think that maintaining a constant frame rate could be handled by
>> the filter framework instead of having to be handled by each filter.
>>
>> I've thought a bit more about the subject and have the following idea:
>>
>> 1- add a field named suggested_rate to AVFilterLink that would be the 
>> suggested frame rate of the output.
>> 2- initialize this field by default by the input frame rate.
>> 3- vf_fps will set it to its nominal value and vf_overlay will set it 
>> either as the highest one, the image rate or the subimage rate
>> 4- in ffmpeg.c, the vf_fps filter will _always_ be inserted in the
>> end of the filter chain (it's fast). It'll be given either the
>> framerate specified by the -r command line parameter or if none
>> specified by the value of suggested_rate in the end of the chain.
>>
>> What do you think?
> 
> What happens for variable framerate inputs?  What framerates do the
> demuxers report for such files?
> 
> Do (some subset of) the muxers support variable framerate outputs?  This
> would make variable framerate outputs impossible...

This is easy to fix. Just skip step 4 (automaticaly adding vf_fps to the 
filter chain) if the muxer supports variable framerate...

-Vitor