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. > 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? On Thu, Dec 29, 2011 at 10:04 AM, Luca Barbato <[email protected]> wrote: > On 29/12/11 15:57, Soren Dreijer wrote: >>> >>> Depends on your container. You might not want to use the default frame >>> interleaver in some cases. >> >> >> I'm currently using the MJPEG codec and plan on just doing raw PCM. >> Will the default interleaver be good enough, you think? > > > Those are codecs, not container formats. > > >>> you decide the timebase and put the time reference in timebase units, >>> that >>> means that if the timebase is 1/1000 s and your frame is around 1/25 s, >>> your >>> pts would be about 40 timebase unit apart each other. >> >> >> 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. > > >>> the encoder does not care about timing. It process frames as they go. >> >> >> Since I'm capturing the frames live, the source might have a hiccup >> and I might skip a frame (or several). Since the encoder only cares >> about the frames I tell it, I need to be able to tell it that there >> was a gap somewhere. I was planning on doing that by just feeding it >> the previous frame for the number of frames I knew I dropped, but I'm >> curious if the encoder does that automatically if it notices a gap in >> the pts. > > > The encoder does not care about pts, the muxer will and depending on it you > might have to use such tricks. > > > 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
