switch to gstreamer 1.x on win32

[Antoine Martin]

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:

• we could ship a different version of python for the sound process (ie: python3)
• this ensures that the sound modules and dlls cannot be loaded from the main process at all

[Antoine Martin]

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:

• run the py3k build and install the client
• run the py2k build and install somewhere else
• use the 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.

[Antoine Martin]

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:

• trim down the python3 build further (remove "--with-gtk3" and "--with-client" which should not be needed)
• fix bencode warning (and related alert box?)

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.

[Antoine Martin]

could be useful if we need to modify the environment on win32 before launching the sound subprocess

[Antoine Martin]

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:

• get rid of the warning about missing "bencode" (we don't care, we use rencode)
• trim DLL dependencies further (dupe msvcr..)
• split gobject util so we can include the gobject bits without any gtk
• better error handling in the "xpra_cmd.exe" built without client / server support

[Antoine Martin]

the bencode warning was meant to be fixed (really ugly fix) in r11685 - doesn't seem to have done it :(

[Antoine Martin]

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

[Smo]

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.

[Antoine Martin]

Note: version 3.18.2 rev6 of the gi bindings is out, but this does not update gstreamer, still at 1.6.3

[J. Max Mena]

Did some testing with the r13031 trunk Windows client (from /beta) against a trunk r13101 Fedora 23 server:

• Most codecs and containers work fine. I used --speaker-codec= on the client side to force a specific codec+container combo.

• I got an error with 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.

[Antoine Martin]

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.

[Antoine Martin]

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)

[J. Max Mena]

Did some further testing with newer versions:

• Fedora 23 trunk r13283 behaves nicely. No issues with sound codecs

• OSX r13235 on the other hand does not have working vorbis and flac at all, all combinations fail. The other codecs behave nicely, however

• They fail with the same error as mentioned in comment:8

[Antoine Martin]

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

[J. Max Mena]

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.

[Antoine Martin]

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.

[migration script]

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