Rygel currently provides a UPnP and DLNA Server, serving media to DLNA Players and Renderers such as TVs, smartphones, and speakers. It has achieved UPnP and DLNA Certification as a server in the Nokia N9 smartphone, thanks to work by Openismus and others.

But Rygel also already has some mature support for software that wishes to be a DLNA Player. With some work, this could let a GStreamer-based media player become a DLNA Player, able to play video, music, or pictures from DLNA Servers. We believe it could achieve DLNA certification as a Player. As a side-effect, this would add some (DLNA standardized) remote-control functionality to the media player.

This is work that Openismus would like to do for a customer. In fact, we’ve done some of it already, but we haven’t published it yet. The rest of this post describes what we’d like to do. UPDATE: Some of this is now done.

DLNA Player

A DLNA Player is a device that can access media files on a DLNA server and plays them back.

Browsing

A DLNA Player must implement a DLNA Controller (Known as a Control Point in UPnP terminology) that implements the “Browse” operation, to request data from the DLNA server, and must be able to play media in its own UI.

The user interface could either:

• Display the raw structure as retrieved from the server, allowing direct browsing, or
• Collect all the data from the server beforehand (maybe caching it), to present it like other media collections, for instance with searching, thumbnails, etc.

As inspiration, we can use code from the Helium (a UPnP control point) and Korva (a daemon used by PushUp) open source programs, We have tested both against the DLNA tool and they seem to pass quite well.

Playing

DLNA Servers provide media via HTTP streaming, so any GStreamer-based player can easily play that content via the souphttpsrc element. Rygel’s own (unfinished) Renderer (its playbin plugin – see below) uses this souphttpsrc element. (Note that souphttpsrc does not use SOAP, and use of SOAP is not required for basic playing. souphttpsrc’s name is based on its use of libsoup, which once also did SOAP, but now does not.)

DLNA Servers may additionally support RTSP as an alternative to HTTP, but GStreamer also has support for RTSP. Most DLNA Servers only support HTTP.

Codecs

The Player must support some standard media codecs according to the DLNA Profile that it claims to support:

The minimum for “Home networked device” (meaning it is usually connected via Ethernet, is rather stationary and is powerful):

• LPCM
• JPEG_SM (meaning resolution <= 640×480)
• A variety of MPEG2 profiles. There are three regions, North America, Europe and Japan, each of which requires a different set. A device can have support for multiple regions.

The minimum for “Mobile networked device” (meaning it is usually connected via Wi-Fi, can be carried around and is less powerful):

• MP3 and AAC_320 either without any container (ADTS framing) or in a 3GP or MP4 container.
• JPEG_SM (meaning resolution <= 640×480)
• AVC_MP4_BL_CIF15_AAC_520, that’s baseline H.264 video, 320×288, 15 FPS with AAC audio in an MP4 container.

Most of the formats (MP3, MPEG2, AAC, H.264) have their own license and patent issues. MP3 could be covered by using the Fluendo plugin while MPEG2 and H.264 are usually covered by using a DSP-based implementation. Commercial software decoders without dubious copyright for MPEG2, H.264 and AAC used to be available e.g. from MainConcept, though of course not as GStreamer elements. Device vendors still need to make an agreement with the MPEG-LA if they are not already in that patent pool, depending on the predicted sales volume. The MPEG-LA usually doesn’t care what implementation is used, we believe.

DSP integration in GStreamer already exists for SOCs made by TI (The OMAP/DaVinci family). For TI there are two alternative techniques:

• dspbridge and gst-dsp.
  • This is mostly maintained and used by Nokia (by Felipe Contreras), though we can assume that Nokia has now abandoned it.
  • We have heard that this doesn’t work with recent 3.2 kernels, though that would need to be confirmed.
• The newer dsplink with gstreamer-ti.
  • gstreamer-ti supports more codecs anyway.

Instead of relying on vendor-specific implementations, the preferred way seems to be via OpenMAX. GStreamer elements for that are included in upstream and freely available.

