A bit late for the “I’m back from this year’s GNOME.Asia” post, but well. This was the fist GNOME.Asia event I attended and even my first time in asia and it was a very interesting experience that needs repeating. It was nice to meet all those people from around this part of the world who never make it to the european conference and I was particularly pleased to meet Jiro who enabled i18n support in the GUPnP tools and to learn about the <Super>M shortcut to get the message bar. Unfortunately I couldn’t join the city tour on Sunday since I was already heading back to London then.

I did a talk on DLNA (who would have guessed that) in GNOME and some of the things that might come: Slides of the talk. I’m afraid the blog post on setting up a hardware-accelerated DLNA renderer on the Raspberry Pi that I announced during the talk is still not written, sorry about that.

A big thanks to the the cheerful local team, the GNOME.Asia people and of course the sponsors who made all this possible and thanks to the GNOME foundation for sponsoring my attendence.

So why is this better than using GUPnP for this? Let me show you some examples.

Controlling a renderer

Not much code to see here, you get the usual suspects of player control functions such as start, stop, etc. as well as methods to query device’s capabilities as there are a lot of optional things on UPnP devices.

Uploading

Well, say you want to upload a file to a server. The code how to do that in GUPnP is  available in gupnp-tools and it’s not exactly pretty. With dLeyna, on the other hand, it’s a fewliner:

#!/usr/bin/env python
import sys
import mediaconsole as mc
 
u = mc.UPNP()
d = u.server_from_udn(sys.argv[1])
d.upload_to_any(sys.argv[2], sys.argv[3])

In DLNA land, this is called “+UP+”.

Playing a file

Or you want to show some media file you got on your device or app on a DLNA-capable TV? Korva is showing how you can do that with plain GUPnP, again with a lots of lines of code. dLeyna providing a nice and clean solution:

#!/usr/bin/env python
import sys
import rendererconosle as rc
m = rc.Manager()
d = m.renderer_from_udn(sys.argv[1])
uri = d.host_file(sys.argv[2])
d.stop()
d.open_uri(uri)
d.play()

And this is called “+PU+” in DLNA land.

Behind the scenes, this is all GUPnP of course. Currently it consists of two DBus services, dleyna-renderer-service and dleyna-server-service, although other IPC mechanisms are on its way. What happens is that that these two services scan the network for available devices and making them available through a set of DBus interfaces, relieving you from the need of searching for devices yourself (and with that providing a device cache, relieving the network from UDP packet bursts), introspecting the devices for supported capabilities and methods and so on.

If you execute the push script from above you get a python wrapper for the com.intel.dLeynaRenderer.Manager DBus interface, which is then locally looking for the DBus path matching the given UPnP UDN and returning a python object implementing the com.intel.dLeynaRenderer.PushHost and com.intel.dLeynaRenderer.RendererDevice interfaces.

Then we temporarily host the file given on the command-line on dLeyna’s internal HTTP server, stopping the currently running playback (Which translates to RenderingControl:Stop SOAP call), send the URI to the server (RenderingControl:SetAVTransportURI) and last but not least start the playback (RenderingControl:Play) which in the end starts the HTTP streaming from dleyna’s internal HTTP server to (Rygel’s) renderer.

And it doesn’t stop at the application level, there’s even integration with HTML5 through cloudeebus and cloud-dLeyna.

As a sidenote: You might ask how that relates to Grilo’s UPnP-AV support or Korva. This is a very valid question. Grilo and Korva are doing very specific tasks while dLeyna aims to be a more complete SDK. It should be quite easy, for example, to port Grilo’s UPnP-AV suppport to dLeyna.

Features

• Exchangeable media engines: We’ve loosened the dependency on GStreamer a bit. While it is still our first-class transcoding and general media handling library, it is now possible to substitute it with other media processing libraries. A simple example is included in the source.
• Change tracking. This is a feature introduced in the UPnP content directory specification version 3. It allows clients to, well, track the changes that happen on the server in detail for synchronization purposes. It’s implemented in the framework and as a demonstration in the MediaExport plug-in.
• GStreamer 1.0 support. As the rest of GNOME, we transitioned to GStreamer 1.0.
• Playlist support. Rygel now generates playlists for containers on-the-fly and the renderer framework supports automatic playback of them. The only format that’s supported currently is one of the two formats defined by DLNA, DIDL_S, which is just the same format that is used by UPnP AV to describe the media content on a server.
• Playspeed support. A renderer now can announce that it supports different speeds and directions than normal forward playback.

API

There was another split-up into a renderer framework library and a specific implementation of a renderer using GStreamer which again may be used in your own programs. This is mainly due to the aforementioned change in media backend flexibility.

Otherwise we’re working on making the API easier to use from C and other languages through introspection.

