> 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? > 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? > 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. Cheers, Soren On Thu, Dec 29, 2011 at 8:36 AM, Luca Barbato <[email protected]> wrote: > On 29/12/11 15:10, Soren Dreijer wrote: >> >> Thanks, Luca. >> >> I need to write both audio and video, so I *have* to use interleaved >> frames, right? > > > Depends on your container. You might not want to use the default frame > interleaver in some cases. > > >> I was trying to read up on the pts value yesterday, but I'm a little >> unclear what to set it to. I have the time the packet was captured (in >> milliseconds) and the time of the first packet in the stream, but I'm >> not sure how that fits in with the AVStream->time_base units. If I'm >> capping at 25 FPS, do I simply calculate (from my own timestamps) >> which frame I'm passing the encoder? > > > 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. > > >> What if packets are dropped? Do I need to manually feed the encoder >> the previous frame for all the dropped frames, or does the encoder >> know how to handle this case if there's a gap in the pts value? > > > the encoder does not care about timing. It process frames as they go. > > > 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
