Device.Media Requirements
Device.Media.DMR.AV
Devices that can serve A/V content need to implement these requirements.
| Related Requirements |
Device.Media.DMR.AV.AVC Device.Media.DMR.AV.WMV |
Device.Media.DMR.AV.AVC
AVC requirements for a DMR
| Target Feature |
Device.Media.DMR.AV |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
| Req. AVC-01 |
| Applies to AV DMR |
| A DMR must decode and render content identified with the following Profile IDs: Profile for AVC content (SD) is Jun. 26, 2013 Profile for AVC content (HD) is Jun. 26, 2013 Note: These profiles will be published before the end of 2011 once related industry standardization efforts reach stability. For early implementers, we recommend the following guidelines: AVC SD content: MP@L3, fragmented and non-fragmented, AAC-LC audio, MP4 filesAVC HD content: MP@L4, fragmented and non-fragmented, AAC-LC audio, MP4 files |
| Req. AVC-05 |
| Applies to AV DMR |
| A DMR must declare these Profile IDs in the list of supported profiles exposed in the SinkProtocolInfo state variable available as part of the Connection Manager Service (CMS). |
| Req. AVC-10 |
| Applies to AV DMR |
| A DMR device must be able to decode the video rotation angle from MP4 files and perform video rotation during composition. The DMR must be able to perform rotations for angles of 0, 90, 180, and 270 degrees. |
Design Notes
As described in the DLNA Guidelines, a DMR declares in the SinkProtocolInfo state variable the list of all the media types it can play. A DMC connected to the network reads the value of this state variable to determine if content can be played or not in a DMR.The video rotation angle is defined in the MP4 File Format specification as a transformation matrix that decoders apply during composition - see Section 6.2.2 of ISO/IEC 14496-12:2005(E). In the matrix, coefficients a, b, c, and d define a rotation transformation for an angle of R degrees (measured counterclockwise) ifa = cos R, b = sin R, c = -sin R, and d = cos R There are two locations for this matrix; one is in the movie header (mvhd) and the other is in the track header (tkhd). For any track, the actual video rotation is given by the sum of the angle defined in the movie header and the angle defined in the corresponding track header. For example, the following 3 cases show a rotation of 90 degrees:
Case 1: movie header rotation: 0 degrees, track header rotation: 90 degrees
Case 2: movie header rotation: 90 degrees, track header rotation: 0 degrees
Case 3: movie header rotation: 20 degrees, track header rotation 70 degrees
Cameras normally use Case 1 and possibly Case 2. Case 3 is allowed in the MP4 specifications but it is not normally used. The tests will cover only cases 1 and 2.
Additional Information
| Enforcement Date |
Mar. 01, 2012 |
Device.Media.DMR.AV.WMV
WMV requirements for a DMR
| Target Feature |
Device.Media.DMR.AV |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
| Req. WMV-01 |
| Applies to AV DMR |
| A DMR must decode and render content identified with the following Profile IDs: WMVMED_BASE WMVMED_FULL WMVHIGH_FULL |
| Req. WMV-05 |
| Applies to AV DMR |
| A DMR must declare these Profile IDs in the list of supported profiles exposed in the SinkProtocolInfo state variable available as part of the Connection Manager Service (CMS). |
Design Notes
The WMV Profile IDs referenced in this requirement are defined in the DLNA Media Formats Guidelines.As described in the DLNA Guidelines, a DMR declares in the SinkProtocolInfo state variable the list of all the media format profiles that it can play. A DMC connected to the network reads the value of this state variable to determine if content can be played or not by a DMR.
Additional Information
| Enforcement Date |
Mar. 01, 2012 |
Device.Media.DMR.Base
Baseline requirements for all DMR devices
| Related Requirements |
Device.Media.DMR.Base.ChangingFriendlyName Device.Media.DMR.Base.ContentPlaybackWithoutUserInput Device.Media.DMR.Base.DeviceInformation Device.Media.DMR.Base.DisplayedMetadata Device.Media.DMR.Base.DLNA15CertificationCompliance Device.Media.DMR.Base.DMPPlayback Device.Media.DMR.Base.DMPSelectionOfAdvertisedResources Device.Media.DMR.Base.DMRStateAfterFindingAnError Device.Media.DMR.Base.EndOfStream Device.Media.DMR.Base.Events Device.Media.DMR.Base.MetaDataPackage Device.Media.DMR.Base.MetadataSize Device.Media.DMR.Base.OptionalFieldsEntries Device.Media.DMR.Base.PausingAStream Device.Media.DMR.Base.PlaybackPerformance Device.Media.DMR.Base.PlayBackPerformanceConstrainedBandwidth Device.Media.DMR.Base.PlaysMediaContinuously Device.Media.DMR.Base.ProtocolInfoField Device.Media.DMR.Base.ResponseToSetAVTransportURIActions Device.Media.DMR.Base.SeekOperations Device.Media.DMR.Base.SendsSSDPByeByeMessage Device.Media.DMR.Base.SetNextAVTransportURI Device.Media.DMR.Base.VolumeControl Device.Media.DMR.Base.WakeOnLAN Device.Media.DMR.Base.WiFiDirectSupport Device.Media.DMR.Base.WMDRMNDLinkProtectionSupport |
Device.Media.DMR.Base.ChangingFriendlyName
DMR supports changing the Friendly Name
| Target Feature |
Device.Media.DMR.Base |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
| Req. NAME-01 |
| Applies to AV DMR, Audio DMR |
| A Digital Media Renderer (DMR) must allow the user to update the DMR friendly name using any configuration method. The DMR friendly name is defined as the string value included in element friendlyName in the Device Description Document. |
Design Notes
Some DMR devices may choose to implement this requirement using the presentationURL element in the Device Description Document. The URL in this element points to a device web page that may define configuration options. One of the configuration options can give users the opportunity to change the friendly name. Other DMR devices may choose different means to give users the option to change the DMR friendly name.The use of a presentation URL to expose an HTML presentation page is described in the UPnP Device Architecture (DA) specification at https://www.upnp.org.
Additional Information
| Enforcement Date |
Mar. 01, 2012 |
Device.Media.DMR.Base.ContentPlaybackWithoutUserInput
DMR content playback without user input
| Target Feature |
Device.Media.DMR.Base |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
| Req. INPUT-01 |
| Applies to AV DMR, Audio DMR |
| A Digital Media Renderer must advertise its presence on the network via ssdp:alive messages after the device has been turned on and once the user has completed any required network configuration options. |
| Req. INPUT-05 |
| Applies to AV DMR, Audio DMR |
| If a Digital Media Renderer advertises its presence on the network via ssdp:alive messages, it must be capable of accepting actions, including SetAVTransportURI() and Play() from a Digital Media Controller without requesting any additional user input. The only exception for this requirement is if the user is performing interactive operations with the device such as configuring the device, playing games, etc. Only in these cases, the device may respond with error codes that indicate that the device is busy. |
| Req. INPUT-10 |
| Applies to AV DMR, Audio DMR |
| A Digital Media Renderer that implements additional functionality for passive media consumptionmust also advertise its presence on the network when the device is used for passive media consumption activities.Examples of passive media consumption activities are: watching TV, listening to AM/FM radio, listening to CDs, listening to Internet music, watching a DVD or BD disk, watching a movie from the Internet, operating the device as a DMP, etc. Active media consumption is the opposite of passive media consumption. Playing games is an example of an active media consumption activity. Using menus to configure device options is another example of active media consumption. This requirement does not apply to active media consumption scenarios. |
Design Notes
The moment a DMR advertises its presence to the network, any DMC device connected to the network expects the DMR to operate without further delays. Some DMRs could be designed for example to authorize every stream request received from a DMC, but this approach disrupts the interactions of DMCs and DMRs. This requirement forces DMRs to perform any configuration operations before they start sending ssdp:alive messages. Requirement INP10 applies to multi-function devices. For example, it applies to devices that implement a DMR, a TV, and an AM/FM radio receiver. This requirement indicates that the DMR needs to be advertised even if the device operates as a TV, as an AM/FM radio receiver, etc. In addition, requirement INP05 indicates that once the DMR is advertised on the network, it needs to be fully operational. In other words, if the user is watching TV or listening to AM/FM radio, the DMR is fully operational in the background. If the user picks a controller and pushes a picture to the device, the device needs to transition from TV mode or AM/FM radio mode into DMR mode automatically. Although the examples described in the Design Notes mention TV experiences and AM/FM radio experiences, they apply to any other types of passive media consumption like playing a DVD/BD or listening to Internet radios.
Additional Information
| Enforcement Date |
Mar. 01, 2012 |
Device.Media.DMR.Base.DeviceInformation
Availability of DMR Information
| Target Feature |
Device.Media.DMR.Base |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
Req. INFO-01 The following device information must be available at the time of testing: * If the device uses firmware (or middleware): firmware vendor and firmware version * If the device uses an application model: App name, App vendor, App version, and App platform * If the device uses an Operating System: OS name and OS version * Hardware Platform (e.g ARM, x86, x64, etc) * Manufacturer Name * Model Number Design Notes The information is collected to identify certified devices, track bugs, identify areas of improvement, etc.
Additional Information
| Enforcement Date |
Mar. 01, 2012 |
Device.Media.DMR.Base.DisplayedMetadata
Displayed Metadata in DMR Operations
| Target Feature |
Device.Media.DMR.Base |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
| Req. DISP-01 |
| Applies to AV DMR, Audio DMR |
| If a DMR displays the title of an item during playback, by default the title must be extracted from the dc:title value associated with the item or from an internal metadata field within the file. If the DMR displays the date of a picture during playback, by default the date must be extracted from the dc:date value associated with the picture or from an internal metadata field within the file. If the DMR displays the size of a file during playback, the value must describe the correct file size. A DMR can obtain the file size from the res@size attribute, from an internal metadata field in the file, or from its own size computation. After determining the file size, the DMR may round the value to any desired precision (e.g. zero decimal digits, one decimal digit, etc.) in order to show the value in a User Interface. If an average user measures the duration of an A/V or audio item using a standard clock as Tuser, and if the DMR displays the content duration as Tdisp, then for all cases, the displayed duration must comply with: 0.9 Tuser < Tdisp < 1.1 Tuser Note: These requirements describe the default behavior expected from DMR devices. At any time, a user can bypass the default behavior and register user-defined titles, or dates, or event duration values. |
Design NotesMany of the popular file formats like MP4 and ASF include metadata fields that describe title information. Similarly, the file formats for JPEG and PNF also include metadata fields that describe the image creation date. These metadata fields together with metadata properties received from a controller (dc:title, dc:date) represent the best source for obtaining correct values.
Additional Information
| Enforcement Date |
Mar. 01, 2012 |
Device.Media.DMR.Base.DLNA15CertificationCompliance
DMR compliance with DLNA 1.5 Certification
| Target Feature |
Device.Media.DMR.Base |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
| Req. DLNA-01 |
| Applies to AV DMR, Audio DMR |
| A Digital Media Renderer must demonstrate compliance with the DLNA protocols using one of the following alternatives: The DMR passes the DLNA Certification Program and obtains a DLNA certificate. The DMR uses an OEM reference design (hardware/software) that has already passed the DLNA Certification Program and has obtained a DLNA certificate. The DMR uses middleware from an independent software provider. The middleware has passed the DLNA Certification Program and has obtained a DLNA certificate. If the device implements multiple network interfaces (Ethernet, Wi-Fi, etc.), the DLNA Certificate must indicate a satisfactory evaluation using all interfaces. If the device implements additionally a DMP, the device must demonstrate compliance with the DLNA protocols for the DMP class using one of the alternatives mentioned above.If the device implements additionally a DMS, the device must demonstrate compliance with the DLNA protocols for the DMS class using one of the alternatives mentioned above. |
| Req. DLNA-05 |
| Applies to AV DMR |
| An AV DMR is a renderer that plays images, audio, and videos. The DLNA certification for an AV DMR must include the Image Class, the Audio Class, and the A/V Class. |
| Req. DLNA-10 |
| Applies to Audio DMR |
| An Audio DMR is a renderer that plays audio but not video. The DLNA certification for an Audio DMR must include the Audio Class. If an Audio DMR plays images, the DLNA certification for this Audio DMR must include the Image Class. |
Design Notes
The Windows Device Certification Program recognizes two types of renderers:
AV DMR: A Digital Media Renderer that plays images, audio, and A/V content. For example, a TV, a BD players, a Set-Top Box, etc.
Audio DMR: A Digital Media Renderer that plays audio content but not videos. An Audio DMR could play images.
Additional Information
| Enforcement Date |
Mar. 01, 2012 |
Device.Media.DMR.Base.DMPPlayback
DMP Playback Functionality
| Target Feature |
Device.Media.DMR.Base |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
| Req. DMP-01 |
| Applies to AV DMR, Audio DMR |
| If a DMR device also implements a Digital Media Player (DMP), the DMP must play all content types that can be played as a DMR. Similarly, the DMR must play all content types that can be played as a DMP. The different types of content are defined using a Profile ID, a MIME type, or both. |
| Req. DMP-05 |
| Applies to AV DMR, Audio DMR |
| If a DMR device also implements a Digital Media Player (DMP), the DMP and the DMR must work jointly as a single combined unit in the network: If the DMP plays content, the DMR state variables must change accordingly to reflect the playback conditions. If the DMP stops or pauses playback, the DMR state variables must change accordingly to advertise the changes. The DMR state variables advertise conditions such as current status, current state, current position, current transport actions, etc. |
| Req. DMP-10 |
| Applies to AV DMR, Audio DMR |
| If a DMR device also implements a Digital Media Player (DMP), the DMP must be capable to navigate a Reference Windows DMS in compliance with the following performance procedure and requirement: Using the DMP controls find the UI from where users start navigating the content in a DMS Using the DMP controls navigate the UI menus to find the first music item Using the DMP controls play the first music item The time to complete tasks 2 and 3 must not exceed 10 seconds (under ideal network conditions). |
Design Notes
A Reference Windows DMS is defined as a Windows 8 PC, with WinSAT score of 4 or higher, that shares content with DLNA devices. The content available in a reference Windows DMS is 300 pictures in the Pictures library, 300 music files in the Music library, and 30 video files in the Videos library.
Additional Information
| Exceptions |
If ImplementedIf a Digital Media Renderer device also works as a Digital Media Player then this requirement applies. A DMR that does not work as a DMP needs not implement this requirement. |
| Enforcement Date |
Mar. 01, 2012 |
Device.Media.DMR.Base.DMPSelectionOfAdvertisedResources
DMP selection of advertised resources
| Target Feature |
Device.Media.DMR.Base |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
| Req. DMP-20 |
| Applies to AV DMR, Audio DMR |
| This requirement only applies if a DMR device also implements a DMP. Furthermore, this requirement only applies if all the following conditions are satisfied: A DMP finds an item with multiple <res> elements. A DMP selects an A/V or an Audio resource in streaming mode, or a DMP selects an Image resource in interactive mode. A DMP connects to a DMS under ideal network conditions The DMP must select a <res> element according to the following procedures: Audio ClassIf the server exposes a non-transcoded resource with a Profile ID that matches one of the Profile IDs advertised by the DMP/DMR device, then the DMP device must select this resource. If the DMP does not support the Profile ID for the non-transcoded resource, the DMP must select a transcoded resource with a supported Profile ID and play this resource. A/V Class: If the server exposes a non-transcoded resource with a Profile ID that matches one of the Profile IDs advertised by the DMP/DMR device, then the DMP device must select this resource. If the DMP does not support the Profile ID for the non-transcoded resource, the DMP must select a transcoded resource with a supported Profile ID and play this resource. Image ClassThe DMP device must select a <res> element for an image with a resolution of 1920x1080 or smaller. There is one exception: a DMP device may select an image resource with a resolution higher than 1920x1080 if the DMP can display the image within 2 seconds. The 2 seconds are measured from the moment the user selects an image to the moment the image is displayed on the screen. |
Design Notes
A Windows DMS often exposes content items using multiple <res> elements. Each element identifies the same item but using different encoding formats and different bitrates. When a DMP starts the process to play the content, the DMP needs to select one <res> element for playback.The native (non-transcoded) content can be identified from the DLNA.ORG_CI flag. A value of 1 indicates transcoded (non-native) content. A value of 0 indicates the opposite. The absence of this flag is equivalent to a value of 0. This requirement does not apply in the following conditions: (1) the exchange happens under poor network conditions, (2) the request uses background transfer, and (3) the <item> element has only one <res> element. For Image Class behavior, it is acceptable to provide a configuration option (a menu or a UI dialog window) to bypass the recommended behavior (default behavior), so that the DMP always selects the highest quality image at the expense of transfer time.
Additional Information
| Exceptions |
If ImplementedIf a Digital Media Renderer also works as a Digital Media Player then this requirement applies. A DMR that does not work as a DMP needs not implement this requirement. |
| Enforcement Date |
Mar. 01, 2012 |
Device.Media.DMR.Base.DMRStateAfterFindingAnError
DMR state after finding an error
| Target Feature |
Device.Media.DMR.Base |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
| Req. ERROR-01 |
| Applies to AV DMR, Audio DMR |
| If a Digital Media Renderer (DMR) is in the PLAYING, TRANSITIONING, or PAUSED_PLAYBACK state and encounters a non-recoverable error, the DMR must enter a STOPPED state and wait for instructions from the Digital Media Controller (DMC). At the same time, the DMR must report the error setting the value of the TransportStatus state variable to ERROR_OCCURRED.As a consequence of this requirement, a DMR with a TransportState value equal to STOPPED and its TransportStatus value equal to ERROR_OCCURRED implies that content playback has been terminated due to an error. |
| Req. ERROR-05 |
| Applies to AV DMR, Audio DMR |
| If the DMC provides another resource using SetAVTransportURI(),the DMR must suppress any error message (i.e., change the value of TransportStatus to OK) and begin the process to play the new resource. |
Design Notes
This requirement is simply a clarification of behavior described in the UPnP AVTransport:1 specifications. In particular, Fig. 1 of the AVTransport:1 specifications describes the behavior after error conditions together with the specifications for the TransportStatus and TransportState state variables .
Additional Information
| Enforcement Date |
Jun. 01, 2011 |
Device.Media.DMR.Base.EndOfStream
DMR requirement for end of stream
| Target Feature |
Device.Media.DMR.Base |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
| Req. EOS-01 |
| Applies to AV DMR, Audio DMR |
| A DMR that finishes playing a media resource must enter the STOPPED state. The resource URI remains associated with the DMR. Consequently, if the DMR receives a new Play() action, the DMR must start playing the same resource. If the resource is either audio or A/V, playback starts from the beginning (play time of 0). |
Design Notes
If the DMR device finishes playing the stream, it needs to enter a stopped state and wait for instructions from any DMC. This requirements exists in the UPnP AVTransport:1 specifications .
Additional Information
| Enforcement Date |
Mar. 01, 2012 |
Device.Media.DMR.Base.Events
DMR Events
| Target Feature |
Device.Media.DMR.Base |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
| Req. EVENT-01 |
| Applies to AV DMR, Audio DMR |
| The DMR must send AVT LastChange events and RCS LastChange events as described in the related UPnP and DLNA specifications. |
Design NotesThe UPnP specifications for the AV Transport Service (AVT) define the use of the AVT LastChange state variable. Similarly, the UPnP specifications for the Rendering Control Service (RCS) define the use of the RCS LastChange state variable. DLNA clarifies several issues such as timing of the different events. UPnP and DLNA require DMRs to implement eventing of these state variables.The DLNA certification program verifies the implementation of events but they do not cover all cases. The Windows Certification tests for this requirement cover many more cases including events for state transitions, URI value changes, and others.
Additional Information
| Enforcement Date |
Mar. 01, 2012 |
Device.Media.DMR.Base.MetaDataPackage
The device has a metadata package that meets Windows 8 metadata specifications for the specific device category; and the metadata package is posted for public usage.
| Target Feature |
Device.Media.DMR.Base |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
| Req. META-01 |
| Applies to AV DMR, Audio DMR |
| The device must have a metadata package that meets Windows 8 metadata specifications for the specific device category. The metadata package must be posted for public distribution through the Windows Metadata Information Services (WMIS) once the hardware certification submission is approved and/or available for distribution with the device. |
Additional Information
| Enforcement Date |
Mar. 01, 2012 |
Device.Media.DMR.Base.MetadataSize
DMR metadata size requirements
| Target Feature |
Device.Media.DMR.Base |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
| Req. META-20 |
| Applies to AV DMR, Audio DMR |
| The DMR must be capable of receiving a DIDL-Lite fragment in CurrentURIMetaData with at least 30 <res> elements and metadata inclusive. The DMR must tolerate the presence of at least 30 <res> elements in a message. However, the DMR decides if it parses (and uses) the information in the <res> elements. |
| Req. META-25 |
| Applies to AV DMR, Audio DMR |
| If the DMR receives more than 30 <res> elements in the CurrentURIMetaData argument of SetAVTransportURI(), the DMR must do one of the following: Return UPnP error 501 (Action Failed) Accept the metadata |
Design Notes
There is no conflict between this requirement and the current DLNA Guidelines. The DLNA Guidelines require a DMR to accept SOAP requests of up to 20,480 bytes in size. Consequently, a SetAVTransportURI() request can be as large as 20 KB in size, which is sufficient to accommodate more than 30 <res> elements.
Additional Information
| Enforcement Date |
Mar. 01, 2012 |
Device.Media.DMR.Base.OptionalFieldsEntries
DMR must provide non-empty and valid entries for optional fields
| Target Feature |
Device.Media.DMR.Base |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
| Req. DDD-01 |
| Applies to AV DMR, Audio DMR |
| In addition to the normative fields in a Device Description Document (DDD), a DMR must provide non-empty and valid entries for the following optional fields: The manufacturer's name in the <manufacturer> element The model name in the <modelName> element The model number in the <modelNumber> element A user-friendly name in the <friendlyName> element |
Design Notes
The UPnP Device Architecture (DA) specification defines the structure of the Device Description Document.
Additional Information
| Enforcement Date |
Mar. 01, 2012 |
Device.Media.DMR.Base.PausingAStream
DMR supports pausing a stream
| Target Feature |
Device.Media.DMR.Base |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
| Req. PAUSE-01 |
| Applies to AV DMR, Audio DMR |
| The Digital Media Renderer (DMR) must support pausing Audio or A/V streams. A DMR that receives a Pause() action must pause the rendering process. After a Pause() action, a DMR that receives a Play() action must resume playback from the same position. A DMR must be capable of pause/resume operations for any resources of the following types: Audio or A/V resources for which the DMS supports time-range requests, or byte-range requests, or connection stalling. |
| Req. PAUSE-05 |
| Applies to AV DMR, Audio DMR |
| The Pause operation must be available while the DMR is in the PLAYING state (for audio and A/V resources). As defined in the DLNA Guidelines, the DMR must advertise availability of this operation by inserting the keyword "Pause" in the list of CurrentTransportActions. |
Design Notes
A DMR can implement pause/resume operations using the following methods: Local caching - The DMR caches the content and performs pause/resume operations using cached data. Byte-range requests - Upon receiving a Pause request, the DMR stores the byte position. Upon receiving a request to resume playback, the DMR issues a byte-range request against the server starting from the stored byte position.Time-range requests - Upon receiving a Pause request, the DMR stores the current play time position. Upon receiving a request to resume playback, the DMR issues a time-range request against the server starting from the stored time position. Connection stalling - The DMR stalls the HTTP connection until the user resumes playback. Servers usually do not keep stalled connections open for a long time. If a server closes the connection, the DMR needs to use either time-range or byte-range requests.
Additional Information
| Enforcement Date |
Mar. 01, 2012 |
Device.Media.DMR.Base.PlaybackPerformance
DMR Playback Performance
| Target Feature |
Device.Media.DMR.Base |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
| Req. PERF-01 |
| Applies to AV DMR, Audio DMR |
| A DMR device must comply with the performance specifications indicated in Table PERF below.The test content for this requirement has the following characteristics: A/V: AVC and AAC using an MP4 file. The video resolution is 1280 x 720 at 30 fps. Maximum system bitrate of 5 Mbps Audio: LPCM content, Maximum bitrate of 1.5 Mbps Image: 1920x1080, Maximum size of 500 Kbytes All tests require ideal network conditions. |
| Req. PERF-05 |
| Applies to AV DMR, Audio DMR |
| A DMR that needs more than 3 seconds to play Audio, A/V, or Images for any of the cases described in Table PERF must display a visual indicator to indicate that data is being processed and that it will start playing content soon. |
Table PERF: Expected performance values for DMR devices
| DMR state |
Task starts |
Task ends |
Max Latency |
| NO_MEDIA_PRESENT |
User hits a play button (video) |
DMR starts displaying video |
5 sec |
| PLAYING |
User hits a play button for new content (video) |
DMR starts displaying the new video |
5 sec |
| STOPPED |
User hits a play button for new content (video) |
DMR starts playing the new video |
5 sec |
| PLAYING |
User seeks to a different position in the stream (video) |
DMR starts displaying video from the new position |
5 sec |
| PLAYING |
User hits the pause button (audio or video) |
DMR pauses playback |
2 sec |
| PAUSED_PLAYBACK |
User hits the play button to resume (audio or video) |
DMR resumes playing the content |
2 sec |
| NO_MEDIA_PRESENT |
User hits a play button (audio) |
DMR starts playing audio. |
3 sec |
| PLAYING |
User hits a play button for new content (audio) |
DMR starts playing the new audio. |
3 sec |
| STOPPED |
User hits a play button for new content (audio) |
DMR starts playing the new audio. |
3 sec |
| PLAYING |
User seeks to a different position in the stream (audio) |
DMR starts playing audio from the new position. |
3 sec |
| NO_MEDIA_PRESENT |
User hits a play button (image) |
DMR displays the image. |
3 sec |
| STOPPED |
User hits a play button with new content (image) |
DMR displays the new image |
3 sec |
| NO_MEDIA_PRESENT, STOPPED, PLAYING, PAUSED_PLAYBACK |
User changes the volume level |
DMR plays (or can play) content at the new level |
2 sec |
| NO_MEDIA_PRESENT, STOPPED, PLAYING, PAUSED_PLAYBACK |
User applies mute (or removes mute). |
DMR is muted (or is not muted) |
2 sec |
Design Notes
The DLNA Guidelines define the term "ideal network conditions" as a connection with virtually unlimited bandwidth and negligible congestion.
Additional Information
| Enforcement Date |
Mar. 01, 2012 |
Device.Media.DMR.Base.PlayBackPerformanceConstrainedBandwidth
DMR Playback Performance under constrained bandwidth
| Target Feature |
Device.Media.DMR.Base |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
| Req. PLAYBACK-01 |
| Applies to AV DMR |
| This requirement applies to a network with approximately constant throughput of 16 Mbps (i.e. a network that simulates an interference-free 802.11g network). This requirement uses A/V content with an instantaneous system bitrate that never exceeds 11 Mbps. A DMR that receives such content normally buffers a few seconds of data before rendering the content. Once the DMR starts rendering the content, the DMR must be able to play the entire content without re-buffering. |
Design NotesA good DMR implementation does not need to re-buffer if the network has enough bandwidth to transfer the content in real time or at rates higher than real-time. This requirement simply tests this assumption.
Additional Information
| Enforcement Date |
Mar. 01, 2012 |
Device.Media.DMR.Base.PlaysMediaContinuously
DMR plays media continuously
| Target Feature |
Device.Media.DMR.Base |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
| Req. STRESS-01 |
| Applies to AV DMR, Audio DMR |
| A DMR must be able to play a mixture of content types continuously without errors, without user intervention, and without degradation in quality, for at least 6 hours. In practice the test will verify that the device neither crashes nor responds with long delays. |
Design Notes
A DMR device needs to work autonomously for long periods of time. The test associated with this requirement plays a mixture of content for a period of 6 hours. However, in practice, DMR devices should be designed to perform consistently for longer periods of time.
Additional Information
| Enforcement Date |
Jun. 01, 2011 |
Device.Media.DMR.Base.ProtocolInfoField
DMR Use of the protocolInfo field
| Target Feature |
Device.Media.DMR.Base |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
| Req. PROT-01 |
| Applies to AV DMR, Audio DMR |
| A DMR that exposes in SinkProtocolInfo a protocolInfo value with a MIME Type and a DLNA Profile ID must be able to play content encoded according to the DLNA specifications for the Profile ID. |
| Req. PROT-05 |
| Applies to AV DMR, Audio DMR |
| A DMR that exposes in SinkProtocolInfo a protocolInfo value with a MIME Type but without a DLNA Profile ID must be able to play content as specified in Table PROT. |
Table PROT: List of supported protocols associated with MIME types (for DMR devices that advertise a protocolInfo value with a MIME type but without a DLNA Profile ID)
| MIME type |
DMR plays at least this type of content |
| audio/mpeg |
Profile ID: MP3 |
| video/x-ms-wmv |
Profile IDs: WMVHIGH_FULL, WMVHIGH_PRO, WMVMED_BASE, WMVMED_FULL, WMVMED_PRO, WMVSPML_BASE, WMVSPLL_BASE |
| audio/x-ms-wma |
Profile IDs: WMABASE, WMAFULL, WMAPRO, WMALSL |
| audio/mp4 or audio/3gpp |
Profile IDs: AAC_ISO_192, AAC_ISO_320, AAC_ISO |
| audio/wav |
Content encoded for a Profile ID of LPCM but using a WAV file format to carry the binary stream. |
| audio/vnd.dlna.adts |
Profile IDs: AAC_ADTS_192, AAC_ADTS_320, AAC_ADTS |
| video/mp4 |
In addition to content described in Req. Device.Media.DMR.AV.AVC, the device must decode the following Profile IDs: AVC_MP4_MP_SD_AAC_MULT5, AVC_MP4_BL_L3_SD_AAC, AVC_MP4_BL_L2_CIF30_AAC, AVC_MP4_MP_HD_720p_AAC, AVC_MP4_MP_HD_1080i_AAC, AVC_MP4_HP_HD_AAC |
| video/quicktime |
A/V content encoded using Apple's Quicktime specifications using the MOV file format. |
Design Notes
A Digital Media Renderer exposes a list of protocolInfo values using the SinkProtocolInfo state variable. These values represent the collection of protocols that the DMR can play. According to DLNA specifications, each protocolInfo entry always carries a Profile ID to identify decoding formats. Many DMR devices use protocolInfo values without a Profile ID (DLNA considers this behavior as out of scope of its specifications). This requirement provides minimum playback requirements for these cases to attempt certain level of interoperability.
Additional Information
| Enforcement Date |
Mar. 01, 2012 |
Device.Media.DMR.Base.ResponseToSetAVTransportURIActions
DMR Response to SetAVTransportURI actions
| Target Feature |
Device.Media.DMR.Base |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
| Req. SETAVT-01 |
| Applies to AV DMR, Audio DMR |
| If a DMR is in the PLAYING state and receives a SetAVTransportURI() action with a valid non-empty URL, the DMR must stop playing the content and start playing the new content defined by the URL. |
Design Notes
The behavior described in this requirement corresponds to the original desired behavior defined in the UPnP AVTransport:1 specifications. DLNA allows the same behavior but it also allows a relaxed option. In the relaxed option, a DMR that is in the PLAYING state can respond with an error if it receives a SetAVTransportURI() action. These DMRs need to receive a Stop() action before accepting a new SetAVTransportURI().Unfortunately, the relaxed option introduced by DLNA creates an implementation problem. This requirement mandates that DMR devices follow the original UPnP AVTransport:1 specifications.
Additional Information
| Enforcement Date |
Mar. 01, 2012 |
Device.Media.DMR.Base.SeekOperations
DMRs must have seek supportDMRs must have seek support
| Target Feature |
Device.Media.DMR.Base |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
DMRs that support audio or video are tested to validate seek functionality.
Seek from both the playing and paused states is required.
If the DMR additionally supports seek from the stopped state it must implement it fully and correctly according to the requirement. This is necessary to ensure fast playback of audio or video when a user initiates a Play To session from non-zero playback position.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Media.DMR.Base.SendsSSDPByeByeMessage
DMR sends ssdp:byebye messages
| Target Feature |
Device.Media.DMR.Base |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
| Req. BYEBYE-01 |
| Applies to AV DMR, Audio DMR |
| A device that implements DMR functionality must send ssdp:byebye messages when the device turns off the DMR functionality. This requirement does not apply to error conditions like accidental disconnections or unexpected malfunctioning. This requirement applies to all cases when a user gracefully turns off the DMR function. |
| Req. BYEBYE-05 |
| Applies to AV DMR, Audio DMR |
| A DMR device that supports a low power (sleep) mode must send ssdp:byebye messages when the device enters low power mode. For devices that support multiple levels of low power modes, this requirement applies to any modes where the device can no longer accept UPnP actions from controllers in the network. |
| Req. BYEBYE-10 |
| Applies to AV DMR, Audio DMR |
| A DMR device must send ssdp:byebye messages in compliance with UPnP and DLNA specifications. In particular, a DMR device sends one ssdp:bybye message for each corresponding ssdp:alive message. |
Design Notes
Devices implement ssdp:byebye messages according to the UPnP Device Architecture 1.0 specification with the additional clarifications defined in the DLNA Guidelines.
Additional Information
| Enforcement Date |
Mar. 01, 2012 |
Device.Media.DMR.Base.SetNextAVTransportURI
DMR supports SetNextAVTransportURI
| Target Feature |
Device.Media.DMR.Base |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
| Req. SETNEXT-01 |
| Applies to AV DMR, Audio DMR |
| A DMR device must implement the SetNextAVTransportURI() action and its related state variables NextAVTransportURI and NextAVTransportURIMetaData. |
| Req. SETNEXT-05 |
| Applies to AV DMR, Audio DMR |
| If the DMR is playing an audio resource, then as soon as the resource finishes playing, the DMR must play the resource described in the NextAVTransportURI state variable.If the DMR is playing an A/V resource, then as soon as the resource finishes playing, the DMR must play the resource described in the NextAVTransportURI state variable.If the DMR is playing an image resource, then as soon as the DMR receives a Next() action, the DMR must play the resource described in the NextAVTransportURI state variable. |
| Req. SETNEXT-10 |
| Applies to AV DMR, Audio DMR |
| If the DMR is playing an audio, A/V, or image resource and if the DMR receives a Next() action, the DMR must play the resource defined in the NextAVTransportURI state variable (if available). If the DMR receives a Next() action but the NextAVTransportURI state variable is empty, then the DMR must respond with error 401 (Invalid Action). This requirement does not apply if the DMR is playing a resource from media collections (DIDL_S, DIDL_V, or any other playlist file format) or PlayContainer operations. In the case of media collections or PlayContainer requests, DLNA defines the proper use of Next() and Previous() actions. These actions are used to traverse back and forth items in the collection or container. The current version of the Play To controller does not support media collections or PlayContainer operations. |
| Req. SETNEXT-15 |
| Applies to AV DMR, Audio DMR |
| If the DMR is playing an audio, A/V, or image resource and if the DMR receives a Stop() action, the DMR must stop playing the current resource. If the NextAVTransportURI state variable is non-empty, the DMR must not play the next resource. |
Design Notes
The UPnP AVTransport specifications define the use of the SetNextAVTransportURI() action. In general, this action can be used with audio and A/V resources with few additional clarifications. The use of this action for images is less clear in the UPnP AVTransport specifications. This document clarifies the use of such action. Specifically:
If a DMR receives a SetAVTransportURI() and a Play() action to play an image, the DMR plays the image for an indefinite time (see Requirement Device.Media.DMR.Image.JPEG).
At any time, the DMR can receive a SetNextAVTransportURI() action. This action conveys the URI of the next content item (images, A/V, or audio).
The controller needs to send a Next() action in order to trigger a change from the current image to the next item.
DLNA has clarified the use of the Next() action when used in the context of media collections (DIDL_S, DIDL_V, or any other type of playlist format) and also in the context of PlayContainer operations. The Previous() and Next() actions are used to play the previous and next items in the collection or in a container. However, DLNA acknowledges that the use of a Next() action for single resources is unspecified. This requirement clarifies the use of a Next() action when the device has acquired a resource URI that will be played after the current resource.
Additional Information
| Enforcement Date |
Mar. 01, 2012 |
Device.Media.DMR.Base.VolumeControl
DMR supports volume control
| Target Feature |
Device.Media.DMR.Base |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
| Req. VOLUME-01 |
| Applies to AV DMR, Audio DMR |
| A DMR device must support volume control requests from a Digital Media Controller and adjust the volume output accordingly. A DMC requests volume adjustments using the SetVolume() action with a level between 0 (silence) and 100 (loudest). A Digital Media Renderer needs not support volume control for channels other than the master channel. |
| Req. VOLUME-05 |
| Applies to AV DMR, Audio DMR |
| A DMR that receives a SetVolume() action must adjust the volume to the requested level while the DMR is in the following states: NO_MEDIA_PRESENT, STOPPED, PLAYING, PAUSED_PLAYBACK. |
| Req. VOLUME-10 |
| Applies to AV DMR, Audio DMR |
| A DMR must declare the implementation of the Volume state variable, the SetVolume() action, and the GetVolume() action in the Service Description Document. In particular, the allowed range value for the state variable must indicate a minimum of 0 and a maximum of 100. |
Design Notes
This requirement is in compliance with current UPnP specifications and DLNA Guidelines. DLNA tests for volume control but not in all applicable states.
Additional Information
| Enforcement Date |
Mar. 01, 2012 |
Device.Media.DMR.Base.WakeOnLAN
DMR supports Wake on LAN
| Target Feature |
Device.Media.DMR.Base |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
| Req. WOL-01 |
| Applies to AV DMR, Audio DMR |
| If a DMR implements a low power mode (sleep mode), the DMR must be capable of waking up to a normal power mode when it receives a Magic Packet. A Magic Packet is a broadcast UDP packet on port 0 with a payload that contains six bytes of 0xFF followed by the MAC address of the DMR repeated 16 times.Within 10 seconds of receiving a Magic Packet, the DMR must send an ssdp:alive message and be capable of accepting a connection. This requirement only applies to the wired Ethernet interface of a DMR. |
| Req. WOL-02 |
| Applies to AV DMR, Audio DMR |
| If a DMR implements a low power mode (sleep mode), the DMR must include the following XML fragment in its Device Description Document: <microsoft:magicPacketWakeSupported xmlns:microsoft="urn:schemas-microsoft-com:WMPNSS-1-0"> 1</microsoft:magicPacketWakeSupported>This requirement only applies to the wired Ethernet interface of a DMR. |
Design Notes
This requirement is necessary to allow communications with a DMR operating in a low power mode.For additional information on Wake-on-LAN see Network Device Class Power Management Reference Specification, Version 2.0, at https://go.microsoft.com/fwlink/?LinkId=40505. The XML fragment described in the requirement includes blank spaces for clarity. Any unnecessary spaces are removed when the fragment is inserted into a DDD document. Some devices implement multiple levels of low-power modes. In some levels, the device remains responsive to UPnP actions received over the network. In other levels the device no longer responds to UPnP actions. When a device no longer responds to UPnP actions, then the device is considered to be in "sleep mode." As defined in this specification, a device that enters a sleep mode needs to implement a Wake-On-LAN protocol because users expect their devices to wake up automatically when making connections.
Additional Information
| Exceptions |
If ImplementedIf the DMR implements a low power (sleep) mode, then it must satisfy this requirement. |
| Enforcement Date |
Mar. 01, 2012 |
Device.Media.DMR.Base.WiFiDirectSupport
Wi-Fi Direct support
| Target Feature |
Device.Media.DMR.Base |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
| Req. WFD-01 |
| Applies to AV DMR, Audio DMR |
| If a device implements Wi-Fi Direct, the DMR functionality must be available over the Wi-Fi Direct channel. All requirements described in this document remain valid when the DMR operates using a Wi-Fi Direct connection. |
Design Notes
Wi-Fi Direct is a new peer-to-peer connection technology that allows connections between endpoints without the need to use an intermediate access point.
Additional Information
| Exceptions |
If Implemented |
| Enforcement Date |
Mar. 01, 2012 |
Device.Media.DMR.Base.WMDRMNDLinkProtectionSupport
DMR supports WMDRM-ND link protection
| Target Feature |
Device.Media.DMR.Base |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
| Req. WMDRM-01 |
| Applies to AV DMR, Audio DMR |
| If a device implements WMDRM-ND, then the implementation must adhere to the DLNA Guidelines for WMDRM-ND Link Protection. |
| Req. WMDRM-05 |
| Applies to AV DMR, Audio DMR |
| If a device implements WMDRM-ND, then the implementation must decode and play all of the following audio profiles: WMDRM_WMALSL WMDRM_WMABASE WMDRM_WMAFULL |
| Req. WMDRM-10 |
| Applies to AV DMR |
| If a device implements WMDRM-ND, then the implementation must decode and play all of the following A/V profiles: WMDRM_WMVMED_BASE WMDRM_WMVMED_FULL WMDRM_WMVHIGH_FULL |
Design Notes
WMDRM-ND provides the protection necessary to stream high-value content from a PC to a device.
Additional Information
| Exceptions |
If ImplementedIf a Digital Media Renderer implements WMDRM-ND, then the device must comply with this requirement. |
| Enforcement Date |
Mar. 01, 2012 |
Device.Media.DMR.Image
Devices that can serve images need to implement these requirements
| Related Requirements |
Device.Media.DMR.Image.JPEG |
Device.Media.DMR.Image.JPEG
JPEG requirements for a DMR
| Target Feature |
Device.Media.DMR.Image |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
| Req. JPEG-01 |
| Applies to AV DMR, Audio DMR (if it play images) |
| A Digital Media Renderer that receives an action to play a valid JPEG image must play the image for an indefinite time. Hence, the Play To controller decides the playback duration for any image.This requirement applies while the device is active outside low-power mode. If the device enters low-power mode, this requirement no longer applies. This requirement only applies while the device operates in DMR mode. If the user changes the mode to watch television or optical disk content, the requirement no longer applies. |
Design Notes
A basic principle of DMR operation is that users interact with the controller UI and not with a UI that may be available in the DMR/DMP device. For this reason, the duration time should be defined by the controller and not by the DMR.
Additional Information
| Enforcement Date |
Mar. 01, 2012 |