[pulseaudio-discuss] [PATCH 0/8] Add GStreamer-based RTP support

[Arun Raghavan]

On Mon, 2016-02-29 at 19:33 +0200, Rémi Denis-Courmont wrote:
>     Hello,
> 
> Le 2016-02-29 12:16, arun at accosted.net a écrit :
> > 
> > Here's a patch set to add a GStreamer-based RTP implementation for
> > module-rtp-send and module-rtp-receive. The rationale for this is 
> > that
> > our own RTP implementation is rather basic, and using a more
> > well-established stack will allow us to do more, such as add support 
> > for
> > RTCP, clock synchronisation, and compressed formats. This should also
> > reduce our support burden for the RTP stack in theory (although we 
> > don't
> > have too much other than the occasional crasher, I think).
> Support for RTCP SR, SDES and BYE compound would probably take less 
> code than support for gstreamer. Not that RTCP is simple in general, but 
> RTCP for a single session actually is.

The difference between the two implementations stands at +100 lines for
GStreamer, but this is not about the amount of code as much as which
project has a reasonably well-maintained RTP stack. There are more
people using GStreamer for this (contributions to RTP have been
miniscule in PA), so over time, whether for features or bugs, not
relying on our own implementation is a good thing, IMO.

> There are plenty of interesting features that could be had with a 
> higher level multimedia framework. Nevertheless, I think adding a 
> dependency from a lower level framework onto a higher level one is a 
> layering violation. From an engineering point of view, I find that 
> unsatisfying. Also I expect this to annoy a variety of people, either 

This is a question of pragmatism. It would be nice to introduce a
separate sharing daemon (for both audio and video) that is able to
properly set up and manage streams (and ideally do DLNA, RTSP, whatever
else we want). In practice, I think this is a significantly larger
effort and one more moving piece that needs to be maintained (with
proper desktop environment integration).

I don't see anyone stepping up to do this work in the short/medium
term, so to be practical, continuing to do this in PA, and improving
that, makes sense.

> because they don't want a multimedia framework dependency, don't want 
> gsteamer, or want to keep the dependency from gstreamer to PulseAudio 
> unidirectional.

Right now, the RTP module supports a GStreamer-less fallback. If we
remove that, we can make the module as a whole optional for those
people. I don't think it is worth worrying about a small minority
fussing over dependencies for which there is a considered reason. 

> Also I am not sure if bringing gstreamer (or really, any big ass 
> multimedia framework) into the PulseAudio process is such a great idea. 
> I would rather expect a Gstreamer-based process to instantiate a 
> PulseAudio sink, and pass the data over some IPC - basically same as 
> ALSA over PulseAudio.
> 
> Specifically, I would not do live stream compression with the PA 
> process, even though that enables obvious desirable streaming features.

I've replied to the rest above, but just to note for those that aren't
aware -- the GStreamer bits occur on a separate thread.

> (...)
> > 
> > From a packaging perspective, this might be a bit confusing since we 
> > add
> > a dependency on the GStreamer package which might in turn depend on
> > PulseAudio (for pulsesrc and pulsesink). The exact dependencies are:
> Well there is the literal interpretation of circular dependency, and 
> then there is the expectation.
> 
> This patch series does not strictly introduce a circular dependency. A 
> distro build bot should still be happy. But it does introduce a circular 
> dependency between the two projects, and impose constraints on the 
> gstreamer build system.

It's not a circular dependency in any practical sense (the components
involved don't form a loop). I don't follow what constraint would be
added to the GStreamer build system.

Cheers,
Arun