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

[Bobby Bingham]

On Mon, 31 Dec 2007 17:51:48 +0100
Vitor Sessak <vitor1001 at gmail.com> wrote:

> Hi
> 
> Víctor Paesa wrote:
> > Hi,
> > 
> > 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...

> 
> -Vitor

-- 
Bobby Bingham
Never trust atoms.  Or anything made of atoms.
このメールは再利用されたバイトでできている。