Documentation

There’s been a lot of effort into extending our sparse documentation. It is currently concentrating on the API side of things but will be extended to a higher level as well soon.

Misc

• There is an example now that implements a DLNA renderer which is running in full-screen
• There are several examples for the most common init systems to run Rygel as a system service if wanted
• A load of bugfixes

Update: This post only applies to the package on 12.10 and will be fixed when Ubuntu resyncs Rygel from Debian.

It seems that the Rygel package is missing some important files which renders the transcoding non-functional.

A work-around is to download the files from http://git.gnome.org/browse/rygel/tree/data/presets
and drop them into /usr/share/rygel/presets.

Improved seeking

ackDuration val="àý]Üž"/><CurrentMediaDuration val="àý

Duration is supposed to be a string representation of an integer. Well done, guys m(

The reason is usually the same. People are not following the specs. Rygel seems to be one of the few UPnP-AV/DLNA server out there that implements a higher version of the UPnP-AV specification than :1. A lot of clients are explicitly testing for this version, ignoring higher versions although the UPnP standard states that higher version services need to be backward-compatible. (cf. UDA 1.1, section 1.2.2, last paragraph on page 10). Of course we can work around that – and we do, but the list of exceptions is getting longer and longer and to be honest I’m starting to get really annoyed of those fixes.

I expect that there will be more and more devices with higher versions now that DLNA has added features that require higher versions of the specification than :1. So pretty please get your clients fixed. And if you don’t want to, then don’t make it extra complicated to work around your bug. But really, fix it.

And please have a working support email address so I can complain directly. About every client author I tried to contact has bounced – and the rest ignored me.

• It fixes 100% CPU usage when encountered by DLNA clients that issue a massive amount of seek requests (GNOME Bug#662125)
• Fixes the issue with XBox 360 that showed songs up to 5 times (GNOME Bug#664184)
• A small memory leak when streaming transcoded audio

• librygel-core: This has been a long-standing TODO item. It was necessary to allow in-process use of the DLNA and UPnP knowledge coded in Rygel, allowing the creation of librygel-renderer (see below). On top of this there are other benefits
  • It will allow a Rygel version running on Windows without ugly libtool hacks for the plug-ins.
  • It simplifies the reuse of other parts of Rygel’s code, such as the transcoding HTTP server, in programs like Korva.
• the new librygel-renderer: In essence this is the playbin plugin with a bit of API on top that simplifies the code necessary to create a renderer. It offers either a playbin element you can use in your code or wraps around an existing playbin.

In future we can extend this family of libraries by “librygel-browse” for remote content access and “librygel-control” for remote control.

To demonstrate librygel-renderer’s capabilities of converting an arbitrary media player based on GStreamer’s GstPlaybin2 into a proper UPnP/DLNA renderer, I have added librygel-renderer support to Totem. You can see the result in the following demo:

The first part of the video (using Sintel) shows how changes in local file playback are being reflected on the UPnP side. In the second part, I set a remote video (Big Buck Bunny) and control totem solely via UPnP, where play, pause, stop, controlling volume, seeking and getting the current playback position is working quite well.

This simple conversion is not a complete DLNA Player. It would need UPnP/DLNA server browsing capabilities for this, as stated in the proposal (In general. Totem can access these servers via its Grilo plug-in).

Of course, with Totem being a complex, mature piece of software, some things don’t work yet:

• Volume changes in Totem aren’t reflected via UPnP
• It is not possible to initiate a remote play-back until Totem has an item in its playlist
• The announced media format support is nowhere near what Totem actually supports

Still, getting an UPnP/DLNA-compatible (and actually close to certifiable) renderer in three lines of code is impressive, don’t you think?

There’s one draw-back that I realized while implementing this. My initial idea to sit on top of a GStreamer playbin2 might be flawed for already existing and mature software such as Totem. There might be much more code-paths dealing with control that happen outside of a playbin. We have an alternative for that as well and that would be implementing one of Rygel’s interfaces by the consuming party. The UPnP and DLNA compatibility that is already in the current code would need to be transferred to this, which is, of course, more work than just attaching to a playbin.

Why should I prefer this above the already available MPRIS Rygel plug-in? There might be several reasons.

• You don’t want a whole separate Rygel process running just for adding UPnP renderer capabilities to your media player.
• You aim for some kind of UPnP or DLNA certification – The additional layer of indirection can make that really hard while the presented approach is nearly ready.

So are we going to abandon Rygel’s MPRIS renderer plugin now? No. Because we can’t expect every media player in the world a) use GStreamer and b) want to link against Rygel. MPRIS gives us a quick, ready-made access to a vast amount of players out there and the compatibility it offers is (most of the time) just enough for casual home use.