> > 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
