New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Switch to GStreamer 1.0 and PyGI #225

Closed
jodal opened this Issue Nov 1, 2012 · 16 comments

Comments

7 participants
@jodal
Member

jodal commented Nov 1, 2012

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:

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

@adamcik

This comment has been minimized.

Show comment
Hide comment
@adamcik

adamcik Oct 28, 2013

Member

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

Member

adamcik commented Oct 28, 2013

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

@txomon

This comment has been minimized.

Show comment
Hide comment
@txomon

txomon Oct 28, 2013

Member

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

Member

txomon commented Oct 28, 2013

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

@jodal

This comment has been minimized.

Show comment
Hide comment
@jodal

jodal Oct 28, 2013

Member

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.

Member

jodal commented Oct 28, 2013

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

This comment has been minimized.

Show comment
Hide comment
@klausenbusk

klausenbusk commented Jun 19, 2014

Any update?

@jodal

This comment has been minimized.

Show comment
Hide comment
@jodal

jodal Jun 19, 2014

Member

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?

Member

jodal commented Jun 19, 2014

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 jodal referenced this issue Jul 12, 2014

Open

Move to Python 3 #779

15 of 19 tasks complete
@liamw9534

This comment has been minimized.

Show comment
Hide comment
@liamw9534

liamw9534 Sep 16, 2014

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

liamw9534 commented Sep 16, 2014

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

@jodal

This comment has been minimized.

Show comment
Hide comment
@jodal

jodal Sep 16, 2014

Member

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

Member

jodal commented Sep 16, 2014

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

@kingosticks

This comment has been minimized.

Show comment
Hide comment
@kingosticks

kingosticks Sep 17, 2014

Member

Can you tick off 'Reintroducing volume mixers'?

Member

kingosticks commented Sep 17, 2014

Can you tick off 'Reintroducing volume mixers'?

@jodal

This comment has been minimized.

Show comment
Hide comment
@jodal

jodal Sep 17, 2014

Member

@kingosticks Done :-)

Member

jodal commented Sep 17, 2014

@kingosticks Done :-)

@jodal jodal modified the milestone: v0.21 - Port to PyGI and GStreamer 1.x Sep 21, 2014

@jodal

This comment has been minimized.

Show comment
Hide comment
@jodal

jodal Feb 5, 2015

Member

Blocked by #961.

Member

jodal commented Feb 5, 2015

Blocked by #961.

@hadess

This comment has been minimized.

Show comment
Hide comment
@hadess

hadess Mar 1, 2015

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

hadess commented Mar 1, 2015

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

@jodal

This comment has been minimized.

Show comment
Hide comment
@jodal

jodal Mar 2, 2015

Member

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

Member

jodal commented Mar 2, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@hadess

hadess Mar 2, 2015

@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 commented Mar 2, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@jodal

jodal Mar 2, 2015

Member

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.

Member

jodal commented Mar 2, 2015

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 jodal self-assigned this Sep 2, 2015

@jodal jodal modified the milestones: v1.3 - PyGI and GStreamer 1.x, v1.2 - Gapless Dec 5, 2015

@jodal jodal added the 2 - Working label Jan 20, 2016

@jodal jodal closed this in #1419 Feb 2, 2016

@jodal

This comment has been minimized.

Show comment
Hide comment
@jodal

jodal Feb 2, 2016

Member

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

Member

jodal commented Feb 2, 2016

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

@kingosticks

This comment has been minimized.

Show comment
Hide comment
@kingosticks

kingosticks Feb 2, 2016

Member

Awesome work @adamcik and @jodal!

Member

kingosticks commented Feb 2, 2016

Awesome work @adamcik and @jodal!

@jodal jodal removed the 2 - Working label Feb 14, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment