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/
