[MPlayer-G2-dev] Recommendations for DEMUXER layer

D Richard Felker III dalias at aerifal.cx
Sat Dec 20 09:34:34 CET 2003


I've been reading some demuxer code to figure out how pts is computed
for various demuxers, in order to understand how it needs to be
handled by the new video (and eventually new audio!) layer. In the
process, I've come up with a few recommendations for changes.

1. Some demuxers, such as AVI, seek into the middle of an audio chunk
   without understanding audio packet boundaries at all (because the
   container format sucks too much to distinguish packets), forcing
   the decoder to recover. This also means (a) the demuxer will output
   a broken packet, which is bad if you just want to remux without
   using any codecs, and (b) pts is no longer exact, only approximate,
   which IMO sucks really bad.

My recommendation would be to _always_ seek to a boundary the demuxer
understands. That way you have exact pts, and no broken packets for
the decoder or muxer to deal with. The demuxer can skip video frames
up to the next keyframe (the point you were trying to seek to) and the
audio pipeline can skip the audio _after_ decoding it so that it can
keep track of the exact number of samples. (Since audio decoding is
very fast, this should not impact performance when seeking.)

2. After seeking, demuxers call resync_audio_stream, which depends on
   there being an audio decoder! I found this problem a long time ago
   while adding seeking support to mencoder: it was crashing with -oac
   copy! It's bad because it makes the demuxer layer dependent on the
   codec layer.

My recommendation is to eliminate resync_audio_stream, and instead
just report a discontinuity the next time the demuxer stream is read.
That way the codec, if one exists, can decide what to do when it reads
from the demuxer, without having to use a callback from the demuxer
layer to the codec. Also, resync should become unnecessary for most
codecs if my above seeking recommendation is implemented.

Please comment on whether you think these changes are acceptible.

Rich




More information about the MPlayer-G2-dev mailing list