On Sun, Jan 01, 2006 at 11:04:56AM -0500, Bobby Bingham wrote: > On Mon, 31 Dec 2007 17:51:48 +0100 > Vitor Sessak <[EMAIL PROTECTED]> wrote: > > > Hi > > > > Víctor Paesa wrote: > > > Hi, > > > > > > On Dec 31, 2007 12:03 PM, Vitor Sessak <[EMAIL PROTECTED]> wrote: > > >> Víctor Paesa wrote: > > >>> On Dec 31, 2007 9:04 AM, Vitor Sessak <[EMAIL PROTECTED]> 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
signature.asc
Description: Digital signature
_______________________________________________ FFmpeg-soc mailing list [email protected] http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
