> fps information on a non-constant frame rate stream is a bit misleading... > > Yet, you have a time_base in the stream description.
Right :) I guess what I'm trying to say is that I might capture a frame anywhere in those 40 ms between each frame rather than right on the 1/25 mark. I don't know if it even matters that much, or if I should simply consider a frame captured at e.g. 45 ms to be frame 2. I feel like what I've encoded so far looks a little jerky though, so I'm wondering if it matters. > All depends on the container format =) I'm calling av_guess_format() with ".avi". / Soren On Thu, Dec 29, 2011 at 10:43 AM, Luca Barbato <[email protected]> wrote: > On 29/12/11 17:22, Soren Dreijer wrote: >> >> Thanks for the quick replies, Luca! >> >>>> So, rather than setting the timebase to 1/<fps> as e.g. >>>> output-example.c does, I'd simply set it to 1/1000 if my incoming >>>> timestamps are in milliseconds? Let's say I capture my first frame a 0 >>>> ms and the second frame a 45 ms. Should I then set the frames' pts to >>>> 0 and 45, respectively in the AVPacket? >>> >>> >>> should work. >> >> >> Where do I set pts timebase? If I change the AVCodecContext::time_base >> from 1/25 to 1/1000, the resulting FPS of the video is 1000, which >> isn't what I want. I still want 25 FPS, but I'd like to have more >> granularity when specifying each frame's pts. > > > fps information on a non-constant frame rate stream is a bit misleading... > > Yet, you have a time_base in the stream description. > > >>> The encoder does not care about pts, the muxer will and depending on it >>> you >>> might have to use such tricks. >> >> >> That's where I get confused because I just call >> av_interleaved_write_frame() with the AVPacket with the correct pts >> and the muxer is "hidden" from me (as far as I know?). It sounds like >> I shouldn't rely on the muxer to be clever enough to handle dropped >> frames then? > > > All depends on the container format =) > > > lu > > -- > > Luca Barbato > Gentoo/linux > http://dev.gentoo.org/~lu_zero > > _______________________________________________ > libav-api mailing list > [email protected] > https://lists.libav.org/mailman/listinfo/libav-api _______________________________________________ libav-api mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-api
