Xpra: Ticket #1276: many codecs don't work on osx

Related to #1212, r12638, #1074, #1075.

Worked OK for me:

No workee:

Not tested:

This is a blocker bug because the defaults don't work. Is this a new thing? When did this regression start? And why didn't we spot it earlier? Is this caused by ticket:1168#comment:3 (tested on El Capitan). Does it work on other versions of OSX?

What do we do? Ideally, try #1168 first. Then maybe we have to disable more codecs on OSX?



Thu, 11 Aug 2016 18:48:27 GMT - J. Max Mena: owner changed

Handing this to myself so I can get info from various machines.

Please note: My testing steps are to connect with a --speaker-codec=$codec and walk through the available codecs listed in the Session Info page. I'm not bothering to test quality, just to see if they blow up in my face or not.

On an OSX 10.11 Machine (Trashcan aka MacPro?):

Codec Name Works?
opus+gdp yes
opus+ogg yes
vorbis+gdp no
vorbis+mka no
flac+gdp no
mp3 no
aac+gdp no matching
aac+mpeg4 no matching
raw+gdp+lz4 yes
raw+gdp yes
wav+lz4 yes
wav yes
wavpack yes
speex+gdp no
speex+ogg no

Edit: Turns out the server doesn't support AAC....


Thu, 11 Aug 2016 19:16:07 GMT - J. Max Mena:

OSX 10.10 machine (Macbook Pro)

Codec Name Works?
opus+gdp yes
opus+ogg yes
vorbis+gdp no
vorbis+mka no
flac+gdp no
mp3 no
aac+gdp no matching
aac+mpeg4 no matching
raw+gdp+lz4 yes
raw+gdp yes
wav+lz4 yes
wav yes
wavpack yes
speex+gdp no
speex+ogg no

Thu, 11 Aug 2016 20:48:00 GMT - alas: owner changed

OSX 10.9 machine (also Macbook Pro)

Codec Name Works?
opus+gdp yes
opus+ogg yes
vorbis+gdp yes
vorbis+mka yes
flac+gdp yes
mp3 yes
aac+gdp no
aac+mpeg4 yes
raw+gdp+lz4 yes
raw+gdp yes
wav+lz4 yes
wav yes
wavpack yes
speex+gdp yes
speex+ogg yes

I suppose you might've already seen the errors, but with aac+gdp (the only codec that didn't work with my un-updated osx) I got the following messages:

2016-08-11 13:32:09,206 sound output pipeline error: gst-stream-error-quark: Could not decode stream. (7)
2016-08-11 13:32:09,206 sound output  gstaudiodecoder.c(1632)
2016-08-11 13:32:09,206 sound output  gst_audio_decoder_push_buffers ()
2016-08-11 13:32:09,206 sound output  /GstPipeline:pipeline0/GstFaad:faad0:
2016-08-11 13:32:09,206 sound output  failed to parse stream
2016-08-11 13:32:09,207 sound output stopping
2016-08-11 13:32:09,224 stopping speaker because of error: gst-stream-error-quark: Could not decode stream. (7)
2016-08-11 13:32:09.836 xpra[68335:d0b] unlockFocus called too many times. Called on <GdkQuartzView: 0x18401f0>.

In any case, it looks like it is the 10.10 update that is breaking things.


Fri, 12 Aug 2016 06:23:19 GMT - Antoine Martin:

On win32: all works, except the ones we already disable explicitly in the code (not re-tested - I assume still broken, may re-test when the gio bindings are updated with a newer gstreamer version): aac+gdp, speex+gdp, speex+ogg.

I couldn't test OSX 10.6.x because the VM lacks a virtual sound device.

Every VM pre-10.10 VM I tested (10.5.8, 10.6.8, 10.7.x, 10.8.x, 10.9.x) worked with every codec, including aac+gdp. (weird) @maxmylyn: please post the server side sound information so we can see what pipeline generated this aac stream (I do remember that we support different combinations of gstreamer elements to produce aac, maybe your setup uses a different combination)

