Split from #970.
In particular, ticket:970#comment:17
We will probably need to build things twice and bundle a nested app. Hopefully this won't be too big. This may have some benefits too:
After many fixes to the py3k build and its packaging, and updating it to the latest gobject win32 binaries (ie: r11567), we can run the gstreamer 1.x sound helper from a python2 / gtk2 client:
XPRA_SOUND_COMMAND
override to point the py2k client at the py3k helper
This needs packaging and trimming down - oh, that's going to be fun.
Re gtkglext, see ticket:640#comment:34.
Lots of preparatory work related to python3 packaging done in r11573 + r11575 (batch file refactoring), r11571 (DLL packaging). Added support for GStreamer 1.x opus and vorbis in r11572. Finally, the big one in r11579.
Still TODO:
I think we'll keep GStreamer 0.10 in this release so we still have a fallback, and remove it completely in 0.18: #1071.
could be useful if we need to modify the environment on win32 before launching the sound subprocess
Done in r11584, with some self-contained general code improvements in r11586, r11587, r11583, r11581, r11588, r11589.
The compressed installer has gained a bit of weight (about 10MB) because of the extra duplicate binaries it now contains: python 3.4 interpreter, gstreamer 1.x libraries, python modules.. The actual disk space used has increased by 45MB from ~92MB to 137MB.
We can reduce this by removing gstreamer 0.10 from the installation (#1071 scheduled for 0.18), but for the time being I prefer to keep both so that we can toggle which one is used at runtime using the XPRA_GSTREAMER1=0
env var (could be useful for debugging and comparing).
The version of gstreamer currently in use can be seen in the client output, or on the session info dialog.
@afarr: ready for testing, there should be no user visible changes, apart from the availability of newer codecs (opus). It might make sense to test this one with #1074.
Still on my TODO list / nice to have / later:
the bencode warning was meant to be fixed (really ugly fix) in r11685 - doesn't seem to have done it :(
@smo: I've updated to the latest gi aio build (pygi aio 3.18.2 rev5 released yesterday), and got gstreamer 1.6.3 for free.
Please update your build system and re-assign to afarr.
I've updated this and built new installers. Looks to have all the necessary files I will pass on to afarr for some more testing.
Note: version 3.18.2 rev6 of the gi bindings is out, but this does not update gstreamer, still at 1.6.3
Did some testing with the r13031 trunk Windows client (from /beta) against a trunk r13101 Fedora 23 server:
--speaker-codec=
on the client side to force a specific codec+container combo.
flac+ogg
:
2016-07-27 11:11:53,022 sound output pipeline error: gst-stream-error-quark: Internal data flow error. (1) 2016-07-27 11:11:53,024 sound output gstbasesrc.c(2943) 2016-07-27 11:11:53,025 sound output gst_base_src_loop () 2016-07-27 11:11:53,025 sound output /GstPipeline:pipeline0/GstAppSrc:src: 2016-07-27 11:11:53,026 sound output streaming task paused, reason not-negotiated (-4) 2016-07-27 11:11:53,026 sound output stopping 2016-07-27 11:11:53,028 stopping speaker because of error: gst-stream-error-quark: Internal data flow error. (1) 2016-07-27 11:11:53,522 sound output using audio codec flac
It consistently fails, so it's not a one time thing.
Other than that combo not working, everything else I tried worked fine.
I got an error with flac+ogg
Fixed in r13102. (edit: backport not needed)
Most codecs and containers work fine.. Other than that combo not working, everything else I tried worked fine.
Assuming that other platforms have been tested (osx, ubuntu, etc) and that removing flac+ogg is enough, please close.
Had problems with flac+ogg on Fedora, so now it is disabled on all platforms by default: r13108. (even though it seems to work with osx clients)
Did some further testing with newer versions:
This ticket is about win32 and can be close IF all the codecs work on win32. Please update #1276 for OSX and record the OSX version(s) used for testing there (since different versions of OSX seem to give different results).
I had a feeling that's what you'd say, but just wanted to make sure.
All the other codec combinations I've tried (I am fairly sure I hit them all) worked fine in Win32.
Closing.
Note: we no longer use python3 for the sound subprocess on win32 since #678, because cx_freeze chokes on the python3 bits.
This could be re-added, see #640 and #1568.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1041