On Tue, Jun 23, 2009 at 5:20 PM, Erik Van Grunderbeeck <[email protected]>wrote:
> > > > What is important though is that you sync on the audio _that is playing_ > > (eg > > coming out of the speakers). The audio boards usually have hardware > buffers > > and may buffer up to a few seconds. I solve this by encoding a timestamp > in > > my buffers, that is read when the buffer is free'ed right after its > played. > > > > Users are less prone to noticing the occasional double frame. They will > > however immediately hear a click, or a "NULL" sound. > > > >Hey, thanks for the answer. > Your welcome > > >The one thing that's still not clear is this: > >"Ege if you are currently playing audio samples of time x, and check the > pts > >of the other > >streams and either drop frames, or insert a duplicate." > > >How do you calculate what the the current time X is. Is it simply the > >packet's pts? Or do I need to offset the packets pts by the start_time of > >the stream (and where does the containers start_time come into account). > I'm > >aware of converting between timebases, so I'm just wondering if there is > >some sort of offsets I need to apply to the pts to get the 'true' pts > (when > >the streams have different start_times). > > > Rule of the thumb: ignore any timebases from containers. In theory, it > should work well, in practice there are so many bad encoders out there that > set this to an either random, incorrect, or whatever they feel like > picking, > that it just does not work. Remember also that (depending on what you are > decoding) some video files don't have a "true" container. Example most > transport streams (since they need to be picked up on the fly, they contain > all needed information in the audio/video streams itself or some control > stream). > > The FF libs go through great length (from what I have seen) to generate > reasonable timestamps in the pts of the packets. Start any timebase from > that. > > You can offset the timestamps to one 0 base (ege substract the smallest > ones > from the biggest one), but it really doesn't matter. Remember, your running > on your clock. And FFlibs remove common factors. > > Work of the pts. As said, generate a master clock. Run your display and > audio of that. From my experience, the audio clock pts works well as a > master clock. > > Also from experience, keep the timestamp stuff as simple as possible. Leave > it to the de-muxers and the codecs to come up with the correct pts. > > Not sure if this answers. Feel free to ask more, if I can help surely will > (or correct any stupid stuff I said ;) ) > > Erik > > _______________________________________________ > libav-user mailing list > [email protected] > https://lists.mplayerhq.hu/mailman/listinfo/libav-user > Thanks again. Just to make sure I'm clear can we run through an example? So I have file with audio and video. The audio stream has a start time of 56994 The video stream has a start time of 64194 Both have a time base of 1/90000 The first audio packet I get has a pts of 56994 The first video packet I get has a pts of 64194 The next video packets have a pts of: (coming out in this order) 56994 60594 74994 67794 71394 I get a frame on the 2nd call to avcodec_decode_video2() (i.e on the packet with a pts of 56994). So given this, should I be playing the first set of decoded audio at the same time that I show the first decoded frame? or is there some delay I need to add to one of the output streams. The fact that my lowest pts for video is 56994, but the start_time is 64194 is a little confusing to me, just I'm just trying to understand the offsets here. Malcolm _______________________________________________ libav-user mailing list [email protected] https://lists.mplayerhq.hu/mailman/listinfo/libav-user
