On May 21, 2013, at 20:35 , Brad O'Hearne wrote: > On May 21, 2013, at 12:12 AM, Robert Krüger <[email protected]> wrote: >> are you talking about using the ffmpeg as a command line application? > > No, using libraries programmatically in an app. > >> you elaborate what exactly you mean by "but FFmpeg must have fixed >> frame rate"? > > In my testing, you have to feed the encoder the exact number of FPS set in > time_base.den. You cannot give the encoder some lesser or greater FPS and > think that accommodating this by setting pts will fix the timing.
I disagree (again). If your player synchronizes audio and video using dts/pts, and as far as I know most do, you can indeed create the weirdest frame rate changes by manipulating dts/pts. > Playback is going to process time_base.den frames per second, so if you give > it fewer FPS than time_base.den, then your video is going to play back faster > than intended, and if you give it greater FPS than time_base.den, then your > video is going to play back slower than intended. Which "Playback" , which player ? Every player can have it's own playback logic, nevertheless I don't see where the player logic would require fps to be fixed (unless it ignores dts/pts). time_base might play a role in the formulas used by the player, so it makes sense to match the dts/pts manipulations to the timebase used. If players base the playback on fps, they will run out of sync sooner or later. That's why we have dts/pts. > > The upshot is that you are pinned to a fixed frame rate while encoding. If > your source data provides are a variable frame rate, then you have some work > to do to feed a fixed frame rate to the encoder. Again i disagree. Just set DTS/PTS accordingly, to compensate for the different fps rate. Been there, done that. Works. _______________________________________________ Libav-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/libav-user
