Download the Guidelines
DLNA Members can click here to download the DLNA Guidelines. Guidelines that are in development or have not been integrated will remain available for DLNA Members ONLY
Non-member companies may download the Guidelines using the form below.
**Please note that the Guidelines you download today are the most current published version of the DLNA Guidelines. When new Guidelines are released, you will need to download the newer Guidelines to receive the additional updates. Note that not all updates are announced.
DLNA Guidelines - June 2016
The Interoperability Guidelines consists of ten parts covering Architecture and Protocols, Media Formats, Link Protection, DRM Interoperability Systems, Device Profiles, HTML5 RUI, Authentication, Diagnostics, HTTP Adaptive Delivery, and Low Power Mode. It provides vendors with the information needed to build interoperable networked platforms and devices for the digital home. The necessary standards and technologies are available now to enable products to be built for networked entertainment centric usages. However, standards and technologies need to be clarified and options limited to ensure interoperability. The DLNA Home Networked Device Interoperability Guidelines fulfill that role.
Part 1 - Architectures and Protocols
The Interoperability Guidelines are based on an architecture that defines interoperable components for devices and software infrastructure. It covers physical media, network transports, device discovery and control, media management and control, media formats, media transport protocols, and remote user interfaces. Table 1 shows a summary of the key functional components and technology ingredients that are covered by the Interoperability Guidelines.
|Functional Components||Technology Ingredients|
|Connectivity||Ethernet, 802.11 (including Wi-Fi Direct), MoCA, HD-PLC, HomePlug-AV, HPNA and Bluetooth|
|Networking||IPv4 and IPV6 Suite|
|Device Discovery and Control||UPnP* Device Architecture|
|Media Management and Control||UPnP AV, EnergyManagement, DeviceManagement, and Printer|
|Media Formats||Required and Optional Format Profiles|
|Media Transport||HTTP (Mandatory) , HTTP Adaptive Delivery (DASH) and RTP|
|Remote User Interfaces||CEA-2014-A , HTML5|
|Device Profiles||CVP-NA-1, CVP-EU-1, CVP-2|
Part 1-2 – Extended Digital Media Renderer
The DLNA Guidelines Parts 1–2 introduce a number of device classes to identify specific roles that connected endpoints implement in the network. Devices can act as content sources (e.g., Digital Media Servers, Push Controllers), and as content sinks (Digital Media Renderers or Digital Media Players).
Having two types of content sinks has been a useful strategy to accelerate the initial deployment phase. However, many of the modern receiver devices now include both types. Consequently, there is a need to define a receiver device that combines both types. This document addresses this issue and specifically, it describes a device class for an Extended Digital Media Renderer (XDMR).
PART 1-3 - CLOUD ACCESS
This document focuses on the discovery, association, and control of Apps capable of augmenting DLNA devices with the ability to consume content from sources outside of the home. The basic support is realized with the UPnP ApplicationManagement Service.
Part 2 - Media Format Profiles
This document describes DLNA Media Format profiles applicable to the DLNA Device Classes. Media Format profiles are defined for each of the following media classes: Audio, Image, and AV. In addition, Profile ID values that identify media collections were also introduced.
It is envisioned that in the home network environment, devices will be capable of exchanging content items that originate from different sources. Content items will typically come encoded in different formats. The term "format" designates the compression and encoding tools utilized to generate the binary instance of a content item, which will be eventually exchanged over the home network using streaming or file transfer protocols. Examples of formats include MPEG-2, MPEG-4, WMV and others for video; or MP3, AAC, WMA and others for audio.
Formats alone however, include as part of their specifications, multiple parameters, features and tools which can be used in a myriad of combinations to generate content binaries. In this document, the notion of a Format Profile is introduced to identify a particular suitable combination of format parameters which define a way for representing content binaries. A format like MPEG-2 for example, can have multiple profiles depending on selections for the companion audio, the system-layer multiplexing specifications, allowed frame resolutions, allowed aspect ratios, allowed bit rates, etc.
This document provides a list of Format Profiles for image, audio, and AV formats defined for use in DLNA devices. For each particular format profile, this document defines a Profile ID text token to be used during the DLNA media discovery and media transfer operations. The Profile ID is exposed in a server's Content Directory Service (CDS) to signal potential networked players or renderers the existence of a content item with particular coding and compression features defined precisely by the item's Profile ID. This document also describes the uses of Format Profiles which define media collections.
The number of potential combinations for suitable profiles becomes large rather quickly, as evidenced by the long profile lists observed in the different clauses and sub clauses of this document. Consequently, this document introduces the notion of mandatory profiles, supported by all devices, as a means to provide baseline content interoperability in the home. Servers will be capable of exposing and transferring mandatory profiles while players and renderers will be capable of decoding and rendering the mandatory profiles.
All profiles not defined as mandatory become optional in the home. An implementer can choose whether to support optional profiles. When supported and used with DLNA’s discover y and transfer methods, it will follow the guideline provisions for encoding and exposing optional profiles.
DLNA Media formats for Home and mobile/handheld Devices
|Media Formats||Required Formats Set||Optional Formats Set|
|Audio||LPCM, MPEG-1 L3 (MP3), MPEG-4 AAC LC||WMA9, AC-3, AAC, ATRAC3plus, MPEG4 (HE AAC, AAC LTP, BSAC), AMR|
|Video||MPEG2, MPEG-4 Part 10 (AVC) with MPEG-4 AAC LC associated audio||MPEG1, MPEG4, WMV9, VC1, H.263, MPEG4 part 2, MPEG4 AVC (BSAC or other for Assoc. Audio), HEVC H.265|
Part 3 – Link Protection
This document includes the DLNA Link Protection guidelines, which are an extension of the DLNA guidelines. DLNA Link Protection is defined as the protection of a content stream between two devices on a DLNA network from illegitimate observation or interception using the protocols defined within this document.
Content protection is an important mechanism for ensuring that commercial content is protected from piracy and illegitimate redistribution. Link Protection is a technique that enables distribution of protected commercial content on a home network, thus resulting in greater consumer flexibility while still preserving the rights of copyright holders and content providers.
The guidelines in this document reference existing technologies for Link Protection and provide mechanisms for interoperability between different implementations as well as integration with the DLNA architecture.
Part 4 – DRM Interoperability Solutions (DIS)
This part specifies DLNA guidelines for DRM interoperability. They are based on so named DLNA DRM Interoperability Solutions (DIS), which are defined as methods to enable the secure transfer and use of protected commercial content among different implementations on network media devices. This content could be protected by different content protection technologies, in this part are referred to as DRMs in short.
The guidelines are not intended to replace or disable other interoperability mechanisms that could already be in place, e.g. DLNA Link Protection guidelines or mechanisms provided by underlying DRMs.
Part 5 – Device Profiles
This document specifies guidelines that define various DLNA Device Profiles. A Device Profile is a collection of DLNA capabilities and features within a DLNA device. For a device to be compliant with a Device Profile, it has to conform to all of the guidelines listed for that Device Profile
In practice, Device Profiles reference existing optional or recommended DLNA guidelines, that enable certain features, and makes those DLNA guidelines mandatory within the context of a Device Profile. A Device Profile can also provide some additional guidelines that complement or modify existing DLNA guidelines for a feature.
A particular type of DLNA Device Profile is the Commercial Video Profile (CVP), VidiPath. VidiPath is an extension of the DLNA guidelines that will allow content from service providers and multichannel video programming distributers to be distributed on the DLNA network. DLNA Commercial Video Profiles (CVPs) are defined as Device Profiles that consistently enable commercial content that enters the home network through a gateway device via an interface to a commercial content service provider. Since different regions of the world have different requirements for commercial content, there are multiple CVPs defined.
Part 6-1 – Remote User Interface – HTML5
This part of DLNA Guidelines specifies guidelines that define HTML5 Remote User Interface (RUI-H). HTML5 allows operators to develop “write once, play anywhere” content applications across a broad range of browsers and platforms. Through native integration, HTML5 enables the repurposing of single codebases, resulting in reduced development costs and the provision of a unique UI for every device.
W3C MSE, EME and Crypto support for accessing protected content from outside of the home (HTML5 RUI Cloud) is defined.
Part 6-2 - Remote user interface - rvu
This part of the DLNA Guidelines specifies guidelines for RVU which is a remote user interface (RUI) protocol that allows clients to present a full-featured user interface by implementing minimal functionality, leaving most of the processing to the server. The RVU RUI delivers bitmapped and/or vector graphic user interface data for a robust, consistent UI experience throughout the home via thin clients.
Part 7 – Authentication
This document specifies DLNA interoperability guidelines for device authentication. The guidelines are based on a device authentication solution, which is defined as methods to enable authentication of a client device as DLNA Certified. Methods are included to allow a client device to authenticate a server device as trusted by a Certificate Authority. The guidelines are intended to supplement other interoperability mechanisms already defined for DLNA link protection and DLNA DRM interoperability solutions.
Part 8 – Diagnostics
The DLNA Diagnostics Guidelines focus mostly on the collection of data through test actions and queries. The procedures for troubleshooting and remedies are outside the scope of the DLNA Guidelines. A user interface is required on the controller side that will allow user access to Diagnostics data and capabilities. The user might be an Operator accessing the Diagnostics application through a TR-069 (an application layer protocol for remote management of end-user devices) management interface, or a technician or end-user accessing it through a browser or screen interface.
Part 9 – HTTP Adaptive Delivery
The DLNA interoperability guidelines for Adaptive Delivery enable content authors to describe content in timed segments at various bit rates and media formats. Client rendering devices can select the appropriate timed segments (e.g. bit rate) based on network congestion to maintain smooth streaming of content for display.
Part 10 – Low Power Mode
This document specifies guidelines for Low Power Mode management. Power savings is modular within a physical device. In the context of DLNA networked devices each physical network interface can have various power modes, some of which can allow Layer 2 or Layer 3 connectivity to still be present, even when many of the other components of the device are powered down. Other physical components, such as screens, hard drives, and similar resources, can also support different power modes.