The MainConcept software decoders basically have a function that takes a blob of encoded data and spits out a blob of decoded data. It should be relatively easy to get a basic GStreamer element going. A Demo SDK is only available upon request and after signing an NDA. As with most commercial software, getting bugs fixed in them is next to impossible.

Possible Architecture: Player/Renderer/Controller

A DLNA Player does not need to be a DLNA Renderer (which could be controlled by another Controller, such as a remote control, for instance to pause or to change color settings). However, we think it would be wise to implement DLNA Renderer, despite the extra work, because:

• A DLNA Renderer can be tested automatically without user intervention, meaning that more code and functionality would be tested more often and more accurately.
• A DLNA Renderer can be controlled by a DLNA remote control device.
• Code reuse: Implementing Controller functionality to control our own Renderer via local standard UPnP/DLNA messages, instead of custom in-process code, would allow the implementation to be reused in a DLNA remote control device.

These are the DLNA Renderer services which could be used by a remote control DLNA Controller device:

• ConnectionManager: List supported media formats and provide connection control for devices that support multiple parallel connections (e.g. rendering several media files at the same time; rarely implemented). Note that this does NOT include ACL: http://upnp.org/specs/av/UPnP-av-MediaServer-v1-Device.pdf
• RenderingControl. Control volume, brightness, hue etc.: http://upnp.org/specs/av/UPnP-av-RenderingControl-v1-Service.pdf
• AVTransport: Set Media file, control playback (start/stop/pause/record): http://upnp.org/specs/av/UPnP-av-AVTransport-v1-Service.pdf

Rygel already provides a simple Renderer via its “playbin” plugin, which uses GStreamer’s souphttpsrc and playbin2 elements. However, this currently just displays directly to the screen and runs out of process, so it would need to be refactored as a shared library (the code is already LGPL). This would avoid interprocess communication of media data, and allow direct manipulation of the playbin2 GStreamer element, for instance, to tell the playbin2 to use the media player’s own display sink.

This already provides the Renderer services needed by a Controller (see above). However, some work would be required to achieve certification.

UPnP Certification

The “Player” device class does not exist yet in UPnP. However, since February 2012 a DLNA Media Player (DMP) must have an UPnP certification. We are not sure yet exactly which UPnP certification is required but we assume that it is a UPNP-AV Controller certification with only the Server-side interaction tested. This would need clarification with DLNA.

UPnP certification requires use of the UPnP Certification Test Tool, which runs on Windows and is available to Basic UPnP members, though you need to be a UPnP Implementor member to go through the Certification process.

During UPnP certification the device must support Link-Local address generation. This is only necessary for the sake of the UPnP certification and does not need to be present in the actual device. NetworkManager seems to do either DHCP or Link-Local. For example to achieve this on the N9, we set a special gconf key to enable Auto IP fall-back only for testing. The production devices can’t do Auto-IP out-of-the box. This is of course not possible with DLNA as you have to send a production device, but one can request a “Auto-IP voucher” during device registration which removes the requirement. For a pure software certification this does not apply of course.

The Player’s interaction with a DLNA Server would be based on GUPnP, whose basic UPnP technologies, such as discovery, eventing, and message syntax have already been well tested during the Nokia N9’s DLNA Server development and certification.

As mentioned above, we have also informally tested Helium’s control point implementation against UPnP. The test run shows a pass in the basic plumbing and for all mandatory operations from the control point requirement documents (connection manager, content directory, control and AV transport).

UPnP Testing Procedure

UPnP testing is done in-house. A log file from the test tool together with a packet capture of the test run is then sent to the UPnP forum via its website. The UPnP forum checks the result and awards a certificate. Certification is usually bound to a device and free of charge. See http://upnp.org/sdcps-and-certification/certification/how-to-certify-a-device/