With 10.10 I get a invalid channel positions and internal data flow error with almost every codec, probably something wrong with the sound drivers on this VM. The only ones that work are: wav variants, aac variants. This looks related: osxaudiosink: Invalid channel positions warning with headerless wav file.


Fri, 12 Aug 2016 08:28:36 GMT - Antoine Martin: owner changed

Unfortunately, the patch does not apply to the 1.6.x branch, so I can't test to see if that helps. We need #1168 to know what to try next.

If this doesn't solve it, we will have to add a platform version test, something like this:

> import plistlib
> pl = plistlib.readPlist('/System/Library/CoreServices/SystemVersion.plist')
> pl
{'ProductUserVisibleVersion': '10.11.1', 'ProductCopyright': '1983-2015 Apple Inc.', 'ProductVersion': '10.11.1', 'ProductBuildVersion': '15B42', 'ProductName': 'Mac OS X'}

@maxmylyn / afarr: see comment:4, also when you said Works = no, what was the error? "Could not decode stream" or "invalid channel positions" followed by "internal data flow error"?


Fri, 12 Aug 2016 16:18:30 GMT - J. Max Mena: owner changed

For me, when I said "Works = no" it was the same error - "invalid channel positions" followed by "internal data flow error". Every time.

The end of comment:3 said that he saw the "Could not decode stream" rather than what I saw.

Lastly, -d sound didn't produce anything other than the server does not support aac at all. I'll poke around my machine this afternoon and see what package(s) I'm missing.


Fri, 12 Aug 2016 16:45:47 GMT - J. Max Mena:

Well here's the relevant bit anyways:

