DLNA Certificates: What do they tell me?
UNH-IOL Staff - July 24, 2012DLNA Certification would be somewhat senseless without the eponymous certificates. Any DLNA-Certified device’s certificate can be accessed via http://www.dlna.org, by searching for the product and then clicking “view certification results” and “view certificate.” At first glance the certificate seems relatively straightforward: it lists simple information like device class, certification date, capabilities (if you’re unclear on device classes and capabilities, hearken back to my previous post “DLNA 1.5 Device Classes – Why So Many?”). However, on the second page begins a more complex page titled “Media Format Interoperability.” This is the meat of the certificate, as it tells you exactly what the device was certified for—this, unfortunately, is not the same as what the device supports, but I’ll get to that in a bit.
Now, what you’re going to see on this section of the certificate will depend on the device class. All device classes will have the same left-hand columns of “Group” and “Profile Name,” but what follows on the right will vary. Let’s start by explaining a DMP (Digital Media Player).
The reading of this certificate is somewhat simple; a bullet in the “Play” column designates play support for that media format, a bullet in “Stop” indicates that the device is similarly able to stop this type of file. The next group of columns is only slightly more complex. Evidently, a bullet in any of the “Pause/Pause-Release” columns means that the device is capable of pausing (and resuming) the media format, however, which column this is under does matter: whatever server you are playing the file off of also needs to support that method in order to pause. This same principle holds true for the “Seek” and “Scan Mode” column groups.
Since we’re concerned about a DMS (Digital Media Server) working with a given DMP, let’s take a gander at a DMS registration next. For good reason, the DMS has fewer columns. With a DMP, the device will have to seek, scan, or pause, and do each with a method. With a DMS, all that matters is that the DMP can make a request via that method—the type of operation the DMP is carrying out is irrelevant. So if our DMP pauses via stalling for LPCM, we just need to check that the DMS is certified for stalling for LPCM (an audio format, like MP3 or WMA). We check similarly for Byte Range or Time Seek (seen as “Range” and “Time” on the certificate respectively).
A quick run-down of the remaining devices: a DMR looks the same as a DMP, and it should be examined the same way, the DMS still needs to support the same methods. A DMC, you may have noticed, is blank; this is because it must support all common media profiles between the DMR and DMS, and does not control methods (operation methods are at the DMR’s discretion). A +PU+ Certificate looks identical to a DMS, and should be read the same way.
UDO (Upload Device Option) has only four columns, and, if you’re looking to upload via DLNA, you should check to see if the bulleted support matches that of your +UP+ device, as the column names are identical.
The same applies for DS devices and +DN+. +PR1+ and +PR2+ should match up with what your DMPr supports.
Now, if you recall, I mentioned that what the device is certified for does not always correlate exactly to what it supports. This is because a device can support more than what it is certified for if the interoperability test bed cannot verify support for a particular profile or method. Most notably, a DMR will not list support for Byte Range or Time Seek on their certificate because the test bed cannot verify this. Similarly, many LP (DTCP-IP) profiles lack sufficient test bed support, so they cannot be certified. So, the DLNA Certificate will always list the minimum support that the device has and it may support more than what it is certified for.
DLNA Certificates are helpful in determining compatibility between DLNA devices for features other than basic ones. While it seems almost counter-intuitive that DLNA needs a complex way of checking compatibility when the protocol itself is supposed to promote universal interoperability, it’s more complex because of the scope of what DLNA is trying to accomplish. DLNA is trying to make all devices have the ability to work together, but with many different features and options. Since it doesn’t always make sense for every device to support all options, they can only enforce a modular approach to testing and Certification. Basic features on the devices will work together, and baseline requirements make sure that any random two DLNA-Certified devices will communicate and work together to some level. There are efforts to make all features (such as seek, scan, etc.) more universally accepted, but currently there is no such requirement. Many companies will try to make their devices support as much as possible to better work with other devices, but it’s still wise to check a product’s certificate to ensure a complete list of the features that matter to you.
About the Author
Austin Pond, Research and Development
Page 1 of 2Next >