It’s been a while since I last blogged about Rygel. Many things have happened since, mainly in features and documentation.
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.
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.
There’s been a lot of effort into extending our sparse documentation. It is currently concentrating on the APIsideofthings but will be extended to a higher level as well soon.
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
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
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.
Ever since the announcement of the N9’s DLNA support people were looking for a feature called DLNA +PU+ which allows you to send media files to e.g. DLNA-capable TVs without enabling content sharing on your device, giving you a really fine-grained control about what and where to share to.
PushUp is a small utility that hooks into the N9’s sharing framework and allows to you push an image or a video to your TV just like you would with Bluetooth or NFC. Get it on this site (or later through the Nokia Store).
It is an offspring of my Korva project, a D-Bus specification and its implementation for media pushing. While still work-in-progress, it’s already fully functional.
Edit: I had to update the package because the icon was missing and cancelling the device selector was broken.
Edit2: Updated again since it was broken on PR < 1.2.
It looks like the PR1.2 update for the N9 is starting to get rolled out now, so your favourite MediaServer implementation will reach your phone soon.
A short hint if you’re eager to try it and you don’t see any files shared: For complicated and mostly non-technical reasons the device needs to assign so-called DLNA media profiles to images and media files. To start this, the device needs to go into idle mode once, so just let it rest for a while and all media created on the device should be available after that. This is a one-shot thing after the update, any files added afterwards will be fine.
If you try to test GStreamer 0.11 there’s this nice gst-uninstalled script; somehow that didn’t work for me as soon as I tried to use more non-gst interdependent libraries so I opted to use jhbuild. Luckily that’s quite easy with the stock gnome jhbuild moduleset.
To do that, I created a new .jhbuildrc-gst-0.11 with the following modifications. skip and modules can of course be adjusted to own needs.
I know I have been quite silent about Rygel in general lately because I was quite busy with my day job. Since Zeeshan left Nokia after the MeeGo turmoil I took over his task of bringing Rygel in good shape to form the basis for Harmattan’s DLNA functionality.
These efforts, started long ago by Zeeshan, are finally coming to a close and entering the wild. With the release of PR1.2 beta for the N950, the alert reader might have spotted the release note entry “Media sharing with DLNA compatible devices”. You can probably guess what that’s powered by 😉
One of the goals that we’d set ourselves has already been reached. The device is UPnP certified. The DLNA compatibility is in really good shape as well.
That is one of the reasons why the upstream Rygel development looks kind of stalled. The other one is that we’ve been focusing on ironing out the rough edges with emphasis on stability. Naturally, all of the patches that resulted here have been upstreamed, either to Rygel, GUPnP or libsoup.
On the device
So what’s on the device? A more or less pristine upstream snapshot taken several commits after 0.11.3 with later patches cherry-picked and some minor adjustments to adapt ourselves to the environment, like different device details and icons.
What can it do?
It implements a M-DMS, a mobile media server, enabling you to share the media content of your phone in your home network.
In addition to the rather useless mandatory media formats defined by DLNA we have decided to include a LPCM transcoder and the necessary profiles to share all the videos and images you’re going to take or already have taken on the device.
The server runs in a strict sharing mode where only media files that conform to one of the supported DLNA profiles are shared. This is configurable and we plan to release a “tweaking app” later to help the average end user to fine-tune and undo some of the limitations that had to be done due to the DLNA guidelines.
So, to all that already can, enjoy Rygel on your mobile phone.
Looks like we have found and fixed the recent issues in the PulseAudio MediaServer2 implementation that led to weird behavior when trying to browse the PA server; it is available in PulseAudio master.
So after applying this, streaming from PA should be possible again if your client natively supports LPCM. If not, then most likely not. There seems to be an issue in setting up the transcoding (this includes the XBox e.g.)