xpra icon
Bug tracker and wiki

This bug tracker and wiki are being discontinued
please use https://github.com/Xpra-org/xpra instead.

Opened 6 years ago

Closed 6 years ago

Last modified 16 months ago

#1090 closed enhancement (fixed)

add new sound container formats: webm / matroska

Reported by: Antoine Martin Owned by: alas
Priority: major Milestone: 0.17
Component: sound Version: trunk
Keywords: Cc: dbrushinski@…

Description (last modified by Antoine Martin)

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

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

Change History (7)

comment:1 Changed 6 years ago by Antoine Martin

Cc: dbrushinski@… added
Description: modified (diff)
Owner: changed from Antoine Martin to alas

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)

comment:2 Changed 6 years ago by 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.)

comment:3 Changed 6 years ago by J. Max Mena

Apparently it likes my system better

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

  • vorbis+webm works 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.

comment:4 Changed 6 years ago by 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.

comment:5 Changed 6 years ago by 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.

Last edited 6 years ago by J. Max Mena (previous) (diff)

comment:6 Changed 6 years ago by Antoine Martin

Resolution: fixed
Status: newclosed

Great! Closing.

comment:7 Changed 16 months ago by migration script

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

Note: See TracTickets for help on using tickets.