[gst-devel] why MPEG fails

[Martin Soto]

On Fri, 2004-03-12 at 20:52, Ronald S. Bultje wrote:
> No, no. This is the actual buffer flow. No thread, so all's lineair.
> Just go through the file like an MPEG demuxer.
> 
> * read audio buffer
> * decode
> * put in osssink
> * osssink sets audio clock to time on buf (0s)

I wouldn't expect the clock to end in 0s here. Sound clocks work by
accumulating the length of the played material, so if the buffer was
actually played by osssink, I'd expect the clock to end up in 0.1s or
whatever length of sound material you had.

> * read video buffer
> * decode
> * put in ximagesink
> * gst_element_wait(1s)

What? If you have to wait for a second, this means the audio and video
timestamps don't match, or, rather, you're receiving a second of audio
without accompanying video. Is that really normal with MPEG? My only
experience with MPEG is with DVDs, and so far I haven't seen any DVDs
showing that behavior (I have some 40 or 50 here at home).

> * triggers a wait for 1s (clock diff between clock and buffer)

Among other things, one element waiting shouldn't block the pipeline, it
should just block that element. I don't know if schedulers handle this
properly, though.

> * play frame
> * read audio buffer
> [.. etc.]

M. S.(who is scratching his head in confusion right now...)
-- 
Martin Soto <soto at informatik.uni-kl.de>