Similar to what was done for gdppay / gdpdepay in #1075:
Both are "good" plugins and should support "vorbis" and "opus".
Done in r11679.
You can now select
vorbis+webm as codec.
I've used the name "webm" instead of "matroska" just because it is shorter, but could easily be convinced to change it if this isn't right.
I did try to enable
opus+webm but that didn't work and gstreamer complained about
could not link opusenc0 to webmmux0. Not sure we care?
@afarr: ready for testing (very similar to #1075), then maybe pass it over to Dave? (added to CC list since he doesn't have a trac account yet)
It looks like
vorbis+webm is in all the lists/arrays of
gstreamer_util.py for a 0.17.0 r11692 fedora 23 server, but I don't see it available as an option on any 0.17.0 r11687 clients (windows or OSX ... no access to a fedora client just now).
Unsurprisingly, when I try to connect and force with
--speaker-codec=vorbis+webm client side, I get the following warning
Warning: invalid value for speaker-codec: vorbis+webm.
What was a little surprising was that, when I then tried to restart the speakers in the client side tray (application bar) menu, I got the following error:
error setting up sound: start_sending_sound() takes exactly 7 arguments (6 given). I'm not sure, but maybe it's expecting a specification for which codec to use? (I think the control channel was holding out for that argument for a while too.)
Apparently it likes my system better
Running a Fedora 23 trunk r11692 against a Fedora 23 trunk r11692 server:
vorbis+webmworks fine. No errors or warnings.
As far as the name goes...their website says mka is the file extension for Matroska audio files. WebM usually refers to video files. "Usually". Not that it's a big deal.....
As an aside, I am seeing some notable choppy-ness (periodic sound dropping out for a few milliseconds) to the sound with all of my codecs.
vorbis+webm seems to behave slightly better of all the codecs I've tried in the last hour or so. Watching the sound queue in graphs shows that the min stays at 0 with the level bouncing up to 60-70 and back down to 0 constantly.
mp3 is the only one that appears to adjust the min, if only for a short period before dropping down to 0. Not sure if this is relevant or not. I'm gonna keep looking and see if I find a pattern.
vorbis+mkv, so you won't be able to use this codec+muxer if you mix older and newer versions.
The choppyness sounds like a real problem and should go in a separate ticket.
upped client and server to r11753:
Did some further spelunking, and found out that the choppy-ness I'm getting is actually a hardware issue with the client machine(Fedora 23). For some odd reason, my headset disconnects for a few hundred milliseconds periodically. (A couple times a minute) I've double-verified that it's a client side hardware issue by running a couple local applications and observing identical behavior. Hell, it's randomly disconnecting even when nothing is playing sound.
As far as I can tell, mka works great.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1090