[MPlayer-dev-eng] mplayer/mencoder audio pts support

John Koleszar jkoleszar at on2.com
Fri Mar 3 16:45:28 CET 2006


Hi all,

Continuing along the lines of Corey's dwStart support, I think this 
issue has broader scope on the decode side of things. I've yet to find a 
way to handle files that have these kind of delayed streams in pts based 
containers (asf in my case, will probably be an issue with nut too). 
I've played with the autosync stuff, and I've hacked around with some of 
the audio delay code similar to the dwStart support, and I can't get the 
behavior I expect. My guess is that it's not really a sync issue (ie, 
hypothetical metric audio_samples/frame is correct & constant) just the 
streams are played offset by a constant amount. Overspeeding the video 
isn't an acceptable way to make up this large of an offset. The dwStart 
behavior seemed like the right route to go, but I couldn't make it work. 
Maybe I just had the semantics wrong, so if that should do what I want, 
please say so.

Specifically, the first video packet in my file has a pts of 5s and the 
first audio packet has a pts of 9s. The proper behavior for this file 
would be to start the video immediately, and then start the audio after 
4 seconds. Yes, I know this is a contrived example, and it's obviously 
not common (at least with delays on this order of magnitude) in the 
wild. Best real world use case I can imagine is short voice-overs with 
long periods of silence in between.

However contrived this example is, I want it to play properly, and am 
willing to put the work in to fix it. I wanted to get some discussion 
going on this list to make sure I fix it correctly. Can pts be relied 
upon to be valid from all demuxers? Or is pts not the way to go? 
Comments/caveats/suggestions accepted...

Thanks..

John




More information about the MPlayer-dev-eng mailing list