The test tool does its testing partly automatically, if the Player also supports Renderer (see above), and partly by requesting user interaction, either to use the Player’s UI, or to plug and unplug the network cable.

UPnP Test Results for the Rygel Renderer plugin

We have already informally tested the current version of Rygel’s Renderer (playbin) plugin, which we recommend that we use (see above).

The full test results are probably confidential according to the UPnP software license, so we probably cannot share them. However, we will summarize the results here:

The test result shows that we pass everything in the basic UPnP plumbing: discovery, eventing, syntax. We also pass every test that was marked as supported by our implementation. This includes all mandatory operations as defined in the relevant UPnP specification documents as well as the optional “Pause” operation.

DLNA Certification

Special attention must be paid to the required media formats. Most of them are proprietary and might need additional licenses. Those formats are:

• Minimum for “Home networked device” (means it’s usually connected via Ethernet, rather stationary and powerful)
  • LPCM
  • JPEG_SM (meaning resolution <= 640×480)
  • A variety of MPEG2 profiles. There are three regions, North America, Europe and Japan, each of which requires a different set. A device can have support for multiple regions.
• Minimum for “Mobile networked device” (means it’s usually connected via Wi-Fi, can be carried around and less powerful)
  • MP3 and AAC_320 either without any container (ADTS framing) or in a 3GP or MP4 container.
  • JPEG_SM (meaning resolution <= 640×480)
  • AVC_MP4_BL_CIF15_AAC_520, that’s baseline H.264 video, 320×288, 15 FPS with AAC audio in an MP4 container.

The main issue will be with the HTTP implementation of whatever displays the media. For instance, if GStreamer is used, it needs to include the fix for Bug #676020.

DLNA Testing Procedure

DLNA Certification requires use of the DLNA testing software, which runs on Windows. Any company would need to become at least a DLNA Contributor member. The membership includes access to the DLNA guidelines (a hard copy can be bought by everyone for 500 USD).

The testing software does its testing partly automatically, if the Player also supports Renderer (see above), and partly by requesting user interaction, either to use the Player’s UI, or to plug and unplug the network cable.

DLNA testing is a two-step process. First a test run is conducted in-house. The device is registered and the results from this test are then sent to the DLNA which check if it’s “worthy” for certification. Then the device needs to be sent to a certification laboratory where the same tests are done according with the registration.

UPnP certification is a pre-requirement for DLNA certification. DLNA certification is usually bound to a device, but it’s possible to certify software. The only certified software so far is a controller, as far as we know.

DLNA Plugfests

In addition to testing against the certification software, DLNA quarterly offers so-called plug-fests, where members can test their implementations or devices against the devices of other members. Attendance to these is not free, of course, but the experience with the N9 showed that it really helps to sort out interoperability problems early in the process. Fees are usually 400 USD person and 500 USD early bird fee, 1000 USD normal fee per device class, not including accommodation. A special rate for a hotel near to the venue is usually available.

DLNA Test Results for the Rygel Renderer plugin

We have already informally tested the current version of Rygel’s Renderer (playbin) plugin, which we recommend that we use (see above).

The full test results are confidential according to the DLNA software license, so we cannot share them, but we can summarize them here.

Our initial test run shows two problems that prevent a proper test run as they shadow most of the real problems:

• The default implementation does not claim support for any DLNA-approved media format.
• There is a problem with the meta-data the renderer sends to the controller (in this case the controller is the test tool). This seems to be a problem with XML escaping of the state variables.

When we work around these problems temporarily, the result shows that we pass almost everything related to basic UPnP/DLNA functionality. This is hardly surprising because we have achieved certification for the Server functionality already, which shares code. The remaining bugs mostly deal with inconsistencies between the evented state variables and the values returned in explicit queries, and a missing function call that is optional in UPnP but apparently required in DLNA.

Summary

Openismus can do this. We can even get it through certification. Clearly we know how.

Please contact us if you’d like us to do this work for your company. We can quickly provide a full proposal with tasks and milestones.