Tag Archives: UPnP

dLeyna has moved

Happy to announce that dLeyna has moved to its new home, GNOME World: https://gitlab.gnome.org/World/dLeyna

The four previously separated repositories core, connector-dbus, renderer and server have been combined into this single repository. I was amongst those who promoted for the split, but since then the conditions have changed and it is far easier to maintain in an all-in-one repository now. Most files should have kept history.

The upcoming dLeyna 0.8 will be the first unified release.

The time of the year…

Springtime is releasetime!
Monday saw a couple of new releases:

Shotwell

Shotwell 0.26.0 “Aachen” was released. No “grand” new features, more slashing of papercuts and internal reworks. I removed a big chunk of deprecated functions from it, with more to come for 0.28 on our way to GTK+4 and laid the groundworks for better integration into desktop online account systems such as UOA and GOA.
GExiv2 also received a bugfix release with its main highlight of proper documentation generation.
 

Rygel

In Rygel, things are more quiet. Version 0.34.0 moved some helpful classes for configuration handling to librygel-core and a couple of bugs were fixed. GSSDP and GUPnP also saw a small bugfix release.

More updates

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

  • 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

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

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

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

DLNA, client side

While we were busy fixing the server and rendering side of DLNA with Rygel, the guys at Intel OTC are fixing the Client side of DLNA with something called dLeyna, a nice set of APIs to access and maipulate UPnP-AV and DLNA servers / renderers (such as Rygel, of course), so you can easily add DLNA support to your applications, including the obvious server browsing and render remote control, but also the more non-obvious like media pushing, synchronization, server-side playlists. They already prepared a cool set of demos (for example a Firefox extension to send images from your browser to your TV).
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.