2016-08-12 09:13:38,116 Handshake complete; enabling connection[0m
[36m2016-08-12 09:13:38,120 pulseaudio id=None, server=None, sound decoders=['aac+gdp'], sound encoders=['vorbis+gdp', 'vorbis+gdp', 'vorbis+mka', 'flac+gdp', 'mp3', 'aac+gdp', 'aac+mpeg4', 'raw+gdp+lz4', 'raw+gdp', 'wav+lz4', 'wav', 'wavpack', 'speex+gdp', 'speex+ogg', 'speex+ogg'], receive=True, send=True[0m
2016-08-12 09:13:38,121 Python/Gtk2 Mac OS X client version 1.0-r13235 32-bit[0m
2016-08-12 09:13:38,121  connected from [censored][0m
2016-08-12 09:13:38,122  using h264 as primary encoding also available:[0m
2016-08-12 09:13:38,122   vp9, vp8, mpeg4, png, png/P, png/L, rgb24, jpeg, rgb32[0m
2016-08-12 09:13:38,124  client root window size is 1920x1080 with 1 display:[0m
2016-08-12 09:13:38,124   trashcan.local (677x381 mm - DPI: 72x72)[0m
2016-08-12 09:13:38,125     monitor 1[0m
2016-08-12 09:13:38,125 best resolution matching 1920x1080 is unchanged: 1920x1080[0m
2016-08-12 09:13:38,129 setting keyboard layout to 'us'[0m
[31m2016-08-12 09:13:38,184 client 7: Error: no matching codecs between client and server[0m
[31m2016-08-12 09:13:38,188 client 7:  server supports: opus+gdp, opus+ogg, vorbis+gdp, vorbis+mka, flac+gdp, mp3, raw+gdp+lz4, raw+gdp+lzo, raw+gdp, wav+lz4, wav+lzo, wav, wavpack, speex+gdp, speex+ogg[0m
[31m2016-08-12 09:13:38,188 client 7:  client supports: aac+gdp[0m
2016-08-12 09:13:38,188 client 7: Attached to tcp:10.0.32.170:2200 (press Control-C to detach)[0m
[36m2016-08-12 09:13:41,254 stop_sending_sound() sound_source=None[0m
[36m2016-08-12 09:13:41,255 stop_receiving_sound() sound_sink=None[0m
2016-08-12 09:13:41,255 xpra client 7 disconnected.[0m

Sun, 21 Aug 2016 04:35:15 GMT - Antoine Martin: owner changed

#1168 seems to have done the trick for me.

We still get this warning: WARNING: 140: This application, or a library it uses, is using the deprecated Carbon Component Manager for hosting Audio Units. Support for this will be removed in a future release. Also, this makes the host incompatible with version 3 audio units. Please transition to the API's in AudioComponent?.h., hopefully this will be fixes in the next gstreamer release. Or maybe moving to a newer build environment (#840) will allow it to use the newer headers and API?

Please re-test the latest trunk and the 0.17.5 release candidate. Ensure there are no memory leaks, etc.. Also, is aac+gdp still a problem on 10.9 for you?


Tue, 23 Aug 2016 18:58:49 GMT - J. Max Mena:

With the trunk latest r13447:

EDIT: tested the wrong client version, updated this info after testing the correct client version. No changes as to what works and what doesn't. Chrome caching strikes again!

Codec Name Works?
opus+gdp no
opus+ogg yes
vorbis+gdp yes
vorbis+mka yes
flac+gdp yes
mp3 yes
aac+gdp yes
aac+mpeg4 yes
raw+gdp+lz4 yes
raw+gdp yes
wav+lz4 yes
wav yes
wavpack yes
speex+gdp yes
speex+ogg yes

Oddly enough, opus+gdp has stopped working(EDIT: "internal data flow error" - no "invalid channel" print), but all the other codecs are. And, the aac+gdp issue is limited to one specific server - I'm missing a package to get it, will look into it, but that server is broken - #1291.

Also of note:

And, using the 0.17.5 release candidate r13418:

Codec Name Works?
opus+gdp not available
opus+ogg not available
vorbis yes
vorbis+mka yes
flac not available
flac+gdp yes
mp3 yes
aac+gdp not available
aac+mpeg4 not available
raw+gdp+lz4 not available
raw+gdp not available
wav+lz4 yes
wav yes
wavpack yes
speex+gdp yes
speex yes

The ones marked not available - self explanatory, the client spits out that that is an incorrect option. But, nothing was outright broken in 10.11. I'll get lunch and come back and try 10.9 and 10.10. And then, I'll check the 0.17.5 and the 1.0 more thoroughly. In the meantime, I'll hold on to this ticket.


Tue, 23 Aug 2016 20:06:46 GMT - J. Max Mena:

And using an OSX 10.10 machine(afarr has the 10.9):

Codec Name Works?
opus+gdp no
opus+ogg yes
vorbis+gdp yes
vorbis+mka yes
flac+gdp yes
mp3 yes
aac+gdp yes
aac+mpeg4 yes
raw+gdp+lz4 yes
raw+gdp yes
wav+lz4 yes
wav yes
wavpack yes
speex+gdp yes
speex+ogg yes

Using the 0.17.5 release candidate r13418:

Codec Name Works?
opus+gdp not available
opus+ogg not available
vorbis yes
vorbis+mka yes
flac+gdp yes
mp3 yes
aac+gdp not available
aac+mpeg4 not available
raw+gdp+lz4 not available
raw+gdp not available
wav yes
wavpack yes
speex+gdp yes
speex yes

And, now I'll do some more in-depth testing on my 10.10 machine as it uses the monitor that's less likely to cause neck damage after prolonged period of use.


Tue, 23 Aug 2016 21:52:26 GMT - J. Max Mena:

Finished with the 0.17.5 Client:

Moving on to the 1.0 Client.


Wed, 24 Aug 2016 01:28:36 GMT - alas:

Testing with a 1.0 r13447 osx client on a 10.9 osx, against 1.0 r13448 fedora 23 server. (As an odd side note, shift+alt+F11 wasn't opening Session Info with the combo, had to use the client's application menus... no logs on either side.)

Codec Name Works?
opus+gdp no
opus+ogg yes
vorbis+gdp yes
vorbis+mka yes
flac+gdp yes
mp3 yes
aac+gdp no
aac+mpeg4 yes
raw+gdp+lz4 yes
raw+gdp yes
wav+lz4 yes
wav yes
wavpack yes
speex+gdp yes
speex+ogg yes

Wed, 24 Aug 2016 05:36:27 GMT - Antoine Martin:

Testing with both Fedora 23 and Fedora 24 servers, I can see the gdp variants failing only when connecting to Fedora 23. The main difference is that Fedora 23 runs GStreamer 1.6.x whereas Fedora 24 uses 1.8.x

We have switched to gstreamer 1.8.x (#1168) around the same time, so this has gone unnoticed until now: r13449 changes the codec order so that the formats that use the gdp muxer will end up at the end of the list. (will backport).

r13450 filters the codecs to remove the "gdp" variants if we find that the server gstreamer version is different from the client's. But that's just ugly and brittle, and it would still show those options as available on the command line (--speaker-codec=help, so r13451 just removes all gdp options (undoes #1075) - we have enough codec options anyway.

Please re-test, both against gstreamer 1.6.x (ie: Fedora 23) and gstreamer 1.8.x (ie: Fedora 24)


Wed, 24 Aug 2016 21:58:12 GMT - J. Max Mena:

Finished my testing of the 1.0 client:

Will retest with different gstreamer versions on Friday.


Thu, 25 Aug 2016 06:36:54 GMT - Antoine Martin:

The aac+mpeg4 issue should be tracked in #1194 or maybe a new OSX specific ticket if that's where the problem lies. mpeg4 is important for sound support with the html5 client.


Fri, 09 Sep 2016 02:28:26 GMT - Antoine Martin:

Will retest with different gstreamer versions on Friday.


Please make sure to re-test with a 1.8.3 gstreamer (ticket:1168#comment:9) and record mpeg4 issues in #1194.


Mon, 24 Oct 2016 19:40:24 GMT - J. Max Mena:

Update:

Got the GST quark error against a Debian Jessie 17.5 server with a Fedora 24 17.5 client at home. Will investigate - probably related to older ffmpeg, unless it's not. Just jotting this down here so I don't forget.


Sun, 30 Oct 2016 15:48:40 GMT - Antoine Martin:

I was seeing some errors with older distros running gstreamer 0.10, so we now only enable "matroska" on gstreamer 1.x: r14339.


Mon, 31 Oct 2016 19:28:02 GMT - J. Max Mena: owner changed

Okay, upped server to r14364 - with two different machines - one is Fedora 24 and the other is Fedora 23. Both are built from latest trunk source (r14364) - the client machine is an OSX 10.11 machine running a trunk r14155 Client:

Test steps are the same - connect and see if sound doesn't blow up or not.

Against the Fedora 24 machine:

Codec Name Works?
opus+gdp not supported by client
opus+ogg yes
vorbis+gdp not supported by client
vorbis+mka yes
flac+gdp yes
mp3 yes
aac+gdp not supported by client
aac+mpeg4 yes
raw+gdp+lz4 not supported by client
raw+gdp not supported by client
wav+lz4 yes
wav yes
wavpack yes
speex+gdp not supported by client
speex+ogg yes

Again, against a Fedora 23 machine (older):

Codec Name Works?
opus+gdp not supported by client
opus+ogg yes
vorbis+gdp not supported by client
vorbis+mka yes
flac+gdp not supported by client
mp3 yes
aac+gdp not supported by client
aac+mpeg4 server has it disabled
raw+gdp+lz4 not supported by client
raw+gdp not supported by client
wav+lz4 not supported by server
wav yes
wavpack yes
speex+gdp yes
speex+ogg yes

---

It would seem that the newer trunk builds have notably fewer codecs enabled, but all the ones enabled, but all the ones enabled do work.

Passing back to you - everything seems to be behaving nicely, at least for what's enabled.


Tue, 01 Nov 2016 02:38:35 GMT - Antoine Martin: status changed; resolution set

All the "gdp" options have been removed, see comment:13 for details.


Sat, 23 Jan 2021 05:19:50 GMT - migration script:

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