OpenSolaris Multimedia Improvements

The multimedia experience in OpenSolaris has improved so greatly since Solaris 10 that it is worth taking a look at the improvements in the latest OpenSolaris releases. Especially for people who have an interest or need for good multimedia support. Solaris 10 shipped with GNOME 2.6, GStreamer 0.8, and only a few GStreamer-based applications, such as totem. Aside from a lack of applications, the user experience on Solaris 10 is further hindered by the fact that most popular non-free media formats are not supported.

After investing a good deal of effort, the experience when using OpenSolaris is a world of difference. OpenSolaris now includes GStreamer 0.10, which supports Fluendo's popular media codecs. You can purchase licensed media codecs from them to play popular formats such as Windows Media (audio and video), MPEG-2, MPEG-4, and MP3 audio. Their MP3 audio plugin is available at no charge, which is nice.

OpenSolaris now supports a more rich set of GStreamer-based multimedia applications, including Songbird and rhythmbox, so it is now possible to organize and play an audio library on OpenSolaris. With codecs from Fluendo, totem is far more useful for playing video files. Fluendo's new media program, elisa, has been added to the upcoming 09.06 release and it provides a rich new interface for interacting with both audio and video.

The OpenSolaris 09.06 release also includes codeina. This program makes it easier to update OpenSolaris so it supports most popular non-free media. For example, if a person tries to play any media with a GStreamer-based program, and if a codec is not available on the system to play that media format, then codeina checks to see if there is a Fluendo plugin available to play it. If so, then codeina steps the user through the process of downloading and installing the needed codec. Once purchased, then the program will just go ahead and play the media file immediately. Of course, that media format will then be supported by all GStreamer-based programs.

I hope that people who try the latest OpenSolaris releases find it to be a much more positive multimedia experience. Feedback is welcome. Let us know on the mailing list if you run into any issues or have comments.

We are not done working yet. Probable the most significant remaining issue with multimedia in OpenSolaris is that it still does not support playing DVD's. Fluendo promises that they will soon make available a DVD playback application, so hopefully that will address this issue in the near future.

Also, the OpenSolaris Desktop team is working to integrate more exciting applications in future OpenSolaris releases. Work is currently underway to integrate OSS into Solaris, though this will not make the 2009.06 release. Once that is done, we are considering making the popular audcaity Audio multitracking editor available. We are also planning to add the coherence Python module to add UPnP support to OpenSolaris and the jokosher audio multitracking program application. So, there are a lot of exciting reasons to look forward in terms of OpenSolaris multimedia support also.


We have been working on a UPnP framework (GUPnP) and applications (gupnp-tools, Rygel and soon GVFS backend) specifically for GNOME over the last few years so it would be shame if someone creating a GNOME-based distro/OS chooses to use \*only\* a non-GNOMEish framework.

Since you'll be supporting multiple different media player applications, I just hope you also take the same approach for UPnP and only use the non-GNOME solutions where there is no GNOME solution available.

Posted by Zeeshan Ali on March 27, 2009 at 11:34 PM CDT #

Please don't use Coherence. Their media server is fundamentally broken (uses 1000 for the root ID instead of 0 like everyone else) and has limited functionality (no metadata/change support). Rygel/GUPnP would be a much better choice.

Posted by iain on March 28, 2009 at 01:41 AM CDT #

By the by, is GUPnP actually a strictly GNOME technology? I thought it was GObject-y, but I didn't know it required GNOME.

Ex., I would wonder if perhaps Amarok or another KDE project could use it without too much hassle library-wise, assuming they were willing to deal with GObject stuff.

Posted by Anonymous Coward on March 28, 2009 at 05:29 AM CDT #

Depends on what do you mean by 'requiring' GNOME? If you mean libraries named \*gnome\* then the answer is: no. gupnp requires glib, libxml2 and libsoup mainly.

Posted by Zeeshan Ali on March 28, 2009 at 08:21 AM CDT #

Some words in advance - I'm the author of Coherence, so this reply has maybe some personal spin. If it is inappropriate please feel free to remove or shorten it.

I read your post in Google reader (saw only the post) and was as merry as a lark - then looked at your blog and read the comments.

Brian: I'm very delighted to see Coherence move into OpenSolaris - I started with a Sparc II and SUNOS 4.something in '91. As I said to Alfred, this triggers some sentimental memories. ;-)

Anonymous: As Coherence is designed to act as a service, it does provide among other things a D-Bus interface that acts as a proxy to the UPnP world. The plugins written for the GNOME apps EOG, Nautilus and Totem make use of that already.

Plugins for KDE apps, e.g. Amarok and a kio-slave will result from a sprint happening early May, kindly sponsored by KDE. Of course the similar GNOME vfs backend will follow stante pede.

