UPnP Device and Service Templates:
Media Property and Compatibility Extensions
===========================================
Intellectual Property Rights Notice for Open Specifications
Documentation
*
Technical Documentation. Microsoft publishes Open Specifications
documentation for protocols, file formats, languages, standards as
well as overviews of the interaction among each of these
technologies.
*
Copyrights. This documentation is covered by Microsoft copyrights.
Regardless of any other terms that are contained in the terms of
use for the Microsoft website that hosts this documentation, you
may make copies of it in order to develop implementations of the
technologies described in the Open Specifications and may
distribute portions of it in your implementations using these
technologies or your documentation as necessary to properly
document the implementation. You may also distribute in your
implementation, with or without modification, any schema, IDL’s,
or code samples that are included in the documentation. This
permission also applies to any documents that are referenced in
the Open Specifications.
*
No Trade Secrets. Microsoft does not claim any trade secret rights
in this documentation.
*
Patents. Microsoft has patents that may cover your implementations
of the technologies described in the Open Specifications. Neither
this notice nor Microsoft's delivery of the documentation grants
any licenses under those or any other Microsoft patents. However,
a given Open Specification may be covered by Microsoft Open
Specification Promise or the Community Promise. If you would
prefer a written license, or if the technologies described in the
Open Specifications are not covered by the Open Specifications
Promise or Community Promise, as applicable, patent licenses are
available by contacting [email protected].
*
Trademarks. The names of companies and products contained in this
documentation may be covered by trademarks or similar intellectual
property rights. This notice does not grant any licenses under
those rights. For a list of Microsoft trademarks, visit
www.microsoft.com/trademarks.
*
Fictitious Names. The example companies, organizations, products,
domain names, email addresses, logos, people, places, and events
depicted in this documentation are fictitious. No association with
any real company, organization, product, domain name, email
address, logo, person, place, or event is intended or should be
inferred.
Reservation of Rights. All other rights are reserved, and this notice
does not grant any rights other than specifically described above,
whether by implication, estoppel, or otherwise.
Tools. The Open Specifications do not require the use of Microsoft
programming tools or programming environments in order for you to
develop an implementation. If you have access to Microsoft programming
tools and environments you are free to take advantage of them. Certain
Open Specifications are intended for use in conjunction with publicly
available standard specifications and network programming art, and
assumes that the reader either is familiar with the aforementioned
material or has immediate access to it.
Revision Summary
----------------
Date
Revision History
Revision Class
Comments
01/29/2010
0.1
Major
First Release.
03/12/2010
0.1.1
Editorial
Revised and edited the technical content.
04/23/2010
0.1.2
Editorial
Revised and edited the technical content.
06/04/2010
0.1.3
Editorial
Revised and edited the technical content.
07/16/2010
0.1.3
No change
No changes to the meaning, language, or formatting of the technical
content.
08/27/2010
1.0
Major
Significantly changed the technical content.
10/08/2010
1.0
No change
No changes to the meaning, language, or formatting of the technical
content.
11/19/2010
1.0
No change
No changes to the meaning, language, or formatting of the technical
content.
01/07/2011
1.0
No change
No changes to the meaning, language, or formatting of the technical
content.
02/11/2011
1.0
No change
No changes to the meaning, language, or formatting of the technical
content.
03/25/2011
1.0
No change
No changes to the meaning, language, or formatting of the technical
content.
05/06/2011
1.0
No change
No changes to the meaning, language, or formatting of the technical
content.
06/17/2011
1.1
Minor
Clarified the meaning of the technical content.
09/23/2011
1.1
No change
No changes to the meaning, language, or formatting of the technical
content.
12/16/2011
2.0
Major
Significantly changed the technical content.
03/30/2012
2.0
No change
No changes to the meaning, language, or formatting of the technical
content.
07/12/2012
2.0
No change
No changes to the meaning, language, or formatting of the technical
content.
10/25/2012
2.0
No change
No changes to the meaning, language, or formatting of the technical
content.
01/31/2013
2.0
No change
No changes to the meaning, language, or formatting of the technical
content.
08/08/2013
3.0
Major
Significantly changed the technical content.
11/14/2013
3.1
Minor
Clarified the meaning of the technical content.
02/13/2014
4.0
Major
Significantly changed the technical content.
Contents
1 Introduction 6
1.1 Glossary 6
1.2 References 7
1.2.1 Normative References 7
1.2.2 Informative References 7
1.3 Overview 8
1.4 Relationship to Protocols and Other Structures 8
1.5 Applicability Statement 9
1.6 Versioning and Localization 9
1.7 Vendor-Extensible Fields 9
2 Structures 10
2.1 MMPE 10
2.1.1 Artist Properties 10
2.1.1.1 artistAlbumArtist 10
2.1.1.2 artistPerformer 10
2.1.1.3 artistConductor 11
2.1.2 Author Properties 11
2.1.2.1 authorComposer 11
2.1.2.2 authorOriginalLyricist 11
2.1.2.3 authorWriter 11
2.1.3 Ratings Properties 12
2.1.3.1 userRating 12
2.1.3.2 userEffectiveRating 12
2.1.3.3 userRatingInStars 12
2.1.3.4 userEffectiveRatingInStars 13
2.1.4 serviceProvider 13
2.1.5 sourceURL 13
2.1.6 year 13
2.1.7 folderPath 14
2.1.8 fileIdentifier 14
2.2 MCEF 14
2.2.1 Compatibility Flag Values and Behaviors 14
2.2.1.1 WMC_COMPAT_EXCLUDE_HTTP 15
2.2.1.2 WMC_COMPAT_EXCLUDE_RTSP 15
2.2.1.3 WMC_COMPAT_EXCLUDE_DLNA 16
2.2.1.4 WMC_COMPAT_EXCLUDE_DLNA_1_5 17
2.2.1.5 WMC_COMPAT_EXCLUDE_PCMPARAMS 17
2.2.1.6 WMC_COMPAT_EXCLUDE_WMDRMND 17
2.2.1.7 WMC_COMPAT_INCLUDE_RTSP_FOR_VIDEO 18
2.2.1.8 WMC_COMPAT_EXCLUDE_WMALOSSLESS_NONTRANSCODED 18
2.2.1.9 WMC_COMPAT_EXCLUDE_SEARCH 18
2.2.1.10 WMC_COMPAT_DO_NOT_LIMIT_RESPONSE_SIZE 18
2.2.1.11 WMC_COMPAT_EXCLUDE_VIDEO_TRANSCODING 18
2.2.1.12 WMC_COMPAT_PLAYLIST_FAKECHILDCOUNT 18
2.2.1.13 WMC_COMPAT_EXCLUDE_NONPCM_AUDIO_TRANSCODING 19
2.2.1.14 WMC_COMPAT_EXCLUDE_TRANSCODING_TO_MPEG2 19
2.2.1.15 WMC_COMPAT_EXCLUDE_RES_FILTERING 19
2.3 MPME 19
2.3.1 Magic Packets 19
2.3.1.1 microsoft:magicPacketWakeSupported 19
2.3.1.2 microsoft:magicPacketSendSupported 20
2.4 Microsoft ProtocolInfo Extensions 20
2.4.1 PlayToApp Extension 20
3 Structure Examples 21
3.1 MMPE Examples 21
3.1.1 Artist Properties Tags 21
3.1.2 Author Properties Tags 21
3.1.3 Ratings Properties Tags 21
3.1.4 serviceProvider Property Tag 21
3.1.5 year Property Tag 22
3.1.6 folderPath Property Tag 22
3.1.7 fileIdentifier Property Tag 22
3.2 MCEF Examples 22
3.2.1 X_DeviceCaps Example 22
3.3 MPME Examples 23
3.3.1 magicPacketWakeSupported 23
3.3.2 magicPacketSendSupported 23
3.4 Microsoft ProtocolInfo Extensions Examples 23
3.4.1 PlayToApp Extension 23
4 Security Considerations 24
5 Appendix A: Product Behavior 25
6 Change Tracking 26
7 Index 28
1 Introduction
--------------
This document defines the Microsoft Media Property Extensions (MMPE),
the Microsoft Compatibility Extension Flags (MCEF), the Microsoft
Power Management Extensions (MPME), and the Microsoft ProtocolInfo
Extensions. These flags and extensions extend the Universal Plug and
Play (UPnP) interoperability guidelines, as specified by the UPnP
Forum [UPnP] and used by the Digital Living Network Alliance (DLNA)
[DLNA].
Sections 1.7 and 2 of this specification are normative and can contain
the terms MAY, SHOULD, MUST, MUST NOT, and SHOULD NOT as defined in
RFC 2119. All other sections and examples in this specification are
informative.
1.1 Glossary
The following terms are defined in [MS-GLOS]:
Hypertext Transfer Protocol (HTTP)
Universal Plug and Play (UPnP)
UTF-8
XML
The following terms are specific to this document:
device description document (DDD): A document used to specify device
information and its capabilities, as described in the UPnP standard
[UPnP].
digital item declaration language (DIDL-Lite): A subset of the Digital
Item Declaration Language (DIDL), which is an XML dialect developed
within ISO/MPEG21 [MPEG-21].
Digital Living Network Alliance (DLNA): A cross-industry organization
of leading consumer electronics, computing industry, and mobile device
companies, which are focused on delivering interoperability guidelines,
based upon open industry standards, in order to complete the
cross-industry digital convergence.
digital media player (DMP): A Device Class that is defined in the DLNA
guidelines. A DMP implements an UPnP AV control point that issues
actions to a DMS with unexposed DMR functionality.
digital media reader (DMR): A Device Class that is defined in the DLNA
guidelines. A DMR is a UPnP Device that implements the UPnP
MediaRenderer Device type.
digital media server (DMS): A Device Class that is defined in the DLNA
guidelines. A DMS is a UPnP Device that implements the UPnP
MediaServer Device type.
DLNA guidelines: The DLNA Networked Device Interoperability Guidelines
[DLNA] consist of three volumes that provide vendors with the
information required to build interoperable networked platforms and
devices for the digital home, including architecture and protocols,
profiles for media formats, and link protection.
Microsoft Compatibility Extension Flags (MCEF): Flags provided by DMRs
and DMPs to filter specific res elements exposed to these devices.
Microsoft Media Property Extensions (MMPE): Additional metadata
properties that describe a media item that further enriches the
metadata properties defined by [UPnP].
Microsoft Power Management Extensions (MPME): XML tags used to
communicate the devices support of magic packets.
Microsoft ProtocolInfo Extensions: Extensions to the ProtocolInfo
syntax, defined by Microsoft.
ProtocolInfo: As specified in [UPNPCNMGR] section 2.5.2.
Real-Time Streaming Protocol (RTSP): As specified in [RFC2326].
res: Identifies a resource. A resource is typically some type of a
binary asset, such as a photo, song, video, etc. A res element
contains an URI that identifies the resource.
MAY, SHOULD, MUST, SHOULD NOT, MUST NOT: These terms (in all caps) are
used as described in [RFC2119]. All statements of optional behavior
use either MAY, SHOULD, or SHOULD NOT.
1.2 References
References to Microsoft Open Specifications documentation do not
include a publishing year because links are to the latest version of
the documents, which are updated frequently. References to other
documents include a publishing year when one is available.
A reference marked "(Archived)" means that the reference document was
either retired and is no longer being maintained or was replaced with
a new document that provides current implementation details. We
archive our documents online [Windows Protocol].
1.2.1 Normative References
We conduct frequent surveys of the normative references to assure
their continued availability. If you have any issue with finding a
normative reference, please contact [email protected]. We will
assist you in finding the relevant information.
[DLNA] Digital Living Network Alliance, "The DLNA Networked Device
Interoperability Guidelines",
http://www.dlna.org/dlna-for-industry/about-dlna/guidelines
Note There is a charge to download the specification.
[MS-DTYP] Microsoft Corporation, "Windows Data Types".
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997,
http://www.rfc-editor.org/rfc/rfc2119.txt
[RFC3629] Yergeau, F., "UTF-8, A Transformation Format of ISO 10646",
STD 63, RFC 3629, November 2003, http://www.ietf.org/rfc/rfc3629.txt
[RFC5234] Crocker, D., Ed., and Overell, P., "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008,
http://www.rfc-editor.org/rfc/rfc5234.txt
[UPnP] UPnP Forum, "Standards",
http://www.upnp.org/standardizeddcps/default.asp
[XML10] World Wide Web Consortium, "Extensible Markup Language (XML)
1.0 (Third Edition)", February 2004,
http://www.w3.org/TR/2004/REC-xml-20040204/
1.2.2 Informative References
[MPEG-21] Various, "ISO/IEC 21000 - Multimedia framework (MPEG-21)",
http://www.upnp.org/schemas/av/didl-lite-v2.xsd
[MS-DLNHND] Microsoft Corporation, "Digital Living Network Alliance
(DLNA) Networked Device Interoperability Guidelines: Microsoft
Extensions".
[MS-GLOS] Microsoft Corporation, "Windows Protocols Master Glossary".
[RFC2326] Schulzrinne, H., Rao, A., and Lanphier, R., "Real Time
Streaming Protocol (RTSP)", RFC 2326, April 1998,
http://www.ietf.org/rfc/rfc2326.txt
[UPNPARCH1] UPnP Forum, "UPnP Device Architecture 1.0", October 2008,
http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.0.pdf
[UPNPCDS1] UPnP Forum, "ContentDirectory:1 Service Template Version
1.01", June 2002,
http://www.upnp.org/standardizeddcps/documents/ContentDirectory1.0.pdf
[UPNPCNMGR] UPnP Forum, "ConnectionManager:1 Service Template Versions
1.01", June 2002,
http://www.upnp.org/standardizeddcps/documents/ConnectionManager1.0.pdf
1.3 Overview
Microsoft Compatibility Extension Flags (MCEF) are used to request
specific device behavior(s) to enhance interoperability among UPnP
Devices. For example, device manufacturers can develop a UPnP capable
network device in order to retrieve information about the media
content that is exposed to the network by a digital media server (DMS).
Such a device is enabled to include the MCEFs in its device
description document (DDD) or User-Agent Header in order to tailor the
metadata attributes in the XML responses that are provided by the DMS
during interaction for enhanced interoperability.
Microsoft Media Property Extensions (MMPE) are used to expose several
media content properties that are defined by Microsoft. These
properties are generally not expressible, or are difficult to express,
with the existing UPnP metadata attributes. In order to provide the
expected query results with the existing attributes, additional
processing capabilities are required on the device. For example, by
using the additional properties defined by Microsoft, the device is
relieved of the "heavy-lifting" involved in generating similar results
and is enabled to provide a richer media browsing experience to their
users.
Microsoft Power Management Extensions (MPME) are used to expose UPnP
Device capabilities for power management. For example, a UPnP Device
can support sleep mode and accept wake requests from other UPnP
Devices. At the same time, a UPnP Device can support waking other UPnP
Devices.
The Microsoft ProtocolInfo Extensions are extensions to the
ProtocolInfo, defined by Microsoft. For example, a digital media
reader (DMR) can use the PlayToApp extension (section 2.4.1) to
indicate that it supports a nonstandard URI scheme.
1.4 Relationship to Protocols and Other Structures
MMPE are extensions to the XML syntax called DIDL-Lite, which are
defined in the UPnP ContentDirectory service specification. For more
information, see [UPNPCDS1] Appendix A.
MPME are extensions to the XML syntax for UPnP DDDs. The DDDs are
defined in [UPNPARCH1] section 2.1.
MMPE, MCEF, and MPME can be used in implementations of the Digital
Living Network Alliance (DLNA) Home Networked Device Interoperability
Guidelines: Microsoft Extensions [MS-DLNHND].
1.5 Applicability Statement
The MMPE and MCEF are only applicable to implementations of the
Microsoft Extensions to the Digital Living Network Alliance (DLNA)
Home Networked Device Interoperability Guidelines [MS-DLNHND].
The MPME is only applicable to implementations of the Microsoft
Extensions to the Digital Living Network Alliance (DLNA) Home
Networked Device Interoperability Guidelines.
Implementations of the MMPE and/or MCEF and/or MPME are not required
in order to interoperate with Windows. The Media Property and
Compatibility Extensions enhance the Digital Living Network Alliance
(DLNA) Home Networked Device Interoperability Guidelines and the
Remote Media Streaming Initiation Protocol without breaking
interoperability.
Implementers are recommended to consider whether or not the MMPE
and/or MCEF and/or MPME are applicable to their scenarios in order to
provide a richer multimedia experience.
1.6 Versioning and Localization
The MMPE, MCEF, and MPME do not support versioning.
The MMPE, MCEF, and MPME do not explicitly address localization.
However, these Microsoft Extensions use the UTF-8 character set, as
specified in [DLNA] section 7.2.5.9 and [RFC3629].
1.7 Vendor-Extensible Fields
None.
2 Structures
------------
This protocol references commonly used data types, as defined in
[MS-DTYP].
2.1 MMPE
Each MMPE is a property that describes a media item, where all but one
of the properties can be included in a DIDL-Lite XML document. In the
case of the property that is not included, the name of the property is
used as the name of an XML tag that is included within a
tag, which itself is included within an
of the tags associated with the media item.
The properties can also be specified as input parameters to the UPnP
ContentDirectory [UPNPCDS1] service Search and Browse actions,
wherever those actions allow properties to be used. For example, the
ContentDirectory service Search action allows property names to be
used to formulate a search query.
The sourceURL property (section 2.1.5) cannot appear in DIDL-Lite
The XML tags MUST follow the syntax rules for XML defined in [XML10].
Unless otherwise specified, any characters in the value of an XML tag
MUST be escaped, using the XML escaping mechanism defined in [XML10]
section 2.4.
The syntax of each tag is specified using ABNF [RFC5234].
2.1.1 Artist Properties
A group of XML properties that supports various artist roles, which is
included in the multimedia content, such as album artist, performer
(also known as a contributing artist), and conductor. Support for the
artist properties enables devices to provide results for queries such
as "browse by performer, and then find albums by the selected
performer".
2.1.1.1 artistAlbumArtist
This property specifies the name of an artist that is listed on the
album when the media item is part of an album (i.e., a music album).
For some albums, the name of the album artist can differ from the name
of the artist of individual songs.
Multiple instances of this property are allowed.
The syntax of the property is defined as follows:
PropertyName = "microsoft:artistAlbumArtist"; UTF-8
PropertyValue = ALPHA; UTF-8
MMPE = "<" PropertyName ">" PropertyValue "";
2.1.1.2 artistPerformer
This property specifies the name of a performing artist that is
associated with the media item.
Multiple instances of this property are allowed.
The syntax of the property is defined as follows:
PropertyName = "microsoft:artistPerformer"; UTF-8
PropertyValue = ALPHA; UTF-8
MMPE = "<" PropertyName ">" PropertyValue "";
2.1.1.3 artistConductor
This property specifies the name of a conductor (typically, a musical
conductor) that is associated with the media item.
Multiple instances of this property are allowed.
The syntax of the property is defined as follows:
PropertyName = "microsoft:artistConductor"; UTF-8
PropertyValue = ALPHA; UTF-8
MMPE = "<" PropertyName ">" PropertyValue "";
2.1.2 Author Properties
A group of properties that supports various roles that one or more
authors can have in multimedia content: Composer, Original Lyricist,
or Writer. Support for the Author attributes enables devices to
provide results for queries such as "browse by composer, and then find
genres for the selected composer".
2.1.2.1 authorComposer
Specifies the name of a composer (typically, a musical composer) that
is associated with the media item.
Multiple instances of this property are allowed.
The syntax of the property is defined as follows:
PropertyName = "microsoft:authorComposer"; UTF-8
PropertyValue = ALPHA; UTF-8
MMPE = "<" PropertyName ">" PropertyValue "";
2.1.2.2 authorOriginalLyricist
This property specifies the name of a person who created the original
lyrics of the media item.
Multiple instances of this property are allowed.
The syntax of the property is defined as follows:
PropertyName = "microsoft:authorOriginalLyricist"; UTF-8
PropertyValue = ALPHA; UTF-8
MMPE = "<" PropertyName ">" PropertyValue "";
2.1.2.3 authorWriter
This property specifies the name of a person who is considered the
writer of the media item.
Multiple instances of this property are allowed.
The syntax of the property is defined as follows:
PropertyName = "microsoft:authorWriter"; UTF-8
PropertyValue = ALPHA; UTF-8
MMPE = "<" PropertyName ">" PropertyValue "";
2.1.3 Ratings Properties
The Ratings properties support metadata that is supplied from both the
user and from the metadata provider. These properties allow devices to
provide "prioritized" or "scoped" results to end users based on their
preferences. This enables a user, for example, to choose to browse
only musical content that has been rated at "5 or more stars".
There are four Ratings-related properties:
userRating and userEffectiveRating represent the user rating (if
present) and an automatic rating, respectively. The values of the
userRating and userEffectiveRating properties are expressed as a
number, in the range between 0 and 99, inclusive.
userRatingInStars and userEffectiveRatingInStars represent the same
information as userRating and userEffectiveRating, respectively. The
values of the userRatingInStars and userEffectiveRatingInStars
properties are expressed as a number, in the range between 0 and 5,
inclusive.
At most, one instance of each property is allowed.
2.1.3.1 userRating
The syntax of the property is defined as follows:
PropertyName = "microsoft:userRating"; UTF-8
PropertyValue = 1*2DIGIT; unsigned integer ranges from 0 to 99
MMPE = "<" PropertyName ">" PropertyValue "";
2.1.3.2 userEffectiveRating
The syntax of the property is defined as follows:
PropertyName = "microsoft:userEffectiveRating"; UTF-8
PropertyValue = 1*2DIGIT; unsigned integer ranges from 0 to 99
MMPE = "<" PropertyName ">" PropertyValue "";
2.1.3.3 userRatingInStars
The syntax of the property is defined as follows:
PropertyName = "microsoft:userRatingInStars"; UTF-8
PropertyValue = "0" / "1" / "2" / "3" / "4" / "5"; unsigned integer
ranges from 0 to 5
MMPE = "<" PropertyName ">" PropertyValue "";
2.1.3.4 userEffectiveRatingInStars
The syntax of the property is defined as follows:
PropertyName = "microsoft:userEffectiveRatingInStars"; UTF-8
PropertyValue = "0" / "1" / "2" / "3" / "4" / "5"; unsigned integer
ranges from 0 to 5
MMPE = "<" PropertyName ">" PropertyValue "";
2.1.4 serviceProvider
The serviceProvider property represents the name of the distributor of
the media item. The serviceProvider property allows devices to return
results categorized by the entity that provided the content.
Multiple instances of this property are allowed.
The syntax of the property is defined as follows:
PropertyName = "microsoft:serviceProvider"; UTF-8
PropertyValue = ALPHA; UTF-8
MMPE = "<" PropertyName ">" PropertyValue "";
2.1.5 sourceURL
The sourceURL property supports the grouping of results by file system
path, which enables a device to group media files by parent folder.
For example, the device can return results that enumerate all of the
pictures in the "January Ski Trip to Canada" folder.
Note The use of the "ParentID" attribute can provide results similar
to sourceURL, but only for a container hierarchy that replicates the
file system hierarchy.
At most, one instance of each property is allowed.
The syntax of the property is defined as follows:
PropertyName = "microsoft:sourceURL"; UTF-8
PropertyValue = ALPHA; UTF-8
MMPE = "<" PropertyName ">" PropertyValue "";
2.1.6 year
The year property enables the organization of multimedia content based
solely on year, whereas the commonly-used "dc:date" UPnP property
provides the whole date. For example, use of the year property enables
a device to more easily return results for all of the pictures taken
in "2006".
The syntax of the property is defined as follows:
PropertyName = "microsoft:year"; UTF-8
PropertyValue = 4DIGIT; unsigned integer, format YYYY
MMPE = "<" PropertyName ">" PropertyValue "";
2.1.7 folderPath
The folderPath property represents a folder path to the media item,
relative to a root folder.
At most, one instance of each property is allowed.
The syntax of the property is defined as follows:
PropertyName = "microsoft:folderPath"; UTF-8
PropertyValue = ALPHA; UTF-8
MMPE = "<" PropertyName ">" PropertyValue "";
2.1.8 fileIdentifier
The fileIdentifier property is obtained from the media file. The
property is assigned by the creator of the media file.<1>
For example, if the same file is shared by two different DMS
implementations, although the value of the "id" attribute on the
"item" property can be different on each DMS, the value of the
fileIdentifier property is the same, since the value is obtained from
the file itself.
At most, one instance of each property is allowed.
The syntax of the property is defined as follows:
PropertyName = "microsoft:fileIdentifier"; UTF-8
PropertyValue = ALPHA; UTF-8
MMPE = "<" PropertyName ">" PropertyValue "";
2.2 MCEF
MCEFs are used to define specific behavior(s) for a particular device
in order to enhance interoperability. The flags can be provided by a
DMP, or digital media reader (DMR) via its User-Agent header, as
described in [MS-DLNHND] or its DDD, as defined in [UPNPARCH1] section
2.1. To provide the flag, the device MUST specify the
Microsoft-defined microsoft:X_DeviceCaps tag within the Device node of
the DDD, as shown in section 3.2.1. The syntax to follow for this tag
is specified using ABNF [RFC5234], as follows:
CompatibilityFlag= 1*DIGIT; it is the decimal numerical representation
of the bitwise-OR operation among the hexadecimal flags used, as
defined in section 2.2.1;
Note The Microsoft-defined microsoft:X_DeviceCaps attribute does not
change in any respect the manner regarding how DDDs are made available
to other devices in the network as, described by [UPNPARCH1].
2.2.1 Compatibility Flag Values and Behaviors
Any flag value that is not documented in this section is considered
reserved and SHOULD not be used.
2.2.1.1 WMC_COMPAT_EXCLUDE_HTTP
This flag causes a DMS to exclude res and upnp:albumArtURI elements in
the DIDL-Lite response of the Browse or Search UPnP actions that
implement the HTTP protocol in their URLs, as specified in [UPnP].
Value: %x1
This flag affects the response of UPnP Actions:
ContentDirectory:Browse, ContentDirectory:Search, and
ConnectionManager:GetProtocolInfo.
sampleFrequency="44100" bitsPerSample="16" nrAudioChannels="2"
microsoft:codec="{00000055-0000-0010-8000-00AA00389B71}"
xmlns:microsoft="urn:schemas-microsoft-com:WMPNSS-1-0/">http://127.0.0.1:10243/WMPNSSv4/2815481477/0_ezI0OTI3N0I5LUU2MUQtNDdEMi05MTI3LTJBNjFDOTFGM0M5N30uMC40.mp3
When this flag is specified, the value of the protocolInfo attribute,
as defined in [UPNPCDS1] section 6, on res elements, only specifies
non-HTTP transport-dependent formats. Any res element with a
protocolInfo attribute whose value begins with an "http-get" MUST be
excluded from the response. For more information regarding the syntax
of the ProtocolInfo string, see [UPNPCNMGR].
Note This flag MUST NOT be used in combination with
WMC_COMPAT_EXCLUDE_RTSP.
2.2.1.2 WMC_COMPAT_EXCLUDE_RTSP
This flag causes a DMS to exclude res elements in the DIDL-Lite
response of the Browse or Search UPnP actions that implement the RTSP
protocol in their URLs, as specified by [UPnP]. Elements in the
DIDL-Lite response, as demonstrated in the following syntax block,
MUST be removed with the use of this flag.
Value: %x2
This flag affects the response of UPnP Actions:
ContentDirectory:Browse, ContentDirectory:Search, and
ConnectionManager:GetProtocolInfo.
sampleFrequency="44100" bitsPerSample="16" nrAudioChannels="2"
microsoft:codec="{00000055-0000-0010-8000-00AA00389B71}"
xmlns:microsoft="urn:schemas-microsoft-com:WMPNSS-1-0/">rtsp://127.0.0.1:554/WMPNSSv4/2815481477/0_ezI0OTI3N0I5LUU2MUQtNDdEMi05MTI3LTJBNjFDOTFGM0M5N30uMC40.mp3
A consequence of constructing the DIDL-Lite response as shown in this
example is that the value of the protocolInfo attribute, as defined in
[UPNPCDS1] section 6, on res elements MUST specify only non-RTSP
transport-dependent formats. Any res element with a protocolInfo
attribute whose value begins with "rtsp-rtp-udp" MUST be excluded from
the response. For more information regarding the syntax of the
ProtocolInfo string, see [UPNPCNMGR].
Note This flag MUST NOT be used in combination with
WMC_COMPAT_EXCLUDE_HTTP because at least one protocol (either HTTP or
RTSP) SHOULD be enabled. This flag MUST NOT be used in combination
with WMC_COMPAT_INCLUDE_RTSP_FOR_VIDEO.
2.2.1.3 WMC_COMPAT_EXCLUDE_DLNA
This flag causes a DMS to exclude all DLNA-defined attributes and
parameters in the DIDL-Lite responses given by the Browse or Search
UPnP actions, as specified by [UPnP].
Value: %x4
This flag affects the response of UPnP Actions:
ContentDirectory:Browse, ContentDirectory:Search, and
ConnectionManager:GetProtocolInfo.
Note The dlna:profileID and xmlns:dlna attributes MUST NOT be
included in the upnp:albumArtURI nodes.
The following content feature flags MUST also be removed from the
protocolInfo attribute, as defined in [UPNPCDS1] section 6, of res
elements:
DLNA.ORG_PN
DLNA.ORG_OP
DLNA.ORG_PS
DLNA.ORG_CI
DLNA.ORG_FLAGS
DLNA.ORG_MAXSP
sampleFrequency="44100" bitsPerSample="16" nrAudioChannels="2"
microsoft:codec="{00000055-0000-0010-8000-00AA00389B71}"
xmlns:microsoft="urn:schemas-microsoft-com:WMPNSS-1-0/">http://127.0.0.1:10243/WMPNSSv4/2815481477/0_ezI0OTI3N0I5LUU2MUQtNDdEMi05MTI3LTJBNjFDOTFGM0M5N30uMC40.mp3
Because some devices fall down if the string DLNA exists in the
protocol response, the WMC_COMPAT_EXCLUDE_DLNA_1_5 compatibility flag
MUST be set to indicate that the specified attributes have not been
included in the upnp:albumArtURI and res nodes. Setting this
compatibility flag causes the server to not include the DLNA string as
specified in the XML response.
Moreover, because DLNA support is non-existent if the
WMC_COMPAT_INCLUDE_RTSP_FOR_VIDEO flag has been set, it MUST be
ignored. By setting this flag, RTSP-based URLs will be excluded from
res nodes in the case of video content.
Note In order to preserve backwards compatibility, when the
WMC_COMPAT_EXCLUDE_RTSP flag is included within the descriptor
tag, it can be escaped as described in [MS-DLNHND] section 3.4.5.1.
In the case of the UPnP action ConnectionManager:GetProtocolInfo, all
format support information MUST NOT contain protocol information that
announces DLNA profiles, as specified in [DLNA].
http-get:*:audio/x-ms-wma:DLNA.ORG_PN=WMABASE
Note The XML tags can be escaped, as described in section 3.1 of this
document, when this compatibility flag is used.
2.2.1.4 WMC_COMPAT_EXCLUDE_DLNA_1_5
This flag causes a DMS to map the DLNA Profile ID "MP3X" to "MP3", and
to map the DLNA Profile IDs "WMVSPLL_BASE" and "WMVSPML_BASE" to
"WMVMED_BASE". In addition, this flag causes the DLNA Profile ID for
any media item whose DLNA Profile ID begins with "WMDRM_" to be
omitted. When this flag is used, all URLs MUST have a file extension,
such as ".mp3" for MP3 content and ".pcm" for LPCM content.
Value: %x8
This flag affects the response of UPnP Actions:
ContentDirectory:Browse, ContentDirectory:Search, and
ConnectionManager:GetProtocolInfo.
sampleFrequency="44100" bitsPerSample="16" nrAudioChannels="2"
microsoft:codec="{00000055-0000-0010-8000-00AA00389B71}"
xmlns:microsoft="urn:schemas-microsoft-com:WMPNSS-1-0/">http://127.0.0.1:10243/WMPNSSv4/2815481477/1_ezI0OTI3N0I5LUU2MUQtNDdEMi05MTI3LTJBNjFDOTFGM0M5N30uMC40.mp3
Note The XML tags can be escaped, as described in section 3.1 of this
document, when this compatibility flag is used.
2.2.1.5 WMC_COMPAT_EXCLUDE_PCMPARAMS
This flag causes a DMS to exclude sample rate and channels information
from the protocolInfo attribute in the res element for audio/L16 and
audio/L8 MIME types.
Value: %x10
This flag affects the response of UPnP Actions:
ContentDirectory:Browse and ContentDirectory:Search.
sampleFrequency="44100" bitsPerSample="16" nrAudioChannels="2"
microsoft:codec="{00000001-0000-0010-8000-00AA00389B71}"
xmlns:microsoft="urn:schemas-microsoft-com:WMPNSS-1-0/">http://127.0.0.1:10243/WMPNSSv4/2815481477/ezI0OTI3N0I5LUU2MUQtNDdEMi05MTI3LTJBNjFDOTFGM0M5N30uMC40?formatID=20
2.2.1.6 WMC_COMPAT_EXCLUDE_WMDRMND
This flag causes a DMS to not generate res tags where the URL requires
the use of WMDRM-ND.
Value: %x20
This flag affects the response of UPnP Actions:
ContentDirectory:Browse and ContentDirectory:Search.
2.2.1.7 WMC_COMPAT_INCLUDE_RTSP_FOR_VIDEO
This flag causes a DMS to include res tags with RTSP-based URLs for
video even if WMC_COMPAT_EXCLUDE_RTSP and/or
WMC_COMPAT_EXCLUDE_DLNA_1_5 are set.
Value: %x40
This flag affects the response of UPnP Actions:
ContentDirectory:Browse and ContentDirectory:Search.
2.2.1.8 WMC_COMPAT_EXCLUDE_WMALOSSLESS_NONTRANSCODED
This flag causes a DMS to not generate res tags with URLs for
non-transcoded WMA Lossless content. This flag MUST be ignored if used
in combination with WMC_COMPAT_EXCLUDE_RES_FILTERING.
Value: %x80
This flag affects the response of UPnP Actions:
ContentDirectory:Browse and ContentDirectory:Search.
2.2.1.9 WMC_COMPAT_EXCLUDE_SEARCH
This flag causes the ContentDirectory:Search UPnP action to not be
supported for this DMS. In order to accomplish this action,
ContentDirectory:GetSearchCapabilities MUST NOT provide any search
capabilities.
Value: %x100
This flag affects the response of UPnP Actions:
ContentDirectory:Search and ContentDirectory:GetSearchCapabilities.
2.2.1.10 WMC_COMPAT_DO_NOT_LIMIT_RESPONSE_SIZE
This flag causes the DIDL-Lite responses to not be limited to 200 kB
in size for these UPnP actions.
Value: %x400
This flag affects the response of UPnP Actions:
ContentDirectory:Browse and ContentDirectory:Search.
2.2.1.11 WMC_COMPAT_EXCLUDE_VIDEO_TRANSCODING
This flag causes a DMS to not offer res tags with URLs that correspond
to transcoded versions of video items. This flag MUST be ignored if
used in combination with WMC_COMPAT_EXCLUDE_RES_FILTERING.
Value: %x800
This flag affects the response of UPnP Actions:
ContentDirectory:Browse and ContentDirectory:Search.
2.2.1.12 WMC_COMPAT_PLAYLIST_FAKECHILDCOUNT
This flag causes a value of "1" to be returned for the child count of
playlists containers. This flag is used to counteract the reduction in
performance caused by calculating the "real" child count for playlist
container.
Value: %x1000
This flag affects the response of UPnP Actions:
ContentDirectory:Browse and ContentDirectory:Search.
2.2.1.13 WMC_COMPAT_EXCLUDE_NONPCM_AUDIO_TRANSCODING
This flag causes res tags with URLs that correspond to transcoded
versions of audio items to not be offered, unless the res tag is for
an audio item transcoded into LPCM. This flag MUST be ignored if used
in combination with WMC_COMPAT_EXCLUDE_RES_FILTERING.
Value: %x2000
This flag affects the response of UPnP Actions:
ContentDirectory:Browse and ContentDirectory:Search.
2.2.1.14 WMC_COMPAT_EXCLUDE_TRANSCODING_TO_MPEG2
This flag causes res tags with URLs that correspond to transcoded
versions of video items into the MPEG-2 format to not be offered. This
flag MUST be ignored if used in combination with
WMC_COMPAT_EXCLUDE_RES_FILTERING.
Value: %x4000
This flag affects the response of UPnP Actions:
ContentDirectory:Browse and ContentDirectory:Search.
2.2.1.15 WMC_COMPAT_EXCLUDE_RES_FILTERING
All DIDL-Lite responses from a DMS MUST contain all applicable
transcoding res elements associated to the requested media.
Value: %x8000
This flag affects the response of UPnP Actions:
ContentDirectory:Browse and ContentDirectory:Search.
2.3 MPME
MPMEs are used to signal support for specific behaviors for a
particular device in order to enhance power management. The MPME XML
tags can be provided by a DMR or a DMS in its DDD, as described in
[UPNPARCH1] section 2.1. This section defines the MPME XML tags.
2.3.1 Magic Packets
This section defines MPME XML tags for indicating support for magic
packets. For more information about magic packets, see [MS-DLNHND]
section 2.2.5.
2.3.1.1 microsoft:magicPacketWakeSupported
This is an XML tag that a UPnP device provides in its DDD to announce
that it can be awakened by the use of a magic packet.<2>
For more information about the syntax of magic packet, see [MS-DLNHND]
section 2.2.5.
An UPnP device MUST only provide this information if it implements a
low power mode of operation.
An UPnP device that can be woken from a low power mode MUST provide
the following tag in its DDD:
flag = "1" / "0"; true or false, respectively.
2.3.1.2 microsoft:magicPacketSendSupported
This is an XML tag that a UPnP device provides in its DDD to announce
whether the device is able to wake a sleeping UPnP device.<3> The
following syntax shows how the element is used to announce this
capability.
flag = "1" / "0"; true or false respectively.
2.4 Microsoft ProtocolInfo Extensions
The Microsoft ProtocolInfo Extensions extend the syntax of the
ProtocolInfo syntax element, as described in [UPNPCNMGR] section
2.5.2.
2.4.1 PlayToApp Extension
The PlayToApp ProtocolInfo extension can be used by DMR devices to
specify support for additional URI schemes beyond those defined in
[UPNPCNMGR] sections 5.1.1 through 5.1.4.<4>
The PlayToApp ProtocolInfo extension adheres to the extension
mechanism for ProtocolInfo as defined in [UPNPCNMGR] section 5.1.5.
The syntax of the extension is defined as follows:
CustomURIScheme = 1*( ALPHA / DIGIT / "-" )
Protocol = "microsoft.com"
Network = "*"
ContentFormat = "application/vnd.ms-playtoapp;target=" DQUOTE
CustomURIScheme DQUOTE
AdditionalInfo = "*"
PlayToApp = Protocol ":" Network ":" ContentFormat ":" AdditionalInfo
3 Structure Examples
--------------------
3.1 MMPE Examples
In order to preserve backwards compatibility, XML tags inside the
descriptor
[MS-DLNHND] section 3.4.5.1. For example,
"
"<microsoft:artistAlbumArtist>" in the XML response.
3.1.1 Artist Properties Tags
The following is an example of the usage of the Artist properties in
an XML response:
3.1.2 Author Properties Tags
The following is an example of the usage of the Author properties in
an XML response:
3.1.3 Ratings Properties Tags
The following is an example of the usage of the Ratings properties in
an XML response:
xmlns:microsoft="urn:schemas-microsoft-com:WMPNSS-1-0/">
3.1.4 serviceProvider Property Tag
The following is an example of the usage of the serviceProvider
property in an XML response:
xmlns:microsoft="urn:schemas-microsoft-com:WMPNSS-1-0/">
Provider
3.1.5 year Property Tag
The following is an example of the usage of the year property in an
XML response:
3.1.6 folderPath Property Tag
The following is an example of the usage of the folderPath property in
an XML response: <5>
xmlns:microsoft="urn:schemas-microsoft-com:WMPNSS-1-0/">
3.1.7 fileIdentifier Property Tag
The following is an example of the usage of the fileIdentifier
property (section 2.1.8) in an XML response:
78327;X_id={5E8A0C00-0500-11DB-89CA-0019B92A3933};XA_id={F7310100-0400-11DB-89CA-0019B92A3933};XAP_id={88120000-0600-11DB-89CA-0019B92A3933}
3.2 MCEF Examples
3.2.1 X_DeviceCaps Example
Device compatibility flags are specified in a DDD by using the
following format:
...
Use of microsoft:X_DeviceCaps requires that the Microsoft XML
namespace (urn:schemas-microsoft-com:WMPNSS-1-0) be specified in the
DDD. The value for microsoft:X_DeviceCaps is given in decimal and
represents a bitwise OR combination of the individual compatibility
flag values described in section 2.2. In this example, the value of
"94" for microsoft:X_DeviceCaps indicates the following compatibility
flags:
WMC_COMPAT_EXCLUDE_RTSP
WMC_COMPAT_EXCLUDE_DLNA
WMC_COMPAT_EXCLUDE_DLNA_1_5
WMC_COMPAT_EXCLUDE_PCMPARAMS
WMC_COMPAT_INCLUDE_RTSP_FOR_VIDEO
3.3 MPME Examples
3.3.1 magicPacketWakeSupported
The following example shows a DDD that announces that the UPnP device
supports microsoft:magicPacketWakeSupported (section 2.3.1.1). <6>
...
3.3.2 magicPacketSendSupported
The following example shows a DDD that announces that the UPnP device
supports microsoft:magicPacketSendSupported (section 2.3.1.2). <7>
...
3.4 Microsoft ProtocolInfo Extensions Examples
3.4.1 PlayToApp Extension
The following example shows a ProtocolInfo string (section 2.4.1) that
a DMR device can include in its SinkProtocolInfo state variable ([UPNPCNMGR]
section 2.2.2) to declare that it supports playing media using the
"example://" URI schemes.
microsoft.com:*:application/vnd.ms-playtoapp;target="example":*
4 Security Considerations
-------------------------
The MMPE and MCEF do not introduce any new security considerations
beyond those that already apply to XML-based formats. Therefore, the
same security considerations that pertain to the UPnP and DLNA
guidelines also apply.
5 Appendix A: Product Behavior
------------------------------
The information in this specification is applicable to the following
Microsoft products or supplemental software. References to product
versions include released service packs:
Windows Vista operating system
Windows 7 operating system
Windows Home Server 2011 server software
Windows 8 operating system
Windows Server 2012 operating system
Windows 8.1 operating system
Windows Server 2012 R2 operating system
Exceptions, if any, are noted below. If a service pack or Quick Fix
Engineering (QFE) number appears with the product version, behavior
changed in that service pack or QFE. The new behavior also applies to
subsequent service packs of the product unless otherwise specified. If
a product edition appears with the product version, behavior is
different in that product edition.
Unless otherwise specified, any statement of optional behavior in this
specification that is prescribed using the terms SHOULD or SHOULD NOT
implies product behavior in accordance with the SHOULD or SHOULD NOT
prescription. Unless otherwise specified, the term MAY implies that
the product does not follow the prescription.
<1> Section 2.1.8: The Microsoft:fileIdentifier XML tag is not
supported in Windows Vista, Windows 7, and Windows Home Server 2011.
<2> Section 2.3.1.1: The microsoft:magicPacketWakeSupported XML tag is
not supported in Windows Vista.
<3> Section 2.3.1.2: The microsoft:magicPacketSendSupported XML tag is
not supported in Windows Vista.
<4> Section 2.4.1: The PlayToApp ProtocolInfo extension is not
supported in Windows Vista, Windows 7, Windows Home Server 2011, and
Windows 8.
<5> Section 3.1.6: The FolderPath XML tag is not supported in
Windows Vista.
<6> Section 3.3.1: The microsoft:magicPacketWakeSupported XML tag is
not supported in Windows Vista.
<7> Section 3.3.2: The microsoft:magicPacketSendSupported XML tag is
not supported in Windows Vista.
6 Change Tracking
-----------------
This section identifies changes that were made to the [MS-UPMC]
protocol document between the November 2013 and February 2014
releases. Changes are classified as New, Major, Minor, Editorial, or
No change.
The revision class New means that a new document is being released.
The revision class Major means that the technical content in the
document was significantly revised. Major changes affect protocol
interoperability or implementation. Examples of major changes are:
A document revision that incorporates changes to interoperability
requirements or functionality.
The removal of a document from the documentation set.
The revision class Minor means that the meaning of the technical
content was clarified. Minor changes do not affect protocol
interoperability or implementation. Examples of minor changes are
updates to clarify ambiguity at the sentence, paragraph, or table
level.
The revision class Editorial means that the formatting in the
technical content was changed. Editorial changes apply to grammatical,
formatting, and style issues.
The revision class No change means that no new technical changes were
introduced. Minor editorial and formatting changes may have been made,
but the technical content of the document is identical to the last
released version.
Major and minor changes can be described further using the following
change types:
New content added.
Content updated.
Content removed.
New product behavior note added.
Product behavior note updated.
Product behavior note removed.
New protocol syntax added.
Protocol syntax updated.
Protocol syntax removed.
New content added due to protocol revision.
Content updated due to protocol revision.
Content removed due to protocol revision.
New protocol syntax added due to protocol revision.
Protocol syntax updated due to protocol revision.
Protocol syntax removed due to protocol revision.
Obsolete document removed.
Editorial changes are always classified with the change type
Editorially updated.
Some important terms used in the change type descriptions are defined
as follows:
Protocol syntax refers to data elements (such as packets,
structures, enumerations, and methods) as well as interfaces.
Protocol revision refers to changes made to a protocol that affect
the bits that are sent over the wire.
The changes made to this document are listed in the following table.
For more information, please contact [email protected].
Section
Tracking number (if applicable)
and description
Major
change
(Y or N)
Change type
1.2.2
Informative References
Removed the reference to [MS-REMSI].
Y
Content updated.
1.4
Relationship to Protocols and Other Structures
Removed the reference to [MS-REMSI].
Y
Content updated.
1.5
Applicability Statement
Removed the reference to [MS-REMSI].
Y
Content updated.
7 Index
-------
A
Applicability 9
Artist properties 10
Artist properties tags example 22
artistAlbumArtist properties 10
artistConductor properties 11
artistPerformer properties 10
Author properties 11
Author properties tags example 22
authorComposer properties 11
authorOriginalLyricist properties 11
authorWriter properties 12
C
Change tracking 28
Common data types and fields 10
Compatibility flags - values and behaviors 15
D
Data types and fields - common 10
Details
artist properties 10
artistAlbumArtist properties 10
artistConductor properties 11
artistPerformer properties 10
author properties 11
authorComposer properties 11
authorOriginalLyricist properties 11
authorWriter properties 12
common data types and fields 10
compatibility flags - values and behaviors 15
fileIdentifier property 14
flags - values and behaviors 15
folderPath properties 14
magic packets 20
MCEF property 14
microsoft:magicPacketSendSupported tag 20
microsoft:magicPacketWakeSupported tag 20
MMPE property 10
MPME property 20
ratings properties 12
serviceProvider properties 13
sourceURL properties 13
userEffectiveRating properties 12
userEffectiveRatingInStars properties 13
userRating properties 12
userRatingInStars properties 12
WMC_COMPAT_DO_NOT_LIMIT_RESPONSE_SIZE flag 18
WMC_COMPAT_EXCLUDE_DLNA flag 16
WMC_COMPAT_EXCLUDE_DLNA_1_5 flag 17
WMC_COMPAT_EXCLUDE_HTTP flag 15
WMC_COMPAT_EXCLUDE_NONPCM_AUDIO_TRANSCODING flag 19
WMC_COMPAT_EXCLUDE_PCMPARAMS flag 17
WMC_COMPAT_EXCLUDE_RES_FILTERING flag 19
WMC_COMPAT_EXCLUDE_RTSP flag 15
WMC_COMPAT_EXCLUDE_SEARCH flag 18
WMC_COMPAT_EXCLUDE_TRANSCODING_TO_MPEG2 flag 19
WMC_COMPAT_EXCLUDE_VIDEO_TRANSCODING flag 19
WMC_COMPAT_EXCLUDE_WMALOSSLESS_NONTRANSCODED flag 18
WMC_COMPAT_EXCLUDE_WMDRMND flag 18
WMC_COMPAT_INCLUDE_RTSP_FOR_VIDEO flag 18
WMC_COMPAT_PLAYLIST_FAKECHILDCOUNT flag 19
year properties 13
E
Examples
artist properties tags 22
author properties tags 22
fileIdentifier property tag 23
folderPath property tag 23
magicPacketSendSupported 24
magicPacketWakeSupported 24
MMPE 22
ratings properties tags 22
serviceProvider property tag 22
X_DeviceCaps 23
year property tag 23
F
Fields - vendor-extensible 9
fileIdentifier property 14
fileIdentifier property tag example 23
Flags
values and behaviors 15
WMC_COMPAT_DO_NOT_LIMIT_RESPONSE_SIZE 18
WMC_COMPAT_EXCLUDE_DLNA 16
WMC_COMPAT_EXCLUDE_DLNA_1_5 17
WMC_COMPAT_EXCLUDE_HTTP 15
WMC_COMPAT_EXCLUDE_NONPCM_AUDIO_TRANSCODING 19
WMC_COMPAT_EXCLUDE_PCMPARAMS 17
WMC_COMPAT_EXCLUDE_RES_FILTERING 19
WMC_COMPAT_EXCLUDE_RTSP 15
WMC_COMPAT_EXCLUDE_SEARCH 18
WMC_COMPAT_EXCLUDE_TRANSCODING_TO_MPEG2 19
WMC_COMPAT_EXCLUDE_VIDEO_TRANSCODING 19
WMC_COMPAT_EXCLUDE_WMALOSSLESS_NONTRANSCODED 18
WMC_COMPAT_EXCLUDE_WMDRMND 18
WMC_COMPAT_INCLUDE_RTSP_FOR_VIDEO 18
WMC_COMPAT_PLAYLIST_FAKECHILDCOUNT 19
folderPath properties 14
folderPath property tag example 23
G
Glossary 6
I
Implementer - security considerations 26
Informative references 8
Introduction 6
L
Localization 9
M
Magic packets 20
magicPacketSendSupported example 24
magicPacketWakeSupported example 24
MCEF property 14
microsoft:magicPacketSendSupported tags 20
microsoft:magicPacketWakeSupported tags 20
MMPE example 22
MMPE property 10
MPME property 20
N
Normative references 7
O
Overview (synopsis) 8
P
Packets - magic 20
PlayToApp extension 20
PlayToApp extension example 24
Product behavior 27
Properties
artist 10
artistAlbumArtist 10
artistConductor 11
artistPerformer 10
author 11
authorComposer 11
authorOriginalLyricist 11
authorWriter 12
compatibility flags - values and behaviors 15
fileIdentifier 14
flags
values and behaviors 15
WMC_COMPAT_DO_NOT_LIMIT_RESPONSE_SIZE 18
WMC_COMPAT_EXCLUDE_DLNA 16
WMC_COMPAT_EXCLUDE_DLNA_1_5 17
WMC_COMPAT_EXCLUDE_HTTP 15
WMC_COMPAT_EXCLUDE_NONPCM_AUDIO_TRANSCODING 19
WMC_COMPAT_EXCLUDE_PCMPARAMS 17
WMC_COMPAT_EXCLUDE_RES_FILTERING 19
WMC_COMPAT_EXCLUDE_RTSP 15
WMC_COMPAT_EXCLUDE_SEARCH 18
WMC_COMPAT_EXCLUDE_TRANSCODING_TO_MPEG2 19
WMC_COMPAT_EXCLUDE_VIDEO_TRANSCODING 19
WMC_COMPAT_EXCLUDE_WMALOSSLESS_NONTRANSCODED 18
WMC_COMPAT_EXCLUDE_WMDRMND 18
WMC_COMPAT_INCLUDE_RTSP_FOR_VIDEO 18
WMC_COMPAT_PLAYLIST_FAKECHILDCOUNT 19
folderPath 14
MCEF 14
MMPE 10
MPME 20
ratings 12
serviceProvider 13
sourceURL 13
userEffectiveRating 12
userEffectiveRatingInStars 13
userRating 12
userRatingInStars 12
year 13
ProtocolInfo Extensions 20
R
Ratings properties 12
Ratings properties tags example 22
References
informative 8
normative 7
Relationship to protocols and other structures 8
S
Security - implementer considerations 26
serviceProvider properties 13
serviceProvider property tag example 22
sourceURL properties 13
Structures
MCEF property 14
MMPE property 10
MPME property 20
overview 10
ProtocolInfo Extensions 20
T
Tags
magic packets 20
microsoft:magicPacketSendSupported 20
microsoft:magicPacketWakeSupported 20
Tracking changes 28
U
userEffectiveRating properties 12
userEffectiveRatingInStars properties 13
userRating properties 12
userRatingInStars properties 12
V
Vendor-extensible fields 9
Versioning 9
X
X_DeviceCaps example 23
Y
year properties 13
year property tag example 23
3 / 30
[MS-UPMC] — v20140124
UPnP Device and Service Templates: Media Property and Compatibility
Extensions
Copyright © 2014 Microsoft Corporation.
Release: Thursday, February 13, 2014
