[gst-devel] Test MPEG-1 streams

[Erik Walthinsen]

On Sun, 13 Feb 2000, Wim Taymans wrote:

> One problem with the threads you created: the queues are filled up quite 
> fast on my machine, the parser hits eof and ends the program before even
> the first frame is decoded.
Wow.  I get almost all the way through the video before it finishes,
albeit at a much higher speed than the audio... (PIII/500 Coppermine)

> How do we check the end of the decoding process in all the elements?
My plan is to have the EOS bit set on the last buffer as it comes off the
source, and each element has to deal with passing the EOS bit on its last
buffer, or sending a zero-byte buffer with said bit if absolutely
necessary.

Now, the other half of this is state transitions.  I made that change to
gstbin.c:gst_bin_add() last night because the state stuff is a bit of a
mess right now.  Basically, the idea is that as the EOS packet travels
thorugh the system, the elements turn off either their RUNNING or PLAYING
state.  Not sure which.  Probably RUNNING.  I'm a bit fuzzy on how to use
PLAYING and PAUSED, except in the thread case, where they signify whether
or not the thread is spinning.  Hmm.  Probably want to turn off RUNNING
state, since the idea is that once the stream is gone the thing isn't
running.  Of course, that means turning off the PLAYING state too.

Bleagh, I've got to think about this more, especially in the context of
reconfigurable pipelines.  As an example, XMMS will skip a bit when
switching between MP3's, since it doesn't prefetch the next file.  Enigma
4 and others have run-through tracks...  The idea would be to create the
disksrc and cache elements for the next file, then connect them up to a
mux element that will strip the EOS bit from a given stream, responding by
sending a signal indicating the end of that stream (specific to that
element) and switching to the other stream.  It would be app-specific,
etc...  State transitions there could get really fun.

>  Limit the size of the queue to some arbitrary length (configurable). Bad
>  option? 
No, that's the idea.  I think the queue code has that built in already, I
just don't set a limit.  The idea is for the buffer to eventually look a
lot like the ones we have at work, which are time-based rather than
packet- or byte-based, have a size and fill level, and the level is used
to schedule the elements.  That's the research we do at work...

>  Make the system stream parser aware of the PTS/DTS timecodes. How do we
>  do with WAV? limit buffer length?
Yeah, timecodes are there in the buffers, I think, and need to be set by
the various parsers.  System parsers are easy, we just convert from the
units in the header to UST-style nanoseconds since start.  MP3's and
PCM-based files (WAV, au, etc.) will fabricate based on frame or byte
offset.

At the head end (display,sound) these timecodes will be used to sync with
the master clock (which will be clocked to the sound card but offset based
on the seek interface of the source parser), which will keep the display
and audio ends from pulling stuff out of their queues too fast (and invoke
the real-rate concept used to schedule cleanly at work).

> i'll implement the buffer length for now. You'll allways want to limit the 
> queue length or you'll end up having a complete movie in memory.
Yup.

         Erik Walthinsen <omega at cse.ogi.edu> - Staff Programmer @ OGI
        Quasar project - http://www.cse.ogi.edu/DISC/projects/quasar/
   Video4Linux Two drivers and stuff - http://www.cse.ogi.edu/~omega/v4l2/
        __
       /  \             SEUL: Simple End-User Linux - http://www.seul.org/
      |    | M E G A           Helping Linux become THE choice
      _\  /_                          for the home or office user