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
