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 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.

I think that the interface might be sitting at the wrong level. Why do you need to poke at the playbin element directly? (apart from “it’s how it got implemented”). We already have a number of “controller” type plugins, and adding the necessary infrastructure to support one more certainly wouldn’t be frowned upon.

File a bug against Totem with your first pass patch, and we can discuss it there. Looking forward to getting better UPnP support in Totem with Korva as well. Totem to Totem streaming!