Tag Archives: rygel

dLeyna updates and general project things

English, Gnome, Programmieren, Software, , , , , , ,

I have too many projects. That’s why I also picked up dLeyna which was laying around looking a bit unloved, smacked fixes, GUPnP 1.2 and meson support on top and made new releases. They are available at

  • https://github.com/phako/dleyna-core/archive/refs/tags/v0.7.0.tar.gz
  • https://github.com/phako/dleyna-connector-dbus/archive/refs/tags/v0.4.0.tar.gz
  • https://github.com/phako/dleyna-server/archive/refs/tags/v0.7.0.tar.gz
  • https://github.com/phako/dleyna-renderer/archive/refs/tags/v0.7.0.tar.gz

Furthermore I have filed an issue on upstream’s dLeyna-core component asking for the project to be transferred to GNOME infrastructure officially (https://github.com/intel/dleyna-core/issues/55).

As for all the other things I do. I was trying to write many versions of this blog post and each one sounded like an apology, which sounded wrong. Ever since I changed jobs in 2018 I’m much more involved in coding during my work-time again and that seems to suck my “mental code reservoir” dry, meaning I have very little motivation to spend much time on designing and adding features, limiting most of the work on Rygel, GUPnP and Shotwell to the bare minimum. And I don’t know how and when this might change.

More updates

Uncategorized, , , , ,

SystemD conf 2016

I will be giving a presentation at this year’s systemd conf in Berlin. If you ever wondered what the hell I am doing during the day, there’s your chance to get a glimpse 🙂

GUPnP going 1.0!

Parts of GUPnP (that is its core, GSSDP and GUPnP itself) will see a 1.0 release together with the next GNOME release. They are quite stable API-wise and functionality-wise now and I think it’s time to give them a proper blessing for that.
After that, master will become more unstable in regards of API, as there are some long-standing bugs and fixes that need an API change as well as new features to be added, such as proper IPv6 support, support for more recent versions of the UPnP standard (UDA 1.1, UDA 2.0), a more GIO-like async API,…

Rygel

We’ve been digging up some annoying age-old bugs or regressions deep down in Rygel for some corner-cases (Did you know that renderer unmute was broken since 2013?)

Shotwell

Some more usability fixes on their way, but the big roadblock of RAW import performance is still proving to be quite annoying. Bit like a hydra, really. You cut of one RAW developer, three new seem to disappear.

Project Lazarus: GtkTerm

I took GtkTerm and poked a bit at its source, mainly for two reasons

  • Dry-run some GTK modernisation that will be necessary in Shotwell as well (GAction etc.)
  • It’s the least worst (sic) of the graphical serial terminals I tried. At least it seems to cope way better with odd USB <-> Serial adapters than t rest of the bunch
  • I use it

Ok, that’s three reasons.
If you want to have a look, head over to its repository at https://github.com/phako/gtkterm

Rygel/Shotwell/GUADEC

Uncategorized, , , , ,
  • Rygel is currently mainly receiving maintenance things because reason. This is hopefully changing soonish
  • I picked up Shotwell as maintainer and things are coming along nicely, though its architecture sometimes makes changes that sound really easy very hard (e.g. certain import performance improvements). Most annoying part, though, is that the merging of the awesome map feature is somewhat affected by the recent woes regarding MapQuest’s tile server
  • I’m going to be at GUADEC during its core days

That’s all for now.

Things 'n' stuff

Uncategorized, , , ,

Long time no blog. Sorry about that. Things have gotten a bit busy since I changed jobs in Nov 2013, moving along to the crazy and sometimes insane world of automotive in general and IVI in special. Due to that and a rather unpleasant commute, things in Rygel land have gotten a tad more silent then I hoped, not revolutionary, maybe not even evolutionary. For example, there’s still no ACL support as I promised way back on GNOME.Asia 2013.
I will have to skip FOSDEM this year for several reasons, sorry about that.
For Rygel, I hope to finish the integration of (most of) Cablelab’s changes for their CVP-2 work as they will allow nice and long requested features such as pre-transcoding or transcode caching, server-side trickmodes, simple device-dependent resource reorder (for devices that are too stupid to pick the proper resource). Unfortunately I have found a rather large feature regression with upload that seems to turn out to be somewhat nasty to fix.
That’s all for now.

Raspberries and Rygel

Uncategorized, , , , , ,

First I have to apologize for the delay. I initially announced this in my GNOME.Asia talk almost two months ago.

TL;DR:

Raspbian and hardware-accelerated video decoding in Rygel without X. Follow brief instructions on http://rygel-project.org/raspbian/

What’s this problem?

There are already several solutions in the wild that combine Rygel and the Rasbperry Pi, be it Guacamayo or stock Raspbian. While Guacamayo provides easy server and audio renderer images, none of the existing solutions provide a video renderer.
Why’s that? Well, the RPi is (intentionally) slightly underpowered to do video decoding on the CPU. Howerver, it supports video decoding in hardware.
The issue here is that Raspbian is based on wheezy which only comes with GStreamer 0.10 while the support for hardware-based video decoding on the RPi in gstreamer-omx was only added recently to GStreamer 1.0.x. And since this is wheezy, the Rygel package that comes with it is too old to use GStreamer 1.0.

So let’s just grab the packages from sid armhf, should be working, no?

No it doesn’t. Rasbpian is basically a recompilation of Debian for ARMv5 with hard float ABI, while Debian itself is using ARMv7. So we can’t just copy packages.

So?

Well the good news is that we don’t need to do all the heavy recompiling of GStreamer. Someone already did that for us. This work is available at http://vontaene.de/raspbian-updates/ (from the raspberrypi.org forum).

And what exactly are you doing now?

We provide a Debian repository with Rygel’s packages backported to Raspbian. That’s a bit boring, you say? Indeed. This is only the beginning. There will also be a set of instructions to convert a Rasbian installation into a hardware-accelerated DLNA renderer. The first step to this is a meta-package called raspbian-dlna-renderer which depends on all the other important packages necessary for a complete environment.

What’s working right now?

First, add the following repositories to your /etc/apt/sources.list

deb http://rygel-project.org/raspbian wheezy/
deb-src http://rygel-project.org/raspbian wheezy/
deb http://vontaene.de/raspbian-updates/ . main

The packages on rygel-project.org are signed with my private GPG key, key id 7696ECBF. Then run apt-get update && apt-get install raspbian-dlna-renderer to get all updated and necessary packages.
I’ve modified /boot/cmdline.txt to get a screen that is as empty as possible by adding silent and logo.nologo to the kernel parameters.
You can then launch Rygel as user and play files on the RPi using Helium, gupnp-av-cp from GUPnP Tools or any other DLNA control point.

What’s next?

A next version of the meta-package will probably add auto-starting Rygel as a system service – Maybe we’ll even provide a ready-to-go image…

GNOME.Asia 2013

Uncategorized, , , , ,

DSCF0524_RAF_embedded
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.
sponsored-badge-simple

Rygel progress in current master

Uncategorized, , , , , ,

It’s been a while since I last blogged about Rygel. Many things have happened since, mainly in features and documentation.

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

A common mistake in UPnP

Uncategorized, , , ,

We get a lot of reports of UPnP AV clients not working properly with Rygel. It either isn’t seen by the client at all or does not show any content.
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.

Rygel split-up

Uncategorized, , , , ,

Following up on Murray’s “Rygel for a DLNA Player” proposal, I’ve made some of the suggested changes listed there which are now in master. These two new libraries have been added

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