[FFmpeg-devel] [PATCH 3/4] ffmpeg: with filter_complex, avoid random in<->out mapping.
michaelni at gmx.at
Mon Jun 4 03:36:52 CEST 2012
On Mon, Jun 04, 2012 at 12:01:11AM +0200, Nicolas George wrote:
> Le sextidi 6 prairial, an CCXX, Nicolas George a écrit :
> > I think it would be a bad idea: imagine something like that:
> > [24fps] [25fps] overlay [out]
> > The overlay filter is driven by its main input, so it will output 24 fps,
> > and the overlay will skip a frame and stutter once per second, which may be
> > acceptable. With your suggestion, the output will be selected at 25 fps, and
> > thus get another round and stutter with frame duplication.
> > > (one could also pick the largest timebase that allows all timestamps
> > > of all inputs with same type to be exactly represented, but iam not
> > > sure this is better with actual real world data)
> > With an input at 24 and an input at 25, it requires time base = 1/600 and
> > that is already too much for a container that only supports constant frame
> > rates.
> > I believe using the link time base, and letting the user set the frame rate
> > if necessary is the best option for now.
> Pushed 1 and 2 that were approved; 4 was superseded by a better patch you
> mushed in the meantime.
> As for 3, I still believe it is the better solution for now. And at the very
> least, the code it removes is clearly wrong.
well it breaks for example:
ffmpeg -i matrixbench_mpeg2.mpg -filter_complex null test.avi
timebase 1/90000 not supported by MPEG 4 standard, the maximum admitted value for the timebase denominator is 65535
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: Digital signature
More information about the ffmpeg-devel