Xpra: Ticket #1090: add new sound container formats: webm / matroska

Similar to what was done for gdppay / gdpdepay in #1075:

Both are "good" plugins and should support "vorbis" and "opus".

Wed, 13 Jan 2016 06:12:08 GMT - Antoine Martin: owner, description changed; cc set

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)

Wed, 13 Jan 2016 22:51:39 GMT - alas:

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

Thu, 14 Jan 2016 00:01:32 GMT - J. Max Mena:

Apparently it likes my system better

Running a Fedora 23 trunk r11692 against a Fedora 23 trunk r11692 server:

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.

Thu, 21 Jan 2016 03:50:15 GMT - Antoine Martin:

r11701 renames vorbis+webm to 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.

Mon, 25 Jan 2016 23:07:43 GMT - J. Max Mena:

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.

Mon, 25 Jan 2016 23:14:02 GMT - Antoine Martin: status changed; resolution set

Great! Closing.

Sat, 23 Jan 2021 05:14:42 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1090