Switch to GStreamer 1.0 and PyGI

[jodal]

GStreamer 1.0 was released a couple of months ago. As far as I know, it doesn't bring any new features that are important for Mopidy.

Though, in GStreamer 1.0 the GStreamer Python bindings have been replaced by PyGI, which is generic Python bindings for any library supporting GObject Introspection.

Switching to PyGI will remove our dependency on the Python bindings for GStreamer, GObject, and libindicate, and maybe even the DBus bindings. Replacing this pile of manually maintained Python 2.x bindings with PyGI, which works under both Python 2 and 3, is a huge step towards bringing Mopidy to Python 3, and is thus something we should do.

A spike for porting to PyGI using GStreamer 0.10 was done in #147. I wasn't that much work, but we hit some problems that will not be resolved in GStreamer 0.10, so we can't move to PyGI without moving to GStreamer 1.0 at the same time. https://wiki.ubuntu.com/Novacut/GStreamer1.0 is a great resource which explains most of what needs to be changed in the migration.

The question isn't if we should port to PyGI, but when.

The current status of GStreamer 1.0 is:

• Included in Ubuntu 12.10: https://launchpad.net/ubuntu/+source/gstreamer1.0
• Packages for Ubuntu 12.04 is available from the GStreamer PPA on Launchpad: https://launchpad.net/~gstreamer-developers/+archive/ppa
• Not in the upcoming Debian Wheezy release, but 1.0 packages are in sid: http://packages.debian.org/search?keywords=gstreamer1.0-plugins-good&searchon=names&suite=all&section=all
• Not available in Homebrew: https://github.com/mxcl/homebrew/blob/master/Library/Formula/
• Available in Arch: https://www.archlinux.org/packages/?q=gstreamer

My current guess is that we don't want to port before some time in 2013.

[adamcik]

http://lazka.github.io/pgi-docs/ for a very useful pgi reference doc.

[adamcik]

http://lazka.github.io/pgi-docs/ for a very useful pgi reference doc.

[txomon]

When you said 2013, you mean 2014? or later this year?

[txomon]

When you said 2013, you mean 2014? or later this year?

[jodal]

That was written a year ago.

I think the distro support is good enough now, so I'd port anytime if I wasn't in the middle of other stuff like pyspotify2.

[jodal]

That was written a year ago.

I think the distro support is good enough now, so I'd port anytime if I wasn't in the middle of other stuff like pyspotify2.

[klausenbusk]

Any update?

[klausenbusk]

Any update?

[jodal]

Porting to PyGI and GStreamer 1.x is still a high priority on our technical roadmap.

Things that need to happen before porting:

• Reintroduce volume mixers as something independent of GStreamer, like it was in Mopidy a long long time ago. GStreamer 1.x does no longer support hardware volume mixing, as in ALSA or similar, only software volume mixing.
• Extract/reimplement our playlist format support to not depend on GStreamer. There's some issues with reimplementing this on top of PyGI/GStreamer 1.x. @adamcik has details for those interested.

Modules to port to PyGI:

• mopidy.audio use GStreamer and GObject
• mopidy.__main__ use GLib
• mopidy.commands use GLib and GObject
• mopidy.listener use GObject
• mopidy.utils.network use GObject
• mopidy.utils.path use GLib

After porting Mopidy proper, we should have a look at Mopidy-MPRIS:

• python-indicate bindings to libindicate can be replaced with PyGI
• python-dbus can maybe be replaced by GDBus through PyGI

@adamcik Is there anything I've forgotten?

[jodal]

Porting to PyGI and GStreamer 1.x is still a high priority on our technical roadmap.

Things that need to happen before porting:

• Reintroduce volume mixers as something independent of GStreamer, like it was in Mopidy a long long time ago. GStreamer 1.x does no longer support hardware volume mixing, as in ALSA or similar, only software volume mixing.
• Extract/reimplement our playlist format support to not depend on GStreamer. There's some issues with reimplementing this on top of PyGI/GStreamer 1.x. @adamcik has details for those interested.

Modules to port to PyGI:

• mopidy.audio use GStreamer and GObject
• mopidy.__main__ use GLib
• mopidy.commands use GLib and GObject
• mopidy.listener use GObject
• mopidy.utils.network use GObject
• mopidy.utils.path use GLib

After porting Mopidy proper, we should have a look at Mopidy-MPRIS:

• python-indicate bindings to libindicate can be replaced with PyGI
• python-dbus can maybe be replaced by GDBus through PyGI

@adamcik Is there anything I've forgotten?

[liamw9534]

A question...can pygi and pygobject happily co-exist in the same way as gstreamer-1.0 and gstreamer-0.10?

[liamw9534]

A question...can pygi and pygobject happily co-exist in the same way as gstreamer-1.0 and gstreamer-0.10?

[jodal]

No, we have to switch everything in the same process from pygobject to pygi
in one go.

[jodal]

No, we have to switch everything in the same process from pygobject to pygi
in one go.

[kingosticks]

Can you tick off 'Reintroducing volume mixers'?

[kingosticks]

Can you tick off 'Reintroducing volume mixers'?

[jodal]

@kingosticks Done :-)

[jodal]

@kingosticks Done :-)

[jodal]

Blocked by #961.

[jodal]

Blocked by #961.

[hadess]

@jodal there's nothing stopping you from carrying on using python-dbus. It's one more dependency, but it doesn't hurt.

[hadess]

@jodal there's nothing stopping you from carrying on using python-dbus. It's one more dependency, but it doesn't hurt.

[jodal]

@hadess You're saying that there's no conflict between PyGI and python-dbus in the same process, like there is between PyGI and PyGST?

[jodal]

@hadess You're saying that there's no conflict between PyGI and python-dbus in the same process, like there is between PyGI and PyGST?

[hadess]

@jodal I don't know why there would be. PyGI would be wrapping GDBus in the GIO library, python-dbus wraps dbus-glib. 2 separate implementations of D-Bus.

[hadess]

@jodal I don't know why there would be. PyGI would be wrapping GDBus in the GIO library, python-dbus wraps dbus-glib. 2 separate implementations of D-Bus.

[jodal]

I guess the reason PyGST isn't compatible with PyGI is because PyGST use PyGObject, which PyGI replaces. If python-dbus has nothing to do with GObject, it should be quite independent.

[jodal]

I guess the reason PyGST isn't compatible with PyGI is because PyGST use PyGObject, which PyGI replaces. If python-dbus has nothing to do with GObject, it should be quite independent.

[jodal]

PR #1419 has been merged and develop now runs on GStreamer 1.x :-)

[jodal]

PR #1419 has been merged and develop now runs on GStreamer 1.x :-)

[kingosticks]

Awesome work @adamcik and @jodal!

[kingosticks]

Awesome work @adamcik and @jodal!