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

[Rémi Denis-Courmont]

    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.

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 
because they don't want a multimedia framework dependency, don't want 
gsteamer, or want to keep the dependency from gstreamer to PulseAudio 
unidirectional.

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.

(...)
> 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.

-- 
Rémi Denis-Courmont
http://www.remlab.net/