So you have two shiny  new devices say one is a media server and the other is a TV. Both have stamped on them the letters DLNA. You know that DLNA is a standard for media transmission between devices (before Dr Flick jumps on me – I KNOW I am over simplifying greatly.) You would expect media from your server to play on your TV – wouldn’t you? Well perhaps.

The issue here is that it is only going to work if your shiny TV supports the same codecs (Video standards) as your equally shiny media server and that can be frustratingly unlikely.

If you stick to one eco-sphere of media it might work. For example Windows PCs stream pretty well to Xboxes. Yet even with these close siblings there can be frustrations and step over to say Apple’s world and try to stream Windows Media then you are in for a  tough time. I haven’t found an iPad  DLNA client yet that can play Windows Media Video.

The problem here is not just that it doesn’t always work but the fact that it is perceived as a standard that should just work and by not working  it is dragging down the perception of the convenience of the whole connected digital lifestyle.

So how to fix this. Whilst some manufacturers have done great things with their Media Renderers (the play back device)  that only really applies to devices with some processing grunt. For example I have never managed to throw something at the PS3 DLNA client it could not play. I think it is unreasonable to expect the playback devices to solve this issue – getting a phone to transcode on the fly from a standard it cannot play to one can is likely to grind the phone to a halt, although some Windows Phone 7 devices might cope. I think the way forward is with the servers. We need the ability to transcoding servers that can provide what the client CAN play.

Now this isn’t likely to happen for many of the existing media servers out there. So I think there is gap in the market for what I call a DLNA recoder this is something that would act as an intermediary between a server and a renderer client. Basically the renderer would see the recoder box as a server and the server would see it as a client. The recoder would interrogate the server and list all the content to the client but marking them to be in a format that the client could play. When the client requests media from the recoder will request the same media from the server but in a format the server can serve. The recoder will then transcode that media on fly into the format the client understands and stream it. Now I haven’t read the full DLNA standard and there may be something in the specs to cover this – I am sure Dr Flick will jump in if there is – but I haven’t seen a device that does this yet and I know I would buy one and I am sure others would too. I would equally be happy with something that ran on my Media Center to do this – I have seen some DLNA server software that claim to almost do this but I have not yet seen anything truly succeed yet.

Hopefully if DLNA server manufacturers got their act together then over time the need for such recoders would disappear but until that day I think they would  make a lot of Digital Lifestyles a lot easier.

0 thoughts on “Op Ed: DLNA – A frustrating standard”
  1. Comment Dr Flick sent me: 



    This should work, but we all know how that goes…..


    The UPnP/DLNA architecture is designed so that the ConnectionManager does a GetProtocolInfo() against the MediaServer to find out the format of the content.  It then performs a GetProtocolInfo() action against the MediaRenderer and a list of transfer protocols and data formats supported by the MediaRenderer is returned and used to determine that the MediaRenderer can play that format (or one of the formats available for that Content Item). The protocol/format information returned by the ContentDirectory service for the desired content is matched with the protocol/format information returned by the MediaRenderer’s ConnectionManager::GetProtocolInfo() action and passed to the Control Point.  The Control Point then selects a transfer protocol and data format that is supported by both the MediaServer and MediaRenderer for that connection’s Instance ID.  Of course, that is in a perfect world.


    There are three primary caveats with this process.

    ·         One is if the content is protected.  There is additional functionality to determine the DRM scheme and if it is supported by the MediaRenderer.  There is not a requirement to support all possible DRM schemes, so the content may not play at all.

    ·         Another related issue is if the Control Point is based upon an older version of the spec.  There actually are four fields returned with GetProtocolInfo.  Some older Control Points do not read the fourth field of the ProtocolInfo string, which is where the DRM type is defined (the third and fourth fields really need to match to ensure interoperability).  The older Control Point may not know that the MediaRenderer cannot play the content, will try, and then it fails.  Additionally, there are some parameters that have been updated with the newer versions related to the MIME type definitions, which also may influence the ability to match the protocols/data formats correctly.  This is yet another reason why companies like Microsoft specify the DLNA Version 1.5 or newer for their infrastructure to operate properly.

    ·         More to your point, the big issue is codecs (or Formats in DLNA lingo).  Many devices don’t support more than the minimum required Formats.  In fact, if the device is not certified, it may not even support the required minimum Formats.


    The following formats are the minimum required:





        MPEG-4 Part 2

        MPEG-4 Part 10






        MPEG-1/2 L2

        MPEG-1/2 L3

        MPEG-4 AAC LC

        MPEG-4 AAC LTP

        MPEG-4 HE AAC

        MPEH-4 BSAC




        WMA Professional











    Note that there also are different required Profiles for the content, which can be geographically oriented.  Different content is formatted differently depending upon the country in which it was rendered or is being played.  There also are various bit rates available for different Profiles (and Formats), which complicates things even further.  DLNA specifies is a list of minimum Profile requirements that define the bits rates that a MediaRenderer must support to be certified.  Microsoft also has extended these Profiles for the Windows Media platform.


    You also do not mention that there are different requirements for Mobile DLNA-based devices (DLNA Device Classes).  The requirements for a Mobile Digital Media Server (M-DMS) and Mobile Digital Media Player (M-DMP) are different than their non-mobile counterparts.


    I guess, lastly, is that some MediaServers also have the ability to transcode the content as part of streaming it to the MediaRenderer (many on-the-fly).  This seems like an area where your idea of a “middle man” would work the best.  Microsoft has put some effort into this transcoding process (probably because of the horsepower most PCs have available for doing this, especially with the ability to offload this to the graphics processor) for at least the Windows Media formats they support.  Not all MediaServers have this capability.


    Keep in mind you also are talking about Apple-based products.  Is anything Apple actually DLNA certified?  Also, note that being DLNA “compliant” may be different than being DLNA “certified” for many of these software-based solutions.  User/implementer beware, as you have seen.



Leave a Reply