[gst-devel] Streaming video and the 'queue' plugin

[Martin Janzen]

I understand that the chief GStreamer gurus are currently far too busy
enjoying their hyperborean holiday to read this (and/or will be unable
to type before having thawed out for several days?); but in the
meantime, perhaps someone else will be able to comment...

I'm building an MPEG-2 transport stream viewer process which receives
input from a file or a UDP source, and displays the resulting video
on an Xv-capable X server.  The GStreamer platform seems ideal for
this; and so far, things have gone reasonably well.  I now have a
plugin which extracts a PID from the MPEG-2 TS and decodes TS and PES
headers, and am driving it from an application that creates a pipeline
equivalent to:

    gst-launch filesrc location=<file> !
      queue max-level=<M> leaky=2 min_threshold_bytes=<N> !
      { mytsdecoder pid=<pid> ! mpeg2dec ! xvideosink xid=<window_id> }
or
    gst-launch udpsrc port=<port> !
      queue max-level=<M> leaky=2 min_threshold_bytes=<N> !
      { mytsdecoder pid=<pid> ! mpeg2dec ! xvideosink xid=<window_id> }

A sharp-eyed reader will notice that the "min_threshold_bytes"
property is not a part of the standard queue.  I've added this so
that, when the queue is emptied, the reader thread (the "downstream"
side of the queue) is not awakened by  a "not_empty" signal until
the queue has refilled to at least this level.  Without it, the
queue level bounces along near the bottom, rather than filling to a
reasonable level:

Before:              After:

                        +--------- block reader thread
                        |      +-- signal reader thread
                        |      |              /
                        v      v             /|
                                   /   min_threshold_bytes
                      - - - - -/- /|- - - -/- | - - - - - -
                              /| / |  /   /   | /  __
                             / |/  | /|  /    |/| /   etc.
                            /      |/ | /       |/
    /   /    ^          /  /          |/
__/|__/|___/|__      _/|_/


A similar threshold could be added easily to block the "upstream"
writer thread until a full queue drops below a threshold, rather
than waking it as soon as anything is removed, as at present.
In my application I just allow it to leak downstream, since
blocking the incoming UDP traffic is not possible.

I'm happy to submit this simple patch, if anyone else wants it.
But I was a bit surprised that the queue didn't do something like
this already.  Does this mean that I am missing something?  Has
anyone else used GStreamer for similar network-based streaming
applications which benefit from pre-buffering?  Is there another
way to do this?

-- 
Martin Janzen
janzen at pixelmetrix.com