Iain: If you mean broken in the term 'it does not work with my software' then you maybe are right. As I tried to explain you here ( what that specific MediaServer backend is doing is within the UPnP spec. Having it working with all devices we got our hands on - PS3, XBox, Nokia phones, Bravias, Samsung TVs, and even seven/eight year old UPnP A/V devices is another good indication.

As you failed to substantiate your change-request with one fact based on the spec I refrained from investing my spare time to solve issues in your - apparently closed-source - project. Btw, not always is the 'millions of flies' approach the proper one.

And yes, this specific MediaServer out of the twenty ( Coherence does provide atm doesn't care about metadata, aka id3-tags or similar, it is not build for that and there are much more appropriate ones.

Zeeshan: Is there an unspoken law that an application running under the GNOME desktop has to use only GNOME related libraries or may not get in touch with anything - how did you call it - "non-GNOMEish". It is probably a silly assumption, haven't heard of a "GNOMEish" DNS server or a "GNOMEish" postfix yet.

I'm a GNOME user myself - for years now. I've written Coherence UPnP plugins for Rhythmbox, Totem, Nautilus and now EOG. Calling Coherence a "non-GNOMEish" framework has some very irritating tone.

Now replicating all the work that was done on and with Coherence is your decision and perfectly valid, this is a free software world after all.
Jumping up and down and waving your flag whenever somebody talks about Coherence is fine with me too.

But speaking in this way about the work of all the contributors, the other developers and myself is very disrespectful.

Posted by Frank Scholz on March 29, 2009 at 07:35 AM CDT #

I'm not an opensolaris user but what I can say is... Coherence is a fantastic tool and at least as an heavy UPNP user (denon amp' + ps3 + tv + nokia + noxon), it just offered me new uses cases to my devices. I'm glad to see one more OS making that choice.

Posted by Erwan Velu on March 29, 2009 at 08:37 PM CDT #

> Is there an unspoken law that an application
> running under the GNOME desktop has to use only
> GNOME related libraries or may not get in touch
> with anything

Not really but if there is a library specically designed for GNOME, not using it only because one doesn't want to depend on glib is not a very GNOME'ish thing to do.

Also, after two years of when you told me that, I still don't understand why you have problems depending on glib if you have no problem depending on gstreamer, which also depends on glib. Would be nice if you can explain that.

> - how did you call it -
> "non-GNOMEish". It is probably a silly
> assumption, haven't heard of a "GNOMEish" DNS
> server or a "GNOMEish" postfix yet.

That is because they are not part of desktop. UPnP on the other hand needs to be integrated as part of the desktop itself. E.g Per-user-per-login MediaServer (which Rygel is supposed to be) and desktop apps needing to talk to UPnP world directly make UPnP case quite different from the examples you mentioned.

If we follow your logic, then all KDE libraries and apps can be concidered part of GNOME, no?

> I'm a GNOME user myself - for years now. I've
> written Coherence UPnP plugins for Rhythmbox,
> Totem, Nautilus and now EOG. Calling Coherence
> a "non-GNOMEish" framework has some very
> irritating tone.

Dude, chill! Facts are facts. You don't write a framework for GNOME in python. In order to ensure applications to be written in any language of the author's choice, there \*is\* an unspoken law in GNOME world to write the libraries/frameworks in C.

Now I know and understand your reasons to do everything in python but the fact remains that this makes your framework not so fitting in the GNOME world.

> Now replicating all the work that was done on
> and with Coherence is your decision and
> perfectly valid, this is a free software world
> after all.

Now that is extremely harsh thing to say. Who replicated gupnp-tools and network light without even admitting it? At least I have the courage to admit that I have learned from your implementation. Something I do each time someone asks me about my opinion on coherence.

If you recall I had been very much interested in your project even before I knew of gupnp. The only reason I had to "replicate" was that you insisted on keeping your whole implementation in python and that didn't make your software feasible for Maemo (and GNOME Mobile in general) at all. Since I had to go for GUPnP for that anyways, it was only natural that I went for the same solution for the destkop as well since it fits there perfectly too, being a gobject-based, well documented, nicely-divided and well tested set of libraries.

The decision to go for GUPnP rather than your framework was purely based on pragmatic reasons, not because of me wanting to have my own implementation. Keep in mind that I don't own GUPnP, in fact I don't even have write access to the main repositories so you can imagine how "just wanting to replicate" for the sake of doing so, can hardly be one of my motives.

In the end, please notice that I did not ask for anything that goes against your project, I only asked for mutual co-existance. While providing arguments for that if I mentioned some facts that are hard for you to swallow, I am sorry for that.

You implemenation is really great on it's own, just that it does not fit as well into the GNOME (especially mobile) world as much as our implementation does. I suggest you get over it.

Posted by Zeeshan Ali on March 30, 2009 at 10:46 AM CDT #

I agree with Zeeshan here. The GNOME development platform should include a UPnP stack and GUPnP seems to be the best choice for this. Simply because it does not make sense to have fundamental parts of the development platform written in Python. Not everyone wants to code in Python, so we need to make sure that GNOME application developers have the choice. And that means having the core stack written in C with bindings for all major languages.

GUPnP is really very nice. Easy to use, flexible and fast. At work we use it with much success for a commercial product that runs on embedded hardware. I don't think we could afford to use Python for this.

Posted by Sven Neumann on March 31, 2009 at 12:14 AM CDT #

Post a Comment:
Comments are closed for this entry.



« June 2016