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

Michael Niedermayer michaelni at gmx.at
Mon Dec 31 20:14:36 CET 2007


On Sun, Jan 01, 2006 at 11:04:56AM -0500, Bobby Bingham wrote:
> 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?

which of the many frame rate fields do you mean? :)

AVStream.time_base will always be something in which all timestamps can be
repressented accurately

AVStream.r_frame_rate is just a guess and will generally only take the
first few frames into account. (But a demuxer could override this if it
has more reliable information), though its important to keep in mind that
this is not a average frame rate but rather the least common multiple of
all framerates

AVCodecContext.time_base is the equivalent of AVStream.time_base, just this
time for the decoder instead of the demuxer


> 
> Do (some subset of) the muxers support variable framerate outputs?  This
> would make variable framerate outputs impossible...

no muxer allows changing the time_base, and most will be happy with arbitrary
holes in the timestamps, that is they generally dont require 1,2,3,4,5 but
will happily work with 1,5000,80000,100000,110000,123456 as timestamps
though some like avi will be somewhat inefficient with 1000fps and large
holes ...

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-soc/attachments/20071231/52d807c5/attachment.pgp>


More information about the FFmpeg-soc mailing list