[FFmpeg-soc] libavfilter: fps ignored in ffmpeg command line
vitor1001 at gmail.com
Mon Dec 31 18:46:01 CET 2007
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:
>>>>>>> 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...
More information about the FFmpeg-soc