Source bin vs 'fake demux'

[Nicolas Dufresne]

Le mardi 04 mars 2014 à 07:23 -0800, ejcunningham a écrit :

> Hi All, 
> 
> I'm writing a source element that wraps an audio+video streaming library and
> I'm trying to conform to gstreamer conventions as closely as possible. I've
> discovered via this list that source elements with multiple src pads are
> discouraged in favor of the multiple element+bin design, but I'm struggling
> to understand why other than the fact that GstBaseSrc supports only a single
> pad.  Is there a deeper reasoning behind this convention other than
> consistency of implementation?

At a lower level, a source is a socket, a file, a serial port, a USB
port, etc. hence only has one stream. It is the most common use case,
but not really a convention. Some source provides multiple output, bus
contains multiple elements, that is true for rtspsrc. They do that
because it was simply a better design to reuse existing code then
re-implementing what udpsrc, tcpsrc, etc. already do.

Element design is always done on a case by case scenario. A consistant
element from my perspective is an element that just work. So if you are
providing a src, you may want to implement URIHandler so playbin can
find it, you may choose working default so they don't need to be
configured, etc.

About BaseSrc, it only has 1 output src pad because it is the most
common. Also, src with multiple source pad tend to be very complex and
different, so it was not easy to think of a base class for that. You
have to deal with two concurrent streaming threads, and make sure there
is no interlocking. I've seen few people wrap two appsrc to benefit from
the already implement thread handling there, though you need to
understand it to make it work.

> 
> I've also noticed that there are several 'fake demux' elements out there
> that appear to essentially be source elements with multiple pads disguised
> as demux elements (example: dashdemux plugin).  Is this design acceptable
> (preferable?) over the bin implementation? 


Element for fragmented protocol are not sources at all, they have a sink
pad. Though, they use special trick to communicate to the source the new
URIs (usually it's http based) to download. They are demuxers in the
sense that they do what a demuxer shall do, which is to select and offer
multiple streams and handle seeks (they driver the pipeline). But in
practice, the protocol they implement make them way more complex then
that.

good luck with your design,
Nicolas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20140304/1401dd14/attachment-0001.html>