On Wed, 08 Mar 2017 14:14:25 -0500 Calvin Walton <calvin.wal...@kepstin.ca> wrote:
> On Wed, 2017-03-08 at 19:27 +0100, Nicolas George wrote: > > L'octidi 18 ventôse, an CCXXV, Calvin Walton a écrit : > > > > > > If a later input is higher framerate, this results in dropped frames; if > > > a later input is lower framerate it might cause judder. > > > > > > The simplest fix is to just set the out links to have '1/0' as the frame > > > rate, the value meaning "unknown/vfr". Note that this changes the > > > > I do not think that setting it to 1/0 is the correct fix for this issue. > > Unless I am mistaken, the frame rate is available on all inputs when the > > corresponding code is called: I think the correct fix would be to check > > if all inputs have the same. > > Hmm. Setting it to the same as the input value if all inputs match > shouldn't be too hard, I think. > > In the actual case of inputs with different frame rates, would it be > better to use the '1/0' value, or should it attempt to calculate a > common framerate that's a multiple of all inputs? (e.g. for 24fps and > 30fps inputs, it could pick 120fps). > > There's already a TODO listed in the filter code about determining a > common timebase rather than using AV_TIME_BASE - if I'm doing the work > to find a common framerate, I could probably do this at the same time. I really think if there's no common framerate, it should not pretend there is one. Thus setting 1/0 doesn't seem too bad. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel