[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