<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8"> <META NAME="GENERATOR" CONTENT="GtkHTML/4.6.6"> </HEAD> <BODY> Le mardi 04 mars 2014 à 07:23 -0800, ejcunningham a écrit : <BLOCKQUOTE TYPE=CITE> <PRE> 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? </PRE> </BLOCKQUOTE> 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. <BLOCKQUOTE TYPE=CITE> <PRE> 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? </PRE> </BLOCKQUOTE> 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 </BODY> </HTML>