GNOME Bugzilla – Bug 629117
Move rtpmux elements to -good
Last modified: 2012-12-17 01:11:40 UTC
Lets try to move the rtpmux plugin from gst-p-bad to -good. It has unit tests and everything.
Can the elements be used from gst-launch? If so, please add an example launch pipeline. I just pushed 3 small cleanup patches and give my +1 for the move.
I added an example to the doc.
Don't mind moving this, the only thing I'm wondering about is the "rtp dtmf muxer" - the description makes it sound like it's useful in general, more like a rtpmux with priority pad, but then it seems pretty much geared towards dtmf. Is it useful in other circumstances as well? The rtpmux docs blurb could use a short explanation about typical usage scenarios (where is it useful etc.). Is it useful to move this without the dtmf plugin, or should both be moved together really?
It's true that the dtmf muxer really has nothign DTMF specific now (although I don't know any other usecase). Maybe we can to rename it ? I also have a half finished branch of dtmfsrc tests somewhere... I was planning to ask for the dtmf elements to be moved to -good once it's done.
Ok, let's move this next cycle together with the dtmf plugin then. Don't know about renaming rtpdtmfmux. If there's no real other use case, we may just as well leave it as it is - that way it's easier to discover. If someone ever comes up with another use case, we can still add a more generic variant.
commit 3295b5d79100c9a4378a12057af5bb4208439338 Author: Tim-Philipp Müller <tim@centricular.net> Date: Sun Dec 16 15:13:38 2012 +0000 rtpmanager: move rtpmux and rtpdtmfmux elements from -bad https://bugzilla.gnome.org/show_bug.cgi?id=629117 commit 02ab609c11af7555e6f70288b826518166dddec9 Author: Tim-Philipp Müller <tim@centricular.net> Date: Sun Dec 16 17:35:07 2012 +0000 rtpmux: remove rtpmux plugin, moved to -good Move rtpmux and rtpdtmfmux into rtpmanager plugin in -good. https://bugzilla.gnome.org/show_bug.cgi?id=629117
The dtmf plugin needs some more work, I think. tone_detect.c is only placed in the public domain, I'm not sure that's suitable for a move to -good. I'm sure we can find a replacement that's suitably licensed.
I don't see what the problem is with public domain, it's the most permissive regime as there is no copyright involved. This file is also copied into every SIP server out there, so it shouldn't be an issue. That said, it is also part of libspandsp, so we can move that element there, but it would be a bit annoying as I'd like to use it for the unit tests, which happen to be missing. It is only tested by Farstream's tests.
I think 'public domain' is not a concept that's applicable/valid in many jurisdictions (esp. in Europe?), where you can't give up your copyright like that. In those cases, it's just copyrighted without a license.
One could just also argue that it's licensed with the most liberal terms possible, since it's clearly the intent of the author.
See this for more info: http://www.gnu.org/licenses/license-list.html#PublicDomain Part of the reason for being strict about licensing in -base/-good is for licensing simplicity. "Public domain grant" code creates licensing uncertainty, since there is no real legal mechanism to make a license do that.
There's a separate bug for the dtmf move btw in case y'all want to move this discussion there: bug #687416