Designing Digital Video Cameras to Meet Windows Logo Program Requirements - 2

Designing Digital Video Cameras to Meet Windows Logo Program Requirements

November 5, 2010

Abstract This paper provides guidelines for designing a file-based digital video camera that meets the Windows® Logo Program requirements under Windows 7. The guidelines include general transport, protocol, and feature implementation details as well as device installation and device enumeration specifics for a portable device.

The guidelines provide general direction whereas the Windows Logo Program requirements provide implementation details that must be supported in order to qualify to use the Compatible with Windows 7 logo. The requirements are verified during self-test assessment of the hardware using the Windows Logo Kit. For your convenience each of the guidelines has a corresponding logo requirement or requirements referenced; the applicable logo requirements are provided in the Appendix section of this document.

This information applies to the following operating systems: Windows 7

References and resources discussed here are listed at the end of this paper.

The current version of this paper is maintained on the Web at: http://www.microsoft.com/whdc/device/media/video-cameras-logo.mspx

Disclaimer: This document is provided “as-is”. Information and views expressed in this document, including URL and other Internet Web site references, may change without notice. You bear the risk of using it.

This document does not provide you with any legal rights to any intellectual property in any Microsoft product. You may copy and use this document for your internal, reference purposes.

UPnP™ is a certification mark of the UPnP™ Implementers Corporation.

Document History Date Change 11/5/2010 First publication Designing Digital Video Cameras to Meet Windows Logo Program Requirements - 2

Contents

The Windows Logo Program for Hardware The Windows Logo Program is designed to address the current and future market needs of customers using the Windows platform. The Windows logo signifies the compatibility and reliability of systems and devices with the Windows operating system. It gives customers confidence that the product is thoroughly tested with Microsoft®-provided tools and enables a good user experience.

If you create hardware products and drivers, Microsoft urges you to qualify your products for the Windows Logo Program to help customers identify quality products that are easy to install and that run without interfering with other components on Windows-based computers. The program strives to continuously improve its processes, responsiveness, and partner satisfaction.

Introduction The Windows Logo Program for digital video cameras is based on a device supporting the Media Transfer Protocol (MTP). Microsoft has implemented MTP as a client extension to the Picture Transfer Protocol (PTP) for portable devices. MTP is a protocol used for communication between a portable device and a desktop application. MTP allows a computer to control a portable device and to transfer digital content and metadata between the computer and the device. A digital video camera that meets a minimum set of MTP- compatibility requirements may qualify to be certified as “Compatible with Windows 7”. Certification is also required in order to have custom Device Stage™1 experiences signed and distributed by Microsoft.

Although Microsoft initially developed MTP to control portable devices, the MTP class driver in Windows Vista included support for digital video cameras as well. Because of the built-in driver support in Windows Vista, consumers can conveniently connect their MTP-compatible digital video cameras to their desktop computers without having to install third-party drivers.

After purchasing an MTP-compatible digital video camera, the consumer removes the camera from the retail packaging and simply connects it (typically through a USB cable) to a computer that is running Windows. At that point, the consumer can immediately begin using a desktop application to communicate with the video camera and transfer images, videos, or other file types to or from the device.

MTP-compatible digital video cameras have the following advantages over other technologies:

Class driver support for MTP-compatible devices. A wide range of defined image and video object formats. A more complete set of object properties for digital video cameras. Better support for video, including: o Ability to download video (and other types of data) files from the host computer to the MTP-compatible digital video camera. o Leveraging the Windows Media Foundation to support format transcodes when synchronizing media to a device. Fast access to object properties on the device. Transport support over USB, Bluetooth, and IP. Ability to leverage MTP Device Services and define custom Device Service Extensions. Although this paper summarizes the relevant requirements from the MTP specifications, the summary in this paper is not sufficient to ensure full compliance with these requirements.

Hardware vendors should refer to these documents directly to obtain the necessary detailed information required to implement the required features correctly. In support of these guidelines there are referenced documents that describe implementation details, including References to the Media Transfer Protocol Specification, which is hosted by the Universal Serial Bus Implementers Forum, Inc. (USB-IF).

For other questions about MTP or portable devices, send an email message to [email protected].

Scope This paper presents guidelines for the design of digital video cameras that operate as MTP responders. Desktop applications that run in Windows can access MTP objects (digital content) and object properties (metadata describing the content) in digital video cameras. To be MTP-compatible, digital video cameras must be capable of:

Capturing an image or video and storing it as a digital object. Displaying or playing the stored image or video. MTP-compatible digital video cameras must store digital content internally in the form of files that reside in nonvolatile storage devices such as hard disks or flash memory that are part of the digital video camera. By definition, analog (film) cameras and tape-based video recorders (with formats such as VHS, VHSC, and DV) are not MTP-compatible devices.

MTP does not specify the features of the file system that the responder uses to store objects internally. It specifies only how an initiator accesses objects in a responder over the MTP connection between the initiator and responder. However, many manufacturers of MTP devices follow standards—in addition to MTP—that do specify the features of internal file systems.

In particular, a number of digital video cameras conform to Design Rule for Camera File System, Version 2.0 (DCF 2.0), a Japan Electronics and Information Technology Industries Association (JEITA) standard. DCF-compatible devices can handle DCF folder and file structures, but might not work with other folder and file structures. Although this paper addresses only MTP implementation issues, a desktop application that uses MTP to communicate with DSCs and digital video cameras should typically include support for DCF because of its widespread use among these devices.

This paper does not present guidelines for devices other than digital video cameras.

Prepared Requirement Reports The Windows Logo Program for Hardware provides a list of requirements that the validation tests, which are provided in the Windows Logo Kit, are based on. During the hardware design phase it is critical that manufacturers that are going to be involved with the logo process review the logo requirements that are applicable to a target operating system, such as Windows 7. Although the majority of requirements that are outlined for portable devices are based on industry standards and specifications or white papers published by Microsoft, there are some requirements that may not be apparent until you attempt to run through the Windows Logo Kit and come across a failure that you do not expect. For example, there are portable device-specific behavior requirements defined in the requirement report, but there are also fundamental requirements that apply to any device with Windows. There are also requirements that apply to all USB devices, Bluetooth devices, or IP devices; one such requirement is to support USB serial numbers for all portable USB devices. Additional requirements can be reviewed by downloading the Prepared Requirements Reports, which are organized by specific hardware technologies, or by referring to the Detailed Requirements section of this document.

Every attempt has been made within this document to include references to those fundamental requirements.

Portable Devices and Windows Overview Microsoft has defined the Media Transfer Protocol (MTP) as a vendor extension to the Picture Transfer Protocol (PTP) for portable devices. MTP-compatible portable devices, including digital video cameras (DVCs), can communicate with desktop applications that run on Windows-based computers. A DVC that meets the MTP-compatibility requirements of the Windows Logo Program for Hardware can qualify to use a logo. This paper summarizes the features that a DVC should implement to support MTP and to connect seamlessly to computers that run Windows 7.

Portable Device Guidelines This paper presents guidelines for the design of portable devices that operate as MTP responders. Desktop applications that run in Windows 7 can access MTP objects (digital content) and object properties (metadata describing the content) in portable devices. To be MTP-compatible, a portable device such as a digital video camera must be capable of capturing video and storing it as a digital object and displaying or playing the stored video.

A concise list of the MTP commands, formats, and properties that are required by or recommended for MTP-compatible portable devices is provided in this document. Portable devices that include media playback functionality must be implemented using MTP according to the requirements defined in this document. They should allow the transfer and storage of digital media content. These devices must accurately report the available storage capacity of the device. The value reported must not be greater than the amount of data that can be transferred to the device.

Each device must work with the MTP drivers that ship with Windows. This means that they must install and work immediately without requiring the installation of additional drivers or software. Portable devices must ship with MTP enabled as the default connection mode. Devices can support Mass Storage Class (MSC) in addition to MTP.

MTP Implementation MTP is a protocol for communication and control of portable media devices. MTP enables object exchange, object description, and device management in a standard and extensible way. As such, the object-based protocol extracts device capabilities, objects, and object properties so that they can be exchanged with the personal computer independently of device implementation.

Simple devices can implement a minimal set of MTP functionality, which allows a vendor to develop a product with minimal investment in firmware and drivers. More advanced devices can take advantage of the full MTP feature set or extend it with vendor-specific plug-ins and through the use of MTP Device Services for Windows and MTP Device Services Extension Specification, which are also described in this document.

MTP as an Alternative to Mass Storage MTP provides significantly more capability than the existing Mass Storage Class (MSC) driver, as shown in Table 1.

Table 1. Side-by-side comparison between MTP and MSC supported capabilities Media Mass Transfe Storag Capability r e Class Protoco l Built-in support in Windows ■ ■ Supports device storage, read and write ■ ■ Works with all file types (media and data) ■ ■ Supports Microsoft DRM ■ ■ Supports standardized playlists (for example, M3U) ■ ■ Works with any device, operating system, or file ■ system Supports personal computer control of device features ■ Supports events that originate on the device ■ Supports content matching with device capabilities ■ Supports playlist abstractions ■ Capable of being ported to IP networks ■ Provides for third-party extensions ■ Supports Device Services ■ Supports Device Service Extensions ■

Media Transfer Protocol solutions MTP is designed to support richer, more media-intensive products than MSC. MTP provides an alternative to MSC for device manufacturers to enable more advanced device features. MTP is an interface abstraction and does not impose any implementation details other than the need to support a baseline set of MTP commands in the device.

Vendors can choose whether to implement other defined functions such as read back. In addition, the protocol is extendable, so vendors can design products to take advantage of native Windows Media device features and also support additional functions through a third- party application.

Mass storage class solutions MSC is best suited for simple, storage-oriented designs. Devices that use MSC are exposed as storage volumes in My Computer, which provides flexible and proven content enumeration, organization, and storage manipulations. However, MSC is implementation-specific in that it requires the device to use a file system that is directly compatible with Windows, such as FAT 16 or FAT32. This restricts device capabilities.

MSC will continue to be a viable model for some kinds of portable devices. USB storage sticks, for example, can be seen primarily as storage volumes that might also have the ability to play portable media. For products such as these, the MSC approach makes device design simple.

Digital Video Camera Guidelines Different portable devices need to meet standards requirements unique to their generic class. For example, a digital video camera must use USB, Bluetooth, and/or 802.1x to connect to the computer. The connection must be implemented according to requirements in the appropriate connection type section. A DVC must support required mandatory MTP operations, Properties, Events, Responses, and Formats in its firmware. Further, MTP- compatible portable devices must be able to store digital content internally in the form of files that reside in nonvolatile storage devices such as hard disks or flash memory that are part of the DVC. By definition, analog (film) cameras and tape-based video recorders (with formats such as VHS, VHSC, and DV) are not MTP-compatible devices.

In particular, a number of digital video cameras conform to Design Rule for Camera File System, Version 2.0 (DCF 2.0), a Japan Electronics and Information Technology Industries Association (JEITA) standard. DCF-compatible devices can handle DCF folder and file structures, but might not work with other folder and file structures. Although this paper addresses only MTP implementation issues, a desktop application that uses MTP to communicate with DVCs should typically include support for DCF because of its widespread use among these devices.

REQUIREMENT REFERENCE: PORTABLE-0022 PORTABLE-0031 PORTABLE-0055 PORTABLE-0057 PORTABLE-0058

Device Identification In Windows Vista and later operating systems, an MTP device is not required to have a custom driver, but does need to have a USB interface descriptor that indicates that the device is a MTP device (class code = 0x06, subclass code = 0x01, and protocol code = 0x01). Then, the operating system uses the DeviceInfo data set to distinguish the MTP device. The operating system loads the MTP class driver to control the MTP device. This version of the MTP class driver supports a variety of MTP devices, including digital still cameras, mobile phones, portable devices, and DVCs.

Portable devices are required to work with the MTP class driver that ships in Windows.

All devices that are externally connected to a computer must also indicate that it is external to the computer by supporting the CM_DEVCAP_REMOVABLE capability, which will show up in the device devnode.

REQUIREMENT REFERENCE: DEVFUND-0003 DEVFUND-0030 DEVFUND-0034

Transport Guidelines Portable devices that implement MTP have the option to support three different transports in Windows 7. MTP is a transport-independent protocol and can be implemented on hardware interfaces other than USB. A MTP driver for USB was introduced in Windows XP. In Windows Vista, support for MTP over TCP/IP for devices that use Wi-Fi and LAN connections was added. In Windows 7, MTP support was extended with the introduction of Bluetooth. MTP includes a protocol definition and several transport definitions. As devices and computers pick and choose which connectivity transports they support, device and application developers can be assured that the MTP protocol and WPD API will be consistent. Three- transport support gives device manufacturers flexibility to choose wired or wireless, high or low power, faster or slower transfer speed, and other options. The MTP driver is also the first multi-transport driver in Windows, which means that a device manufacturer can implement all three and Windows will choose the best transport to connect over.

If a transport is supported, there are general logo program requirements when implementing that transport. Those requirements have been included below by reference.

Note that support for MTP on Windows XP is included with the installation of Windows Media Player 10 and Windows Media Player 11. Support for MTP over BT on Windows Vista is provided as part of the Platform Update for Windows Vista.

Table 2. MTP transport support on Windows USB TCP/IP Bluetooth Windows XP Yes No No Windows Vista Yes Yes Yes Windows 7 Yes Yes Yes REQUIREMENT REFERENCE: PORTABLE-0025 PORTABLE-0038

MTP over USB The initial MTP transport driver is also the fastest and most powerful way to connect an MTP- enabled device. Windows XP through Windows 7 support USB 1.1 or higher. The binding of MTP to USB is described in the MTP specification itself and in the Still Imaging Capture Device Definition specification. Windows XP uses the Microsoft OS descriptor to identify MTP devices; Windows Vista and Windows 7 can identify MTP devices by either the OS descriptor or the USB Still Image Class Code.

USB is great for fast file transfer, media synchronization, and charging the device while you’re using it.

REQUIREMENT REFERENCE: PORTABLE-0025 CONNECT-0044 CONNECT-0045 CONNECT-0048 CONNECT-0049 CONNECT-0052 CONNECT-0054 CONNECT-0056 CONNECT-0059 CONNECT-0061 CONNECT-0062 CONNECT-0093 CONNECT-0101

CONNECT-0104 CONNECT-0109 CONNECT-0123 CONNECT-0130

MTP over IP Starting with Windows Vista, MTP over TCP/IP was implemented to enable Wi-Fi and networked devices to interact with WPD applications. This is based on the PTP/IP binding, and then uses UPnP™ for pairing and discovery. When devices report their presence on a network via UPnP after the initial pairing, Windows will automatically connect and make the device available to the user.

MTP over IP is ideal for devices with Wi-Fi that can be connected and synchronized anywhere in the home.

MTP/IP responder devices must support the following three technologies to ensure compatibility with computers (MTP/IP initiators) that run Windows Vista® or later. A device is not required to support these technologies to qualify to use the logo. The logo testing does not include validation for MTP over IP implementations; it is strongly recommended that these guidelines are followed when developing a device that supports MTP over IP.

UPnP Basic Device MTP/IP devices must support Simple Service Discovery Protocol (SSDP) discovery as a Universal Plug and Play (UPnP) basic device. For more information about SSDP, see the Resources section.

PTP/IP MTP/IP devices should comply with the Camera and Imaging Products Association (CIPA) PTP over Internet Protocol (PTP/IP) specification (CIPA-005/2005), which extends the PTP specification to use TCP/IP to perform PTP operations over wireless networks. For more information about PTP/IP, see Resources.

Wi-Fi-Provisioning and Network Association Extensions MTP/IP devices must comply with the Wi-Fi-provisioning extension to the MTP specification and the MTP Network Association extension to the MTP specification. For more information about these MTP extensions, see Resources.

MTP over BT In Windows 7, Bluetooth (BT) was introduced as the third transport for MTP. MTP over the L2CAP protocol is supported for fast, efficient, and secure connections. The specification is available in the Windows Portable Device Enabling Kit. Computer users can switch the connection on and off through the Devices and Printers folder or devices themselves can initiate and terminate connections to the computer.

Windows 7 includes an "auto-connect" feature in which Windows attempts to connect to the device every few minutes to maintain a low power connection for automatic synchronization and status updates. When the device is held near the computer, it is connected; when the device moves away, the connection breaks and waits silently to reconnect when the device is back in Bluetooth range.

Applications can use the IPortableDeviceConnect interface to issue connect/disconnect requests to an MTP over BT device. When a connection request is made, the MTP over BT link is established, the WPD MTP driver stack will load, and the device becomes visible to WPD applications to connect to using the WPD API.

Windows requires Bluetooth 1.2 or higher with the Microsoft Bluetooth stack installed. For maximum security, Windows also requires that the device is paired securely with a pin code.

MTP over BT devices are able to communicate with Windows in a standard MTP conversation over Bluetooth, similar to USB and TCP/IP. If the device implements MTP over BT it should comply with the MTP over BT specification, which requires support for:

L2CAP Transport MTP Responder Service Definition Record required parameters GetFormatCapabilities operation to mitigate format enumeration performance issues This is not the complete list of requirements defined in the specification; additional requirements defined in the specification should also be met. A device is not required to support these technologies to qualify to use the logo. The logo testing does not include validation for MTP over BT implementations; it is strongly recommended that these guidelines are followed when developing a device that supports MTP over BT.

MTP over BT is great for low-power, low-speed scenarios like synchronizing Personal Information Management (PIM) data or a quick file transfer.

Multi-Transport Capable Devices In Windows 7 Microsoft introduced a multi-transport aware driver. A multi-transport device is a device that supplies a device property known as the Functional Unique ID (FUID). This is a 128-bit GUID (Globally Unique ID). For MTP devices, this property is defined by the new MTP Device Services Extension (see the MTP Device Services Extension Specification). This does not mean that the device must support services. A device may indicate support for this extension, but only implement the parts that it needs (in this case, the “Functional ID” 0xD301 device property code).

The FUID must be unique across all devices of the same manufacturer, model and version. If two devices of the same model have the same FUID, they are treated as different transports of the same device. To avoid this, and to simplify operations for the device manufacturer, if the MTP driver finds an empty value for the FUID property on the device, it will automatically provision the device with an FUID generated at runtime. The only responsibility of the device manufacturer is to ensure that the FUID value is persisted across connections and available over all transports.

For more information, refer to the MTP Device Services Extension Specification or the WPD Team Blog.

OS Descriptor Support in Windows The OS descriptor technology is supported in Windows XP SP1, Windows Server 2003, and later versions.

OS String Descriptor When vendors introduced the first MTP-compatible portable devices, the USB Implementers Forum had not yet selected a USB device class to use to identify MTP devices. In the interim, Microsoft licensed its proprietary OS descriptor technology to MTP device vendors to provide a temporary solution to their device identification requirements. For more information about OS descriptors, see References at the end of this paper.

Although Microsoft will continue to support existing MTP devices that have OS descriptors, new devices should not use OS descriptors. Instead, these devices should use the USB still

November 5, 2010 © 2010 Microsoft Corporation. All rights reserved. Designing Digital Video Cameras to Meet Windows Logo Program Requirements - 11 image capture interface descriptor and DeviceInfo data set to indicate that they are MTP- compatible, as described previously.

The Microsoft OS descriptor enables hardware vendors to include additional information in their devices, which can be retrieved by a Microsoft OS descriptor enabled operating system. The information that needs to be stored in the device will have to comply with the format of the Feature Descriptors designed by Microsoft. No Feature Descriptor can be defined or implemented without Microsoft’s consent.

The Microsoft OS descriptor is a term used to describe the information embedded in the device that can be retrieved by a Microsoft OS descriptor enabled operating system. The format of the data must be in union with the Feature Descriptors defined by Microsoft.

The Microsoft OS descriptor is broken up into the following segments:

One Microsoft OS String Descriptor One or more Microsoft OS Feature Descriptors The Microsoft OS String Descriptor is a special string that is embedded at a fixed string index. The purpose of this string is to inform the operating system of the presence of the Microsoft OS descriptor along with additional information.

The Feature Descriptors are fixed format descriptors that have been defined and allocated by Microsoft.

OS String Descriptor The Microsoft OS String Descriptor is a string that is stored at string index 0xEE. The format of this string is well defined. The string descriptor is used to achieve the following objectives:

The presence of the Microsoft OS String Descriptor indicates to the operating system that the device has information embedded in it, in the form of Microsoft OS Feature Descriptors. The Microsoft OS String Descriptor has an embedded Signature Field that is used to differentiate it from random strings that might happen to be on a device at string index 0xEE. The Microsoft OS String Descriptor has an embedded version number that allows for future revisions of the Microsoft OS descriptor. There will only be one Microsoft OS String Descriptor stored on the device. The following sections narrate the structure of the Microsoft OS String Descriptor and its retrieval procedure.

Structure of the String Descriptor The structure of the string descriptor is specified below.

Table 3. Structure of the Microsoft OS String Descriptor Field Length Value Description (Bytes) bLength 1 0x12 Length of the descriptor bDescriptorType 1 0x03 String Descriptor qwSignature 14 ‘MSFT100’ Signature field (4D0053004600540031003000300 0) bMS_VendorCode 1 Vendor Code Vendor code to fetch other OS Feature Descriptors

November 5, 2010 © 2010 Microsoft Corporation. All rights reserved. Designing Digital Video Cameras to Meet Windows Logo Program Requirements - 12 bPad 1 0x00 Pad field The structure of the Microsoft OS String Descriptor is fixed for version 1.00 and has an overall length of 18 bytes. The version number of the Microsoft OS String Descriptor is listed in the qwSignature field.

The information stored in the bMS_VendorCode field must be a single byte value. It will be used to retrieve Microsoft OS Feature Descriptors, and this byte value is used in the bmRequest field in section 3.1.

Retrieving the OS String Descriptor To retrieve the information stored in the string, a standard GET_DESCRIPTOR request must be issued to the device. The format of the request is specified below.

Table 4. Standard Get_Descriptor String Request bmRequestType bRequest wValue wIndex wLengt Data h 1000 0000B GET_DESCRIPTOR 0x03EE 0x0000 0x12 Returns the string The bmRequestType field is a bitmap composed of three parts – direction of data transfer, descriptor type, and recipient. As per the Universal Serial Bus Specifications, the value of bmRequestType is set to 1000 0000b (0x80). The bRequest field should be set to a standard GET_DESCRIPTOR request. For a GET_DESCRIPTOR request, the wValue field is split into two parts. The high byte stores the descriptor type and the low byte stores the descriptor index. To retrieve the Microsoft OS String Descriptor, the high byte should be set to retrieve a string descriptor, hence 0x03. Since the Microsoft OS String Descriptor is always stored at index 0xEE, this string index should be stored in the lower byte of the wValue field. The wIndex is used to store the Language ID, but it must be set to zero for a Microsoft OS String Descriptor. The wLength field is used to indicate the length of the string descriptor to be retrieved. The device should respond to any valid range from 0x02-0xFF. If a device does not have a valid descriptor at the corresponding address (0xEE), the device will respond with a request error or stall. For devices that do NOT respond with a stall, a single-ended Zero reset will be issued to the device (to recover it, if it should go into an unknown state).

OS String Descriptor Constraints The following constraints apply to Microsoft OS String Descriptors and their retrieval:

To store information in compliance with the Microsoft OS descriptor specification, the device must have one and only one Microsoft OS String Descriptor that is in compliance with the Microsoft OS Descriptors topic. No Microsoft OS Feature Descriptors will be retrieved from the device if it fails to comply with this section. A device vendor is free to use any value in the bMS_VendorCode field in the Microsoft OS String Descriptor.

OS Feature Descriptor A Feature Descriptor is a fixed format descriptor that has been defined for a specific purpose. To identify itself as capable of supporting MTP, a device must support the Extended

Configuration Descriptor, which is one of the defined Feature Descriptors. The structure of this descriptor is described in the following sections.

Header Section The Header Section stores information about the rest of the Extended Configuration Descriptor. The dwLength field contains the total length of the entire Extended Configuration Descriptor. The Header Section also contains a version number, which will be initially set to 1.00 (0100H). Future revisions of this descriptor may be released at a later stage. It must be noted that future versions of the Extended Configuration Descriptor might also need to increase the number of entries in the Header Section, so developers should verify that this number is accurately stored in the device and read by the operating system.

Table 5. Extended Configuration Descriptor Header Section Offset Field Size Value Description 0 dwLength 4 Unsigned The length field describes the DWord length of the Extended Configuration Descriptor in bytes 4 bcdVersion 2 BCD Extended Configuration Descriptor release number in Binary Coded Decimal (i.e. version 1.00 is 0100H) 6 wIndex 2 Word Fixed = 0x0004 8 bCount 1 Byte Total number of Function sections that follow the Header section = 0x01 9 RESERVED 7 RESERVED

Function Section The Function Section provides two important pieces of information. It groups consecutive interfaces serving a similar purpose into function groups, and provides Compatible and subCompatible IDs for each function. The format of the Function Section (including values that should be used by an MTP device) is listed below.

Note that the offset of the Custom Property section has been reset to zero. To calculate the offset of a field from the beginning of the extended configuration descriptor, add the length of the sections that precede the descriptor.

Table 6. Extended Configuration Descriptor Function Section Offset Field Size Value Description 0 bFirstInterfaceNumb 1 Byte Starting Interface Number for this er function = 0x00 1 bInterfaceCount 1 Byte Total number of Interfaces that must be included to from this function = 0x01 2 compatibleID 8 Bytes Compatible ID for this function as defined by Microsoft = MTP (0x4D 0x54 0x50 0x00 0x00 0x00 0x00 0x00) 10 subCompatibleID 8 Bytes Sub Compatible ID value as defined by Microsoft = 0 18 RESERVED 6 RESERVED = 0

USB Device Class Feature Descriptor An MTP-compatible portable device should specify the following values in its USB interface descriptor:

Class code = 0x6 (image device) Subclass code = 0x1 (still image capture device) Protocol code = 0x1 (PTP) These values identify the device as either a PTP camera or an MTP device. For more information about the still image capture interface descriptor, see "Universal Serial Bus Still Image Capture Device Definition" on the USB website.

In addition, an MTP device should set the fields in the DeviceInfo data set as follows:

MTPVendorExtensionID = 0x00000006 (Microsoft vendor extension ID) MTPVersion = 100 (version 1.0) These settings enable an MTP initiator to distinguish an MTP device from a PTP camera. The Microsoft vendor extension ID, 0x00000006, is assigned by PIMA to identify the Microsoft extension to the PTP specification (PIMA 15740). The value 100 is the current MTP version number, 1.0, expressed in hundredths. For more information about the DeviceInfo data set, see the MTP specification.

In Windows Vista and later, or in Windows XP with Windows Media® Player 11 or Windows Media Player 10, the operating system will ignore the USB still image capture interface descriptor if the device has an OS descriptor.

In the initial release of Windows XP, the operating system did not distinguish between PTP cameras and MTP devices. It treats an MTP device as a PTP camera.

If the operating system bases its selection of a driver for a PTP camera or MTP device on the USB still image capture interface descriptor, then the "Matching Device ID" property for the device will be:

USB\Class_06&SubClass_01&Prot_01 To view this property, open Device Manager, double-click the device, click the Details tab, and select the Matching Device ID property from the list box.

OS Feature Descriptor Constraints The following constraints apply to Microsoft OS Feature Descriptors and their retrieval:

All Microsoft OS Feature Descriptors are defined and standardized. Vendors are not allowed to modify/append/create Microsoft OS Feature Descriptors without direct consent from Microsoft. All Microsoft OS Feature Descriptors will have a size and version number embedded in them. These values should always report correct information to the operating system. A device can have more than one Microsoft OS Feature Descriptor embedded in its firmware. Some Microsoft OS Feature Descriptors are stored on a per-interface level, while others are unique for the device. Device level Microsoft OS Feature Descriptors should set the high byte of the wValue field as zero.

Retrieving the OS Feature Descriptor To retrieve a Microsoft OS Feature Descriptor, a special GET_MS_DESCRIPTOR request needs to be issued to the device. The format of the request is specified below.

Table 7. Standard device request format bmRequestType bRequest wValue wIndex wLength Data 1100 0000b GET_MS_DESCRIPTO X Feature Length Returns R Index descriptor The bmRequestType field is a bitmap composed of three parts – direction of data transfer, descriptor type, and recipient – and is in accordance with the Universal Serial Bus Specification Document. The Microsoft OS Feature Descriptor is a vendor specific descriptor and the direction of data transfer is from the device to the host. Hence the value of bmRequestType is set to 1100 0000b (0xC0). The bRequest field is used to indicate the format of the request. In order to retrieve a Microsoft OS Feature Descriptor, the bRequest field should be populated with a special GET_MS_DESCRIPTOR byte. The value of this byte is indicated by the bMS_VendorCode, which is retrieved from the Microsoft String Descriptor. The wValue field is put to special use and is broken up in to a high byte and a low byte. The high byte will be used to store the interface number. This is essential for storing Feature Descriptors on a per-interface basis, especially for composite devices, or devices with multiple interfaces. In most cases, interface 0 will be used. The low byte will be used to store a page number. This feature prevents descriptors from having a size boundary of 64KB (a limit set by the size of the wLength field). A descriptor will be fetched with the page value initially set to zero. If a full descriptor (size is 64KB) is received, the page value will be incremented by one and the request for the descriptor will be sent again (this time with the incremented page value). This process will repeat until a descriptor with a size of less than 64KB is received. Note that the maximum number of pages is 255, placing a limit of 16MB on the descriptor size. The wIndex field will store the Feature index number for the Microsoft OS Feature Descriptor being retrieved. Microsoft will maintain this list of Microsoft OS Feature Descriptors and indexes. To learn more about Microsoft OS Feature Descriptors refer to the supplementary document titled “Supported Microsoft Feature Descriptors”. The wLength field specifies the length of the descriptor to be fetched. If the descriptor is longer than the number of bytes stated in the wLength field, only the initial bytes of the descriptor are returned. If it is shorter than the value specified in the wLength field, a short packet is returned. If a particular OS descriptor is not present, the device will issue a request error or stall.

Verifying the Integrity of the OS Descriptor Since vendors are allowed to use any string ID to store information, the operating system must verify that the string stored in index 0xEE is indeed the Microsoft OS String Descriptor. To verify this, the following tests will be conducted. Failure of either will inhibit retrieval of the Microsoft OS Feature Descriptors.

If a vendor stores a string in index location 0xEE, the operating system will retrieve the string and query it to see if it is the Microsoft OS String. This can be verified by comparing the signature field in the string to the signature field entry specified above. A mismatch will prevent further parsing of the string.

The second test will include a verification of the length of the string based on the version number specified in the signature field. The version number specified (in the string “MSFT100”) is 1.00. This corresponds to an 18-byte string descriptor.

MTP Requirements The MTP requirements for portable devices are described in detail in the Appendix section of this document. The details provided include requirements for the different MTP commands, responses and events, formats, and properties. Additional details can be found in the MTP version 1.0 specification. For more information, see the Resources section.

REQUIREMENT REFERENCE: PORTABLE-0031

MTP Device Services Overview "Device Services" is a new concept introduced in Windows 7 that provides a framework for device manufacturers to extend device functionality with MTP, and for new APIs for applications to discover and access that extended functionality using WPD. These extensions to device functionality are called "Device Services" because they foster rich interaction between the computer and devices by providing a model for devices to formalize extension capabilities and make these capabilities accessible to applications.

MTP became a USB standard and was widely adopted by numerous device classes: devices, mobile phones, cameras, Xbox 360s, and others. True to its PTP origins, MTP 1.0 was very media-centric; the scenarios it excelled in revolved around browsing device content and exchanging media files (such as images, music, and video) between the device and the computer. This is sufficient for browsing a device and transferring objects between initiators and responders, but does not provide more complex devices with flexibility when the object is a non-media file.

Enabling PIM Scenarios With Windows 7, the focus shifted to enabling more device-to-computer scenarios centered around managing and accessing Personal Information Management (PIM) data (such as contacts, tasks, and calendars) on the device. These involved more complex operations such as SMS, email and advanced synchronization with Outlook. Non-media files present additional challenges in accessing and enumerating them efficiently on the device. Unlike an MP3 or a JPEG file, a contact or task may not be represented by a physical file on the device storage. Depending on device implementation, these objects could be stashed anywhere: in databases, in SIM cards, and other places.

How do Device Services help? An MTP Device Service is an MTP extension that defines a set of MTP operations specific to a new type of object known as a "service”.

A service is composed of three parts:

The core definition of that service and what it does, including its globally unique identifier (GUID). The properties of the service itself. The properties and capabilities of objects and methods of that service. Properties are represented by PROPERTYKEYS, and formats are represented by GUIDs, which eliminate the operation and format number space restrictions. Together, these provide the

November 5, 2010 © 2010 Microsoft Corporation. All rights reserved. Designing Digital Video Cameras to Meet Windows Logo Program Requirements - 17 structure that applications rely on to programmatically discover and use services in a consistent way.

The following describes the most common ways in which Device Services are used today:

Provide a set of properties and events associated with a common scenario. One example is the Status Service, which defines properties for the battery level, the number of missed calls, the number of new voicemail messages, and the number of new pictures acquired by a device. These may be custom properties, and any application that discovers this service can programmatically discover these properties. Provide a known source and/or sink for content. The Contacts, Calendar, Task, and Notes services are all services that allow applications to access and store PIM data. These are analogous to "virtual storages". The device represents the content in a standard location (as child objects of these services) so that applications do not have to work through the device hierarchy to find them. At the same time, this abstraction allows a device implementation greater control over how objects are actually stored on the device. Services are not limited to the known MTP or WPD formats, and may support any arbitrary type of data. For example, devices that wish to provide a Device Stage™ experience upon install can implement a Device Metadata Service that stores *.devicemetadata-ms files. Provide a set of functionality associated with a common scenario. The Full Enumeration and Anchor Synchronization services support "methods". Methods are like extensions to WPD commands, with the added benefits of being easily discoverable and supporting both synchronous and asynchronous invocation. The Anchor Synchronization Service features a method that allows a synchronization application to retrieve the set of changes to content on the device from a given anchor value (which can be a timestamp or a tick count). Methods also provide a flexible way to access content residing on multiple services. For instance, the Ringtones Service contains a method that allows an application to associate a ringtone (an object within the Ringtones Service) with a contact (an object within the Contacts Service).

Device Services in Windows 7 Device Services are leveraged in Windows 7 in conjunction with Device Stage to provide users with new experiences.

REQUIREMENT REFERENCE: PORTABLE-0034 PORTABLE-0043 Device Stage- This uses the Status service to display status elements on the Branding bar and on the Taskbar and preview pane.

Windows 7 Synchronization – The Portable Devices Sync Provider uses the Contact Service, Calendar Service, Task Service, and Notes Service to access PIM data on the device. In addition, the Enumeration Synchronization Service and Anchor Synchronization Service are used to determine the level of synchronization capabilities that a device supports.

Windows Media Player and Windows Explorer – Both these applications use WPD Device Hints to determine content locations more efficiently. For MTP devices, WPD Device Hints is now implemented at the MTP layer as a Hints Service. Devices that implement the Hints Service get WPD Device Hints for free.

Ringtone Editor – The Ringtone Editor uses the Ringtones Service to transfer user-created ringtones to the device, and to associate a ringtone with a contact that is located using the Contacts service.

WPD Class Installer – The WPD Class Installer uses the Device Metadata Service to retrieve and transfer metadata stored on the device, so that the richer, device-manufacturer- customized, Device Stage experience gets presented to the user after the first time the device is connected and installed.

MTP Device Services Extension In addition to the pre-defined device services mentioned above, Windows is also capable of supported custom device services that use the newly defined MTP Device Services Extension to MTP. The MTP Device Services Extension enables Windows to locate and use various services and content types located on a device.

In the recent applications of MTP without device services, content is distributed throughout a device, which makes it difficult for the operating system to determine where the useful assets are and how to deploy them. With the creation of the Device Services extension to the MTP protocol, Windows now has the ability to locate, consume, and interact with this content in practical ways based on Microsoft and manufacturer defined services. This feature is particularly useful in accessing device content that is not based on file system data or accessing settings, or that has restricted capabilities. For example, a device manufacturer could define a custom SMS service.

While MTP already supports enumeration by format, it is cumbersome when applying rich semantics to simple hierarchical storage. With Device Services, content and functionality can be combined under a single functional object, resulting in well-scoped access to only the content and functions specific to that service.

REQUIREMENT REFERENCE: PORTABLE-0035

Tuning MTP Device Performance The following suggestions can help you to improve the performance of your MTP DVC by speeding up property retrieval and transfers of metadata.

Object Property Groups As an option, an MTP DVC can speed up property retrieval by providing support for groups of object properties. If the device supports object property groups, the MTP driver can retrieve a group of object properties in a single GetObjectPropList command. If the device lacks support for object property groups, the MTP driver must individually retrieve the various properties of an object in a series of MTP operations.

The MTP DVC typically divides the set of object properties into several groups. Each object property group is identified by a number called a group code. The group code for an object property is specified in the ObjectPropDesc data set for that property. For more information about ObjectPropDesc, see section 5.3.2.7 of the MTP specification, "Optimizing Object Properties”.

One strategy for improving performance is to organize object properties into groups based on the relative retrieval speeds of the properties. The device should assign the smallest groupcode values to the fastest properties and larger values to the slower properties.

Another strategy is to organize properties into groups based on how likely the MTP driver is to access all of the properties in the group if it accesses any property in the group. For example, to improve the retrieval speed for an application that handles still images or video, but not both, the device can place the object properties of still images into one group and the object properties of video objects into another group. Thus a still image application can avoid

November 5, 2010 © 2010 Microsoft Corporation. All rights reserved. Designing Digital Video Cameras to Meet Windows Logo Program Requirements - 19 retrieving video-only properties, and a video application can avoid retrieving image-only properties.

The following example shows one mapping of object properties into groups according to function. The first group contains the properties that all applications are likely to use. The properties in this group are common to at least two of the three media types—still images, video, and audio. The last three groups contain properties that are required only if the application handles still images, video, or audio, respectively. For example, an application that edits and plays videos with sound can typically avoid retrieving the properties that are exclusive to still images.

Example: Mapping object properties into groups Group 1: Properties common to still images, video, and audio:

StorageID (0xDC01) ObjectSize (0xDC04) ObjectFormat (0xDC02) ProtectionStatus (0xDC03) ObjectFileName (0xDC07) DateCreated (0xDC08) DateModified (0xDC09) ParentObject (0xDC0B) PersistentUniqueObjectIdentifier (0xDC41) Name (0xDC44) NonConsumable (0xDC4F) Width (0xDC87) Height (0xDC88) Duration (0xDC89) Group 2: Properties exclusive to still images:

ImageBitDepth (0xDCD3) FNumber (0xDCD4) ExposureTime (0xDCD5) ExposureIndex (0xDCD6) Group 3: Properties exclusive to video:

BitRateType (0xDE92) ScanType (0xDE97) VideoFourCCCodec (0xDE9B) VideoBitRate (0xDE9C) FramesPerThousandSeconds (0xDE9D) Group 4: Properties exclusive to audio:

SampleRate (0xDE93) NumberOfChannels (0xDE94) AudioBitRate (0xDE9A)

AudioWAVECodec (0xDE99) The mapping of properties to groups in this example is for a hypothetical device and might not be optimal for your device.

Handling Metadata on the Device Consider performance when you implement support for the following two basic actions on your MTP device:

Content enumeration Content transfer For both actions, performance depends on the ability to quickly access content metadata (for example, object format, object size, PUOID, and parent) in the device. For content enumeration, the device should retrieve the metadata and send it to the initiator as quickly as possible. For content transfer, the device needs to store metadata transferred from the initiator as quickly as possible to avoid impacting the overall throughput of data.

The following are suggestions for improving the overall efficiency with which metadata is handled.

Database or Accelerator File The device should store as many object properties as possible in a database or accelerator file. Ideally, this file should fit in fast memory to avoid the delay of accessing the data from a hard disk. Access to this file should be optimized for both reads and writes.

The accelerator file should persist across sessions with an initiator.

Avoid requiring the portable device to read or write tags (for example, Exif file tags) that are embedded in the content.

Constructing a Property List When returning a list of object properties to an initiator, the device should stream the property list in parallel with constructing the list. That is, the device can begin the transfer of property data to the initiator before it has finished constructing the entire list of properties. MTP provides a way for a DVC or other responder device to transfer a property list of unknown length. Thus, the device can begin the transfer before it has determined the total amount of data to be transferred.

Profiling Applications If you know which desktop applications your device is likely to communicate with, you should profile those applications to understand their behavior. In particular, you should determine:

The object properties that the applications are likely to request. The manner in which the applications send property requests to the device. The order in which the applications request the properties. Based on this profiling, you should organize the content metadata to improve the performance of property storage and retrieval by the applications.

Optimizations for Large Data Transfers The MTP specification describes optimizations for speeding up large data transfers between an MTP portable device (for example, a DVC) and an MTP initiator (for example, a Windows- based computer).

The following three optimizations are necessary to obtain the best performance from an MTP device that connects to a Windows computer:

Support for data container sizes that exceed the 4-gigabyte limit in the PTP specification. Splitting the header and data information during the data phase of a transaction. Getting an object property list of unknown length. For more information about these optimizations, see Appendix I of the MTP specification, "USB Optimizations”.

The first two optimizations in the preceding list require minor changes to the data transactions that are described in Annex D of the PTP specification (PIMA 15740). Thus, a device that implements these optimizations might be incompatible with a PTP initiator that does not support MTP. For example, these two optimizations are incompatible with some PictBridge printers. In addition, these two optimizations are incompatible with the PTP class driver in the initial release of Windows XP, and the PTP class driver in Windows XP with Windows Media Player 10 or Windows Media Player 11.

The third optimization in the preceding list requires support of the GetObjectPropList command, which is defined in the MTP specification but is not part of the PTP specification. Thus, support for this feature should not cause incompatibility with a PTP initiator.

Control Requests An MTP or PTP initiator can send a control request to an MTP or PTP responder device to cancel an operation that the device is performing, reset the device, or monitor the status of the device during a lengthy operation. For more information about control requests, see section D.5.2 of the PTP specification, "Class-Specific Requests”. For information about implementing control requests in an MTP device, see "Overview for MTP Device Developers" in the MTP Porting Kit.

To qualify to use the logo, an MTP device must support the following control requests.

Cancel Request After sending a command to an MTP or PTP device, an MTP or PTP initiator might need to cancel the command before the device finishes executing the command. For example, a user might click the Cancel Transfer button in Windows Media Player 11 to cancel a file transfer before the transfer completes. To cancel a previous command, the initiator sends a Cancel Request to the device. For more information about the Cancel Request, see the PTP specification.

Device Reset Request When an MTP or PTP device experiences a severe failure, the MTP or PTP driver can send a Device Reset Request to reset the device to its default idle state. For more information about the Device Reset Request, see the PTP specification.

Get Device Status Request While an MTP responder device performs a lengthy operation, an MTP initiator can issue a Get Device Status Request to determine whether the device is still operating correctly or has entered an invalid state. For more information about the Get Device Status Request, see the PTP specification.

USB Hardware We recommend that MTP devices conform to the USB 2.0 specification and implement the "Hi-Speed" data-rate option (480 megabits per second). In addition, we recommend that MTP devices use the standard USB Mini-B connector.

Windows Explorer and Custom Device Icons

Windows Explorer Windows Vista introduced a number of enhancements to Windows Explorer for displaying the properties of MTP devices. If a device implements the appropriate set of device and storage properties, Windows Explorer automatically displays this information. In addition, Windows Media Player will display an MTP device as available only if the device has the appropriate storage properties and if it supports at least one core audio or video format.

After connecting an MTP device to a computer that is running Windows Vista or later, the user can open Windows Explorer, select the "Computer" (or "My Computer") view, and inspect the properties of the device.

Windows Explorer takes the following steps to select an icon to represent an MTP device:

<1.> Windows Explorer determines whether the device supports MTP and supplies a custom icon. <2.> If the device supplies a custom icon, Windows Explorer uses this icon to represent the device. For more information, see the Custom Device Icons section in this document. If the device does not supply a custom icon, Windows Explorer selects a standard icon as follows: o If the device is a PTP camera that lacks MTP support, Windows Explorer uses the standard device class icon to represent the device. o If the device is MTP-compatible and supports the PerceivedDeviceType device property, Windows Explorer selects the standard icon that corresponds to the perceived device type. In Windows, Windows Explorer obtains the friendly device name that appears with the device icon as follows: <1.> If the portable device is MTP-compatible and supports the DeviceFriendlyName (0xD402) device property, and the property value is not an empty string, Windows Explorer uses this string for the friendly device name. <2.> If step 1 does not succeed, if the device provides a nonempty string for the Model field in the DeviceInfo data set, Windows Explorer uses this string for the friendly device name. <3.> If steps 1 and 2 do not succeed, if the user has installed a .inf file from the device manufacturer and the .inf file specifies a friendly device name for the device, Windows Explorer uses this name. <4.> If none of the preceding steps succeed, Windows Explorer uses the name "MTP Device" to identify the device. If an MTP device supports the DeviceFriendlyName property and allows the initiator to set the property, but the initial property value is an empty string, Windows Explorer automatically sets the property to the friendly device name that it obtains in steps 2 through 4 in the preceding list. In addition, Windows Explorer enables the user to select a friendly device name if the device allows the initiator to set the DeviceFriendlyName property.

All MTP and PTP devices support the GetDeviceInfo command that Windows Explorer (through the MTP or PTP class driver) uses to obtain the DeviceInfo data set. To qualify for a

November 5, 2010 © 2010 Microsoft Corporation. All rights reserved. Designing Digital Video Cameras to Meet Windows Logo Program Requirements - 23 logo, an MTP device must provide a nonempty string for the Model field in the DeviceInfo data set.

To view the device properties of an MTP or PTP device, the user can right-click the device icon and select Properties. The following table lists the device properties that Windows Explorer can display. The right column specifies the source of each property value.

Table 8. Standard device properties supported by Windows Explorer Property Source General name Same as the friendly device name that appears with the device icon. Model name The Model field of the DeviceInfo data set. Manufacturer The Manufacturer field of the DeviceInfo data set. Firmware version The DeviceVersion field of the DeviceInfo data set. Serial number The SerialNumber field of the DeviceInfo data set. Power source Always specified as "Battery". Battery level Required BatteryLevel (0x5001) device property. As indicated in the preceding table, the BatteryLevel device property is required. Windows Explorer displays a battery icon with a battery level.

To view a window that displays the storage areas in the device, the user can double-click the device icon. This window displays a storage icon for each storage area. The name of the storage area and the amount of free space in the storage area appear next to each icon.

The operating system obtains the name of a storage area as follows:

If the device supplies a string in the StorageDescription field of the StorageInfo data set, the operating system uses that string for the storage area name. Otherwise, the operating system obtains a name for the storage area by combining the storage ID with the information from the StorageType field of the StorageInfo data set. The resulting name might not be user-friendly (for example, "Removable storage 100001"). All MTP devices must support the GetStorageInfo command, which is the source of the StorageInfo data set that is mentioned in the preceding list. However, supplying a nonempty string for the StorageDescription field is optional for MTP devices. For more information about StorageInfo and storage IDs, see the MTP specification.

To determine how much free space is available in a storage area, Windows Explorer uses the information in the FreeSpaceInBytes field of the StorageInfo data set.

To view the properties of a storage area, the user can right-click the storage icon and select Properties. The following table lists the storage properties in Windows. The right column specifies the source of each property value.

Table 9. Property description of Explorer items Property Source General name Same as the storage area name that appears with the storage icon. Description The optional string from the StorageDescription field in the StorageInfo data set. File system The FileSystemType field from the StorageInfo data set. Used space The difference between the MaxCapacity and FreeSpaceInBytes fields from the StorageInfo data set. Free space The FreeSpaceInBytes field from the StorageInfo data set.

Capacity The MaxCapacity field from the StorageInfo data set.

Custom Device Icons Portable devices can optionally supply a custom icon. The icon image must conform to the Windows .ico file format. To retrieve the icon from the device, the MTP driver sends a request for the DeviceIcon (0xD405) device property to the device. DeviceIcon is an MTP property; it is not part of the PTP specification. The Windows Portable Device (WPD) API enables an application to access an MTP device's custom icon as a device resource. For more information about the WPD API, see the Platform SDK documentation on MSDN.

There are two ways to support the device icon feature. The first is by having an object available named “DevIcon.fil” on the root of the device. The second is by supporting the DeviceIcon MTP device property. If the DeviceIcon property is supported, the DevIcon.fil object from the root of the devices store will not be used. Note that Windows Media Player 10 does not support the DeviceIcon MTP device property method; it supports only the DevIcon.fil method. The object should be of the same type as an .ico file and should be implemented incorporating eight icons in the single object (4 sizes x 2 color depths), paying particular attention to:

Sizes (16x16, 32x32, and 256x256). The 256x256 size is recommended for optimal support (see below). Colors: 32-bit with 8 bit alpha (256x256 and 32x32), 8-bit with 1-bit transparency (16x16 and 32x32). Isometric angle. Drop shadow. Windows Media Player 10 only took advantage of the icon sizes of 32x32 and below. However, Windows Media Player 11 and future versions of the Windows shell make prominent use of the 256x256 images, so it is strongly recommended that this size be included in your icon object.

This icon is represented as a device resource in WPD, WPD_RESOURCE_ICON.

Windows 7 introduced Devices and Printers and Device Stage. Both of these features enable the use of photo-realistic icons to represent the device. For Devices and Printers the image is stored in an icon file, and the file must be specified in the DeviceIconFile element of the DeviceInfo XML document. Device Stage also makes use of XML to enable rich branding and customization to represent the device and also provide users with a way to interact with the device. See Windows Device Experience for more information.

This information can also be found in the Resources section.

DevIcon.fil Device firmware should be implemented such that an object named “DevIcon.fil” is enumerated on the root of the device, regardless of which storage is requested.

DeviceIcon Device Property In Windows Media Player 11 and later, a new MTP device property called DeviceIcon (0xD405) is defined. This property is requested by the initiator and expects the same icon data as above in the data phase of the response. If this property is supported, the DeviIcon.fil object will not be used. See below for the specification of the DeviceIcon MTP device property.

Table 10. MTP definition for the DeviceIcon device property Field name Field Size (bytes) Data type Value order

PropertyCode 1 2 UINT16 0xD405 Datatype 2 2 UINT16 0x4002 (AUINT8) Get/Set 3 1 UINT8 Device-Defined DefaultValue 4 Device-Defined GroupCode 5 4 UINT32 Device-defined FormFlag 6 1 UINT8 0x00 None This device property can be accessed on the computer via the WPD Property Key. Refer to the Resources section at the end of this document.

Icons in Win32 For more information about the format of Win32 .ico files and Win32 APIs so that they can be examined and manipulated, see the Icons article on MSDN.

Default Device Icons In Windows, the operating system supplies standard icons to represent a variety of MTP device types. The following diagram shows the standard icons that are available to represent the various types of MTP devices.

The operating system selects the generic MTP device icon to represent an MTP device that does not clearly belong to any of the other device types listed in the preceding diagram.

The device type icons in the preceding diagram correspond to the perceived device types that are described in section 5.2.1, "PerceivedDeviceType (0xD407)". If an MTP device does not supply a custom icon, and the device supports the PerceivedDeviceType device property, Windows Explorer uses this property to select the appropriate standard icon to represent the device. A minimum of device class identification is highly recommended for an improved user experience.

Windows Explorer will use the standard camera icon to represent a portable device that supports PTP but not MTP.

In the initial release of Windows XP, and in Windows XP with Windows Media Player 10 or Windows Media Player 11, the operating system treats an MTP device as a PTP camera, and Windows Explorer uses the standard camera icon to represent a portable device that supports either PTP or MTP.

Device Classes Seven device classes exist, identified by various subcomponents. To be identified as a specific device class, the Microsoft OS descriptor should be modified as follows.

Subcomponent identifiers

Table 11. MTP subcomponent identifiers MTP subcomponent identifier Perceived device Device class type (MTP device property) MS_COMP_MTP&MS_SUBCOMP 0x0 MTP generic _01 MS_COMP_MTP&MS_SUBCOMP 0x1 MTP digital still camera _02 MS_COMP_MTP&MS_SUBCOMP 0x2 MTP audio/video player _03 MS_COMP_MTP&MS_SUBCOMP 0x3 MTP mobile handset _04 MS_COMP_MTP&MS_SUBCOMP 0x5 MTP personal digital _05 assistant (PDA) MS_COMP_MTP&MS_SUBCOMP 0x4 MTP digital video camera _06 MS_COMP_MTP&MS_SUBCOMP 0x6 MTP audio recorder _07

General Windows Device Behavior Guidelines The logo program includes general requirements that all devices must comply with in order to qualify for the logo. Those requirements include basic transport capability compliance, typically with industry standards, and compliance with device power management settings. Those details are covered by reference in this document.

REQUIREMENT REFERENCE: PORTABLE-0022 PORTABLE-0048 PORTABLE-0057

Down-Level Solutions MTP drivers ship in Windows Media Player 10. However, Windows Media Player 10 can only be installed on computers running Windows XP or later. Windows Vista and later releases include MTP class drivers that will be installed by default for MTP devices. To receive the Windows 7 logo, the device must pass logo testing using the MTP class driver that ships in Windows.

REQUIREMENT REFERENCE: PORTABLE-0057

Dual (MSC+MTP) Mode Devices Other solution that device manufacturers may choose to consider is a “dual-mode” device. Many devices already support mass storage class (MSC) today. Microsoft has developed a solution whereby a device can detect the configuration of the computer to which it is connected and automatically switch to the appropriate mode of communication.

At a high level, the solution works by taking advantage of the fact that dual mode devices will support both a MSC USB class ID (0x08) and Microsoft’s proprietary OS descriptor. For more information, see the section about the OS Descriptor.

When the device is connected to the computer, the following installation steps take place:

<1.> The device provides a USB descriptor indicating support for Control, Bulk and Interrupt end points. <2.> The device provides an MSC class ID (0x08) indicating that it supports Mass Storage mode with the Control and Bulk endpoints. <3.> The device provides an OS descriptor indicating that it supports MTP mode. In versions of the operating system that support the OS descriptor, presence of the OS descriptor (on a device) takes precedence over a USB class ID. When the OS descriptor is detected during the install process, the PnP system will attempt to find a matching driver. If the MTP communications stack has been installed, a matching driver will be found and loaded (wpdusb.sys or similar component). If the MTP communications stack has not been installed, no matching driver will be found, and the computer will revert to the MSC class ID and load the USB MSC driver (usbstor.sys).

Once a driver has been loaded it will initiate communications with the device. We propose that by taking advantage of the unique nature of the communications initiated by each of these drivers, the device can determine which communication mode needs to be supported.

REQUIREMENT REFERENCE: PORTABLE-0031

MSC Identifier (usbstor.sys) The USB Mass Storage Class Bulk-Only Transport specification requires that every MSC Command Block Wrapper (CBW) start with a DWORD signature, 0x43425355. Microsoft’s MSC driver (usbstor.sys) complies with this requirement. An MSC device could use this signature and/or other information (such as the size of the command) to differentiate a CBW or MSC driver from other protocols or drivers.

Refer to the official USB documentation for more details on the specifics of CBWs.

MTP Identifier (wpdusb.sys or similar component) As outlined in the MTP spec, GetDeviceInfo must be issued to the device prior to any other operation. The Microsoft MTP class driver conforms to this requirement.

The following bit pattern, where the last four bytes are indeterminate, corresponds to the structure of the generic USB container packet for the GetDeviceInfo operation:

0000000C 0001 1001 xx xx xx xx

Note that the above hex string uses big-endian notation. Given that USB connections are always little-endian the pattern to look for is actually the following:

0c 00 00 00 01 00 01 10 xx xx xx xx

Windows Logo Program

Windows Logo Kit The Windows Logo Kit is used to validate the requirements defined for the logo program. This kit can also be used for product development. We encourage its use during the product development cycle of hardware in order to ensure device compliance with both Windows and industry standards. The kit includes several tests designed to validate device implementation and behavior at multiple levels. There are tests for USB compliance, MTP compliance, and WPD platform compliance that also cover device services validation.

The core tests provided for portable devices are:

MTP Compliance Tests WPD Compliance Tests WMDM Compliance Tests WMDM Sync Test For detailed description of these tests, please go to the Windows Logo Kit help documentation.

There is a significant amount of information available about the Windows Logo Kit, including user guides and video tutorials. For more information about the Windows Logo Kit, see: http://www.microsoft.com/whdc/winlogo/WLK/default.mspx

The kit is free to download and use.

Detailed Requirements

Connect Requirements The following requirements with ID starting CONNECT- are general bus type requirements that apply to any device that connects over that transport. For example, if a device supports connecting to a computer over USB, the USB connect requirements are required. CONNECT-0044, Version4 The USB device complies with implementation details from the USB specification Enforcement Date: 6/1/2006 Windows 7 – Required

Details

Any devices that are connected externally or internally to a USB port must be tested as USB devices—that is, the devices provide the capabilities of one or more functions, a hub to the host, or both, as described in USB Specification, Revision 2.0 or later, Chapters 9 and 11. Therefore, these requirements apply to any device that is connected to a USB port: the USB specification and any related USB device class specification, and the Windows logo program requirements for USB and the related device class. CONNECT-0045, Version4 USB serial numbers are implemented for specific device classes and are unique across specific device models Enforcement Date: 6/1/2006 Windows 7 – Required

Details

USB serial numbers must be implemented for the following device classes:

Bluetooth (Class Code 0xE0) Communication device class (Class Code 0x02) Mass storage (Class Code 0x08) Scanning/imaging (Class Code 0x06) Printing (Class Code 0x07) Host Wire Adaptors (Class Code 0xE0, subclass 02) Device Wire Adaptor (Class Code 0xE0, subclass 02, if supporting Isoch the Class Code 0xEF subclass 02) USB serial numbers are optional for all other device classes.

Design Notes

For more information on USB device class details, see "Defined 1.0 Class Codes" on the USB website.

For more information on implementation of serial numbers, see USB Specification, Revision 2.0 or later, Section 9.6. CONNECT-0048, Version5 Isochronous USB device and driver requirement Enforcement Date: 6/1/2006 Windows 7 – If Implemented

If Implemented Description

If a USB device supports alternate settings that consume isochronous bandwidth, it is subject to this requirement.

Details

ISO USB device and driver provide multiple alternate settings to support maximum flexibility of hardware interface options: If any alternate setting consumes isochronous bandwidth, devices and drivers must provide multiple alternate settings for each interface. USB device and driver do not use isochronous bandwidth for alternate setting 0: Devices and drivers must not use isochronous bandwidth for alternate setting 0. Devices must consume bandwidth only when they are in use. USB isochronous full-speed or high-speed device that uses more than 50 percent of USB bus bandwidth provides alternate settings: If a USB isochronous full-speed or high-speed device uses more than 50 percent of USB bus bandwidth, it must provide alternative settings that allow the device to switch to a setting that uses less than 50 percent of the bus bandwidth and operate as a device of that particular class (for example, if it is a camera, it must continue to stream video), even though the device(?) may be in a lower quality mode. Devices with attached host controllers are exempt from this requirement. USB device with interfaces containing isochronous endpoints has at least one alternative interface for low bandwidth scenarios:

USB device must provide at least one alternative interface for low bandwidth as described in USB Specification, Revision 2.0 or later, Section 9.6.5. Design Notes

See section 9.6.5 in the USB Specification, Revision 2.0.

If two or more devices are connected that use more than 50 percent of the bus bandwidth and do not provide alternate settings, only one of the devices works at a time.

See USB Specification, Revision 2.0 or later, Sections 5.6 and 5.7. CONNECT-0049, Version3 A USB hub or device that implements USB functionality complies with the related specification Enforcement Date: 6/1/2006 Windows 7 – Required

Details

USB devices or drivers that fit into one of the USB device class definitions must comply with the appropriate USB specification as follows:

USB 1.1, Revision1.1 USB 2.0, Revision2.0 CONNECT-0052, Version4 The USB device can be configured to any USB address Enforcement Date: 6/1/2006 Windows 7 – Required

Details

To ensure that the devices function at all device address ranges, USB devices must be able to be configured to any USB address that the host provides. The device must enumerate and function correctly at any address ranging from 1 to 127. See USB Specification, Revision 2.0 or later, Sections 9.1.1.4 and 9.4.6. CONNECT-0054, Version4 The USB device responds to all string requests that the host sends to indexes Enforcement Date: 6/1/2006 Windows 7 – Required

Details

USB devices must respond according to string requests that the host sends. Devices must stall if no string is stored at the index being queried or if a request error exists. Devices must not reset themselves or stop functioning. This is described in USB Specification, Revision 2.0 or later, Section 9.6. CONNECT-0056, Version4 A USB peripheral operates in function mode when connected to a computer host controller

Enforcement Date: 6/1/2006 Windows 7 – Required

Details

When connected to a system’s host controller, a USB peripheral must operate as a USB function only. A function is a USB device that provides additional capabilities to the host controller. This is described in USB Specification, Revision 2.0 or later, Section 4. CONNECT-0059, Version4 USB device responses to host requests are limited in size by the wLength field Enforcement Date: 6/1/2006 Windows 7 – Required

Details

All USB device requests contain a wLength field. Responses by the USB device to host requests must be of a size less than or equal to the wLength field of the device request as defined in the USB Specification, Revision 1.1 or later, Section 9.3.5. CONNECT-0061, Version4 A USB device that uses the iSerialNumber field ensures unique serial numbers across devices of the same model Enforcement Date: 6/1/2006 Windows 7 – If Implemented

If Implemented Description

If the USB device uses the iSerialNumber field, it is subject to the requirement.

Details

If a USB device uses the iSerialNumber index to the manufacturer-determined descriptor field, the serial number must be unique across devices of the same model. This specifically refers to devices that share the VID+PID+REV triple.

If two devices share the same VID and PID, they must have different serial numbers (regardless of the revision ID) because devnodes are generally based on a VID+PID combination and rarely involve the REV field.

USB serial numbers must be implemented for the following device classes:

Bluetooth (Class Code 0xE0) Communication device class (Class Code 0x02) Mass storage (Class Code 0x08) Scanning/imaging (Class Code 0x06) Printing (Class Code 0x07) Host Wire Adapter (Class Code 0xE0, subclass 02) Device Wire Adaptor (Class Code 0xE0, subclass 02, if supporting Isoch the Class Code 0xEF subclass 02) USB serial numbers are optional for all other device classes.

Design Notes

See USB Specification, Revision 2.0 or later, Section 9.6. CONNECT-0062, Version3 A USB device that implements manufacturer-defined serial numbers contains valid characters Enforcement Date: 6/1/2006 Windows 7 – If Implemented

If Implemented Description

If the USB device implements manufacturer-defined serial numbers, it is subject to the requirement.

Details

A USB serial number must be a string that contains a manufacturer-determined ID composed of valid characters. Valid characters are defined in the Windows Driver Kit, "USB_DEVICE_DESCRIPTOR".

Portable devices are required to support a USB serial number. CONNECT-0093, Version4 A USB device is USB IF certified Enforcement Date: 6/1/2011 Windows 7 – Required

Details

Change for Version 4: Enforcement Date moved out to 1 June 2011

Change for Version 3: Enforcement Date moved out to 1 June 2010

USB devices must pass USB IF test certification. CONNECT-0104, Version3 A USB device that signals device-attach responds after at least 100 ms Enforcement Date: 6/1/2006 Windows 7 – Required

Details

When the USB device has signaled device-attach, the operating system provides a debounce interval of 100ms. The device must respond at the end of that interval. This is described in USB Specification, Revision 2.0, Section 7.1.7.3. This requirement ensures that the electrical and mechanical connections are stable before the attached device is reset. CONNECT-0109, Version4 Attached USB devices must be functional after resuming from system power states Enforcement Date: 6/1/2009 Windows 7 – Required

Details

Devices not entering a timely ready state will be marked code 10 or other by the system. Certain classes of devices do not properly respond to system events, such as resume, and

November 5, 2010 © 2010 Microsoft Corporation. All rights reserved. Designing Digital Video Cameras to Meet Windows Logo Program Requirements - 33 require upper driver or expect precise boot timings in order to function properly. Devices also must be able to function without a port reset upon resume but also remain functional if a reset does occur.

A device must be in the attached state (USB Specification 2.0, section 9.1) to be configured and the device must be in the configured state before its functions may be used (that is, the device is useable). This is per USB Specification 2.0 as in section 9.1 and 9.2.6.2: “After a port is reset or resumed, the USB System Software is expected to provide a ’recovery’ interval of 10 ms before the device attached to the port is expected to respond to data transfers. The device may ignore any data transfers during the recovery interval”.

Design Notes

Clarification: Devices must function after resuming from system power states whether a port reset is issued or not. CONNECT-0123, Version1 A USB device should allow the operating system to load an alternate driver on the device Enforcement Date: 6/1/2010 Windows 7 – Required

Details

The device should retain basic USB functionality after driver re-enumeration.

For example, a driver to redirect IO to alternate paths requires re-enumeration. CONNECT-0130, Version1 USB 3.0 devices are backwards compatible with down-level controllers and hubs Enforcement Date: 12/1/2010 Windows 7 – Required

Details

USB 3.0 devices both enumerate and function on USB 2.0 controllers. USB 3.0 devices also need to enumerate and have functionality when connected to a full-speed hub, and enumerate and have functionality when connected to a high-speed hub (see USB 2.0 Specification section 5.3.1.1). “Functionality” is defined as operating as a user would expect a device of that class to operate.

Design Notes

USB 3.0 devices must:

Be able to reset successfully at high and full speeds. Respond successfully to standard requests at high and full speeds for device and configuration descriptors such as set_address, set_configuration, and get_descriptor, and then return appropriate information. USB 3.0 devices must also be able to function at a minimum level of intended functionality, though this level of functionality does not have to meet high-speed requirements. For example, a USB 3.0 mass storage device must be able to transfer files at full speed mode as well as at high speed mode. Data transfer is much slower at the lower speed, but is still possible.

CONNECT-0101, Version2 A network-enabled device that implements Devices Profile for Web Services (DPWS) must adhere to the protocol and schema Enforcement Date: 6/1/2008 Windows 7 – If Implemented

If Implemented Description

If DPWS is implemented, it must comply with the following specifications and requirements.

Details

A network-enabled device that implements Devices Profile for Web Services (DPWS) must adhere to the Devices Profile for Web Services as described by the schema.

The device must also reference the namespace URI as described in The Devices Profile for Web Service specification.

A device that implements DPWS must adhere to the Web Services Description Language (WSDL) associated with the logo device class. The WSDL defines services as collections of network endpoints, or ports. The WSDL specification provides an XML format for documents for this purpose. Devices must implement the WSDL version 1.1.

Design Notes

For more information, see the WSDL Version 1.1.

For more information, see the Devices Profile for Web Services schema.

For more information, see the Devices Profile for Web Service specification.

For more information, see the Windows Rally Development Kit.

Device Fundamentals Requirements Requirements with IDs beginning DEVFUND- are general device requirements that apply to any device. The following device fundamental requirements apply to portable devices. DEVFUND-0003, Version2 Plug and Play (PnP) IDs embedded in hardware devices, including each functional unit of a multi-function device, must have device IDs to support Plug and Play Enforcement Date: 6/1/2006 Windows 7 – Required

Details

Each device connected to an expansion bus must be able to supply its own device ID. Each function or device on a multi-function add-on device that is individually enumerated must also provide a device ID for the bus it uses.

The following are the specific requirements for PnP device IDs:

Each separate function or device on the system board must be separately enumerated. Therefore, each must provide a device ID for the bus it uses, as required in the current PnP specification. If a device on an expansion card is enumerated, it must have a unique ID and its own resources according to the current deviceID requirements for the bus to which the

card is connected. This includes devices that are separately enumerated on multifunction cards or multifunction chips. A PnP ID can be shared with other devices that have the same model name, as defined in the device-specific PnP specification. Each logical function of the device must have a distinct PnP ID. The INF [Install] section must key off only the most specific ID according to the PnP guidelines in the Windows Driver Kit. For legacy devices such as serial, parallel, and infrared ports, requirements and clarifications for automatic device configuration, resource allocation, and dynamic disable capabilities are defined in Legacy PnP Guidelines. Exceptions: Devices that are completely invisible to the operating system, such as out-of-band systems management devices or I2O hidden devices, still must use ACPI methods to properly reserve resources and avoid potential conflicts.

The following are the exceptions to individual device ID requirement for multi-function devices:

Multiple devices of the same device class, such as multiline serial devices. Devices that are generated by an accelerator or auxiliary processor and that do not have independent hardware IO. That processor must have an ID, and MF.sys must be used to enumerate the dependent devices. If an OEM uses a proprietary mechanism to assign asset or serial numbers to hardware, this information must be available to the operating system by using Windows hardware instrumentation technology.

Design Notes

For more information, see the Windows Hardware Instrumentation Implementation Guidelines (WHIIG), Version 1.0. DEVFUND-0030, Version2 Device and driver installation, uninstallation, and reinstallation must be completed without any error, including function drivers for a multi-function device Enforcement Date: 6/1/2009 Windows 7 – Required

Details

Device and driver installation, uninstallation, or reinstallation must not fail in any case.

Driver installation must not cause the system to stop running or restart without user interaction (unless a restart is required by the operating system).

In the case of multi-function devices (a single device supporting multiple functionalities) with separate drivers enabling separate functions, each driver must be capable of installing and uninstalling independently with no start order or hidden dependencies.

Devices that use inbox drivers for operation must also meet this requirement. This requirement is not applicable for iSCSI devices.

Design Notes

This requirement will enable a good user experience when installing or uninstalling device drivers. It is critical when the operating system is being upgraded.

In the case of multi-function devices, a supervisory driver that loads different drivers for the individual functions does not work well with Windows. In particular, driver support is likely to be lost following an operating system reinstallation or upgrade, or with distribution of new drivers through Windows Update. Therefore, such supervisory drivers should be avoided.

This requirement will be tested using the "Reinstall with IO" test in the Windows Logo Kit. DEVFUND-0034, Version1 All PnP devices must properly implement the CM_DEVCAP_REMOVABLE capability Enforcement Date: 6/1/2009 Windows 7 – Required

Details

All PnP devices must properly implement the CM_DEVCAP_REMOVABLE capability. Proper implementation of this capability allows the Windows operating system to correctly represent the physical device in the Windows shell.

Devices externally connected to the computer

Externally connected devices are those that are external to a computer or a system, and designed so the users can physically disconnect them easily from the computer or the system.

For a device that exposes a single function (one devnode for the physical device) and is externally connected to the computer and can be disconnected from the computer, the CM_DEVCAP_REMOVABLE capability must be set to true.

For a multifunction device (two or more devnodes for the physical device) that is externally connected to the computer and can be disconnected from the computer:

The topmost devnode in the device hierarchy must set the CM_DEVCAP_REMOVABLE capability to true. Children of the topmost devnode must set the CM_DEVCAP_REMOVABLE capability to false if they are physically embedded in the parent device. Children of the topmost devnode that can be physically removed from the device should set the CM_DEVCAP_REMOVABLE capability to true. The requirement for proper implementation of the CM_DEVCAP_REMOVABLE capability can be checked by opening the Device Center in the Windows shell. A device that has properly implemented the CM_DEVCAP_REMOVABLE capability will show one instance of the physical device in the Device Center.

Devices physically integrated into a computer or system

Physically integrated devices are those devices or components that are meant to be embedded in a laptop or inside the chassis of a desktop and are not meant to be physically removed by the user of the system. When a device has been integrated with a computer, it should not report itself as removable. The device is now considered part of the computer, and must be marked to reflect this relationship.

The CM_DEVCAP_REMOVABLE capability should not be set on the device in this case, allowing the Windows operating system to correctly detect the integrated relationship, show a single icon in the Device Center, and expose the functionality of the device through the computer.

Laptops: Devices or components that are inside the laptop and cannot be removed or are not intended to be removed by the user should not be marked as removable. Such devices typically include the keyboard, mouse touchpad, and LCD display. Devices that can be

removed (such as a hot-swappable DVD-ROM drive) should be marked as removable. The laptop should appear as a single display object when executing the dispobj4pc.exe tool.

Desktops: All devices inside of the computer chassis should not be marked as removable. The desktop should appear as a single display object when executing the dispobj4pc.exe tool.

The dipobj4pc.exe tool must be executed on the system to check if this requirement has been met. The tool is available in the Windows Logo Kit.

Design Notes

Please refer to the Multifunction Device Support white paper for complete information on the use of the removable capability and its proper implementation.

This requirement can be manually verified by performing the following steps:

Externally connected device

<1.> Install the device on the computer. <2.> Verify that the device has successfully installed. A successful installation includes: All devnodes for the device installed successfully. (No devnodes are partially installed, as indicated by a yellow exclamation point icon.) The device is fully functional. <3.> Verify that the device is powered on. <4.> Open the Devices and Printers folder. <5.> Locate the device in the Devices and Printers folder. There should only be one icon representing the device. Computer integrated device:

Execute the DispObj4PC.exe tool to make sure all equipped devices in computers report the removable value correctly. Verify that the device under testing is reported as non-removable when this tool is executed.

Portable Device Requirements Requirements beginning with PORTABLE- apply to portable devices. For your convenience only the requirements that apply directly to a digital video camera are included here. PORTABLE-0022, Version1 Portable devices must comply with Device Fundamentals requirements and all Device Connectivity requirements of all specific technologies utilized to connect to a Windows computer Enforcement Date: 6/1/2008 Windows 7 – Required

Details

In order to obtain the logo, a portable device must also comply with all Device Fundamentals requirements.

In addition, for each specific technology that is used to connect to a Windows computer, all Device Connectivity requirements specific to that technology must be met.

The following is a mapping between all the supported connectivity protocols and the requirements that must be met.

When the portable device connects to a computer using USB, all requirements in the DEVICE CONNECTIVITY / USB DEVICE Group/SubGroup must be met. When the portable device connects to a computer using wireless USB, all requirements in the DEVICE CONNECTIVITY / WIRELESS USB DEVICE Group/SubGroup must be met. If multiple technologies are used to connect to a computer, ALL requirements for each specific technology must be met. PORTABLE-0025, Version1 Portable devices support USB connectivity and are compliant with USB Specification Revision 2.0 Enforcement Date: 6/1/2009 Windows 7 – Required

Details

Portable devices must support connectivity to the computer over USB. They must also be USB 2.0 compliant and support both high-speed USB and full-speed USB connections.

Design Notes

Refer to USB Specification 2.0 for additional information.

There are no specific certification requirements for the type of USB connector used. PORTABLE-0031, Version1 Portable devices support Media Transfer Protocol (MTP) operations, device properties, and object formats depending on the type of portable device class supported Enforcement Date: 6/1/2009 Windows 7 - Required

Details

There is a core set of MTP operations, device properties, and object formats that must be met by each device category in order to be compliant with Windows. Implementation details for each operation, device property, and object format are defined in the Media Transfer Protocol Specification, Revision 1.0.

Table 12. Required operations Operation Cellular Portable Digital Digital Other Handset Media Camera Video Portable Player Camera

GetDeviceInfo R R R R R OpenSession R R R R R CloseSession R R R R R GetStorageIDs R R R R R GetStorageInfo R R R R R GetNumObjects R R R R R GetObjectHandles R R R R R GetObjectInfo R R R R R GetObject R R R R R SetDevicePropValue R R DeleteObject R R R R

SendObjectInfo R R R SendObject R R R GetDevicePropDesc R R R R R GetDevicePropValue R R R R R GetPartialObject R R R GetObjectPropsSupport R R ed GetObjectPropDesc R R GetObjectPropValue R R SetObjectPropValue R R GetObjectReferences R R SetObjectReferences R R

Table 13. Required device properties Device Property Cellular Portable Digital Digital Other Handset Media Camera Video Portable Player Camera

Battery Level R R R R Synchronization R R R Partner Device Friendly R R R Name Note that digital cameras are required to support the Battery Level property after June 2010.

The following operations are recommended, but not required:

FormatStore GetObjectPropList SetObjectPropList GetInterDependentPropDesc SendObjectPropList – For this command, your device must also support specification of destination, which allows the MTP initiator to dictate a parent handle for that object. Required object formats

The following table represents the list of required object formats for a portable device. Each object format also has a list of object properties that must be supported per object type.

Note that portable devices that are capable of playing audio and/or video must support at least one of these formats. This table does not represent the complete list of supported formats; it represents the list of commonly used formats.

Table 14. Required object formats Object Formats Cellular Portable Digital Digital Other Handset Media Camera Video Portable Player Camera

Undefined R R R Association R R R R R Abstract Audio R R Album

Abstract Audio & R R R(2) Video Playlist WAV R(2) R(2) MP3 R(2) R(2) AVI R(2) R(2) R(2) MPEG R(2) R(2) R(2) ASF R(2) R(2) R(2) EXIF/JPEG R(2) TIFF/EP R(2) BMP R(2) WMA R(2) R(2) AAC R(2) R(2) WMV R(2) R(2) R(2) MP4 Container R(2) R(2) R(2) 3GP Container R(2) R(2) R(2) Design Notes

See Appendix A – Object Formats in the MTP specification, Revision 1.0 for complete list of defined Device Properties.

See Appendix C – Device Properties in the MTP specification, Revision 1.0 for complete list of defined device properties.

See Appendix D – Operations in the MTP specification, Revision 1.0 for complete list of defined MTP operations.

For more information, see the Media Transfer Protocol Specification, Revision 1.

Additional implementation details can be found in the Windows 7 Portable Device Enabling Kit for MTP. PORTABLE-0034, Version1 Portable devices that support in-box device services implement these services according to the requirements defined in the MTP Device Services for Windows Specification Enforcement Date: 6/1/2009 Windows 7 – If Implemented

Details

The MTP Device Services architecture enables Windows to locate and use various services and content types located on a device. By creating extensions to the WPD API and MTP protocol, Windows can locate, consume, and interact with useful content and services on the device.

Supported Personal Information Management (PIM) services:

Contact Service Calendar Service Notes Service Tasks Service Other supported services:

Status Service

Hints Service Device Metadata Service Ringtones Service If the device supports one or more of the PIM synchronizations, it must also support one of two synchronization services to actually synchronize the data. Windows supports the following in-box synchronizations:

Enumeration Sync Anchor Sync The manufacturer should choose the services that are best suited for the device.

In addition to implementing these services on the device, the corresponding tasks or device properties must be supported in the Device Stage metadata package to be properly exposed to the end user.

Design Notes

See the MTP Device Services for Windows Specification.

See the Media Transfer Protocol Specification, Revision 1.0.

See also the Metadata Schema and Package Format Specification.

Additional implementation details can be found in the Windows 7 Portable Device Enabling Kit for MTP. PORTABLE-0035, Version1 Portable device implements custom MTP device services as defined in the MTP Devices Services Extension Specification Enforcement Date: 6/1/2009 Windows 7 – If Implemented

If Implemented Note

This applies only if a mobile phone implements a custom MTP device service.

Details

The MTP Device Services Extension to the Media Transfer Protocol (MTP) helps an MTP initiator, in this case Windows, find and access certain types of content stored on the device. Extension mechanisms have been defined that provide greater flexibility for applications that deal with specific content types defined by the device. These mechanisms provide greater extensibility than the existing data code mechanisms currently defined by the Media Transfer Protocol Specification, Revision 1.0.

If the portable device supports a custom device service, the implementation must have a valid ServiceInfo data set, a valid ServiceCapabilities data set, and a valid ServicePropertiesDesc data set as defined in the MTP Device Services Extension Specification. All mandatory properties defined in the specification must be supported in the custom service.

If scenarios that can be implemented using capabilities defined in the MTP 1.0 specification are not implemented using the operations, device properties, and other specifications defined in the MTP 1.0 specification, the device must define these scenarios in terms of device services and must support these services according to the requirements defined in the MTP Device Services Extension Specification.

To expose a custom device service in Device Stage, a custom task must be authored and defined as part of the Device Stage authoring process. This is described in the Microsoft Device Experience Development Kit.

Design Notes

Refer to the MTP Device Services Extension Specification.

Refer to the Microsoft Device Experience Development Kit.

Refer to the Media Transfer Protocol Specification, Revision 1.0. PORTABLE-0038, Version1 The portable device connects to the computer using USB, Bluetooth, or Wi-Fi connectivity and complies with additional requirements defined for that device connectivity type Enforcement Date: 6/1/2009 Windows 7 – If Implemented

If Implemented Note

If the device connects over one of these transports, it must also comply with general transport requirements.

Details

The portable device connects to a computer over at least one of the following connection types:

USB 2.0 Bluetooth 2.0 with EDR Wireless – PTP over IP; Windows Rally Technologies The device must also comply with applicable requirements defined in the Device Connectivity section of WinQUAL, unless superseded by the requirements defined here.

Design Notes

Refer to the specific Prepared Requirement Report on WinQUAL for additional information. PORTABLE-0043, Version1 A digital camera that has a metadata package and tasks qualifies for the Device Stage AQ Enforcement Date: 6/1/2009 Windows 7 – AQ

Details

To qualify for the Device Stage additional qualification (AQ), a digital camera must implement the following Tasks:

Browse files – Allows the user the ability to use the computer to view files and folders on the device.

Import your pictures and videos – Allows the user the ability to transfer pictures and videos from the device to the computer.

A device experience task is a representation of a device-related action that can be invoked by the user. The metadata package must adhere to the device class rules defined for digital cameras as described in the Metadata Schema and Packaging Format Specification. This specification contains several requirements for specific graphic sizes, icons, and others.

Design Notes

See the Metadata Schema and Package Format Specification. PORTABLE-0048, Version1 A portable device that can function as a Digital Media Controller (DMC), Digital Media Renderer (DMR), or Digital Media Service (DMS) must be DLNA 1.5 Certified and comply with requirements defined for Networked Media Devices Enforcement Date: 6/1/2009 Windows 7 – If Implemented

If Implemented Notes

If the portable device can function as a DMC, DMR, or DMS, it must comply with this requirement.

Details

Portable devices can function as a DMC, DMR, and/or DMS in Windows. The device must meet the requirements defined for those functions that are called out in the Networked Media Device section in LogoPoint.

DLNA 1.5 certification is required for each supported function and a valid certification ID must be included in the submission package.

Design Notes

Refer to the Networked Media Device section for requirement details. Information on DLNA certification can be found at http://www.dlna.org. PORTABLE-0055, Version1 The device supports the optional ModelID property to uniquely identify logical device functions on a multi-function device Enforcement Date: 6/1/2009 Windows 7 – If Implemented

If Implemented Notes

If the device implements the ModelID field, it must comply with this requirement.

Details

PnP has been extended to support a new devnode property called DEVPKEY_Device_ModelId. This key is used to store the ModelID value that some devices will store in a device-class- specific or manufacturer-specific manner on the device. The ModelID spans logical device functions on a multi-function device through an internal structure new to Windows 7 called the Display Object that aggregates logical devices in a single “piece of plastic” representation.

The ModelID can be as specific or as generic as the manufacturer chooses. For example, ModelID may differ between product models, colors of an individual model, or even individual devices. To support ModelID, the device property code 0xD302 must be supported.

Design Notes

Refer to the MTP Device Services Extension Specification that is included with the Windows Portable Device Enabling Kit. PORTABLE-0057, Version1 A device that supports MTP must meet mandatory general functionality requirements to facilitate expected behavior in Windows Enforcement Date: 6/1/2009 Windows 7 – Required

Details

Portable devices that include media playback functionality must be implemented using MTP according to the requirements defined in this document.

Supports transfer and storage of content

The device must allow the transfer and storage of digital media content.

Persists all transferred content

The device must not report receiving content that it has not persisted.

Accurately reports available capacity

The device must accurately report the available storage capacity of the device. The value reported must not be greater than the amount of data that can be transferred to the device. The device can report 1024 bytes or 1000 bytes as a kilobyte (KB).

Supports MTP drivers

Each device must work with the MTP drivers that ship with Windows. This means that they must install and work immediately without requiring the installation of additional drivers or software.

Supports MTP by default

Portable devices must ship with MTP enabled as the default connection mode. Devices can support Mass Storage Class (MSC) in addition to MTP if the following conditions are met:

The device must not have a persistent, user accessible setting to enable or disable the MTP or MSC mode. All storage volumes on the device (both internal and external) must be accessible using the MTP protocol. A device can have a safe mode that allows the user to boot to MSC mode for device recovery scenarios. After the user disconnects a device connected in safe mode, the device must resume normal operation.

Device responsiveness

A device must respond when it receives an MTP GetDeviceStatus control request issued by a host.

Allows unexpected device disconnects

An unexpected disconnect must not cause the device to stop responding (hang or crash) or to restart.

Device metadata

If a host sends an empty value for Album, Artist, or Title, the device must display meaningful text in place of the empty metadata and allow the user to find the content when searching on the associated field in the device UI. For example, a device might use Unknown Artist for the artist when it receives an empty value for artist metadata. If the device supports displaying genre metadata, then if a host sends an empty value for genre, the device must display meaningful text in place of the empty metadata and allow the user to find the content when searching on the associated field in the device UI. PORTABLE-0058, Version1 Devices that support MTP must meet basic interoperability requirements to successfully transfer content with an MTP aware media player application on Windows Enforcement Date: 6/1/2009 Windows 7 – Required

Details

An MTP based device must be able to transfer data to and from the computer using a Windows-based application that supports MTP. The following requirements must be met when interacting with Windows Media Player.

Supports digital media transfers from device to computer

The device must support digital media transfers to computers through applications that enable such transfers, such as the Portable Device Shell Namespace Extension and Windows Media Player.

Supports digital media transfers from computer to device

The device must support transfer of supported media formats from the computer to the device through Windows Media Player. The device must support transfer of all file formats from the computer to the device through the Windows Namespace Extension.

Supports metadata updates

The device must support updates to MTP metadata after the original track has been copied to the device. The metadata updates are performed using Windows Media Player.

Supports cancellation of transfer and synchronization

The device must support cancellations of transfers and synchronizations mid-task.

Properly identifies file types

The device must not rely on the file name extension of a file to discover the file type. The device must be able to use the MTP object format or can parse the file contents to determine the file type.

Playlist transfer

The device must support the transfer of playlists manually created by the user using Windows Media Player. When a manual playlist is transferred using Windows Media Player, both the playlist and the content the playlist references must reside on the device.

To receive playlists from Windows Media Player, a device must support object references. If object references are supported, they must be supported on all formats. Support for object references is indicated by supporting the following commands:

GetObjectReferences (0x9810) SetObjectReferences (0x9811) To receive playlists from Windows Media Player, the device must support the AbstractAudioVideoPlaylist (0xba05) format. A playlist is sent as a 0-byte object with a list of references to object handles for all objects contained in the playlist. PORTABLE-0060, Version1 Devices that support MTP must support mandatory control requests and events as defined in the Picture Transfer Protocol (PTP) specification Enforcement Date: 6/1/2009 Windows 7 – Required

Details

The PTP, of which the Media Transfer Protocol (MTP) is an extension, describes control requests and events. The PTP standard is maintained by the Photographic and Imaging Manufacturers' Association, Inc. (PIMA).

Control requests enable an MTP initiator to send out-of-band requests to the MTP responder. The device must support the following requests:

Get Status Cancel Request Reset Device Request If the portable device supports removable media that can be exposed to Windows, it must also support the following events.

StoreAdded (0x4004) StoreRemoved (0x4005) For more information about these events, see section G of the MTP specification.

Design Notes

For implementation details refer to Media Transfer Protocol Specification Revision 1.0.

See sections 12.5.4, 12.5.5, and D.5 in the "Picture Transfer Protocol (PTP) for Digital Still Photography Devices", Version 1.0 of the PIMA15740: 2000 Picture Transfer Protocol specification. PORTABLE-0062, Version1 Portable devices that support MTP must support the DeviceInfo data set as defined in the MTP specification Enforcement Date: 6/1/2009 Windows 7 – Required

Details

The device must support the MTP DeviceInfo data set. The following table describes field- specific requirements that must be implemented.

Table 15. Field-specific requirements Field Requirement Serial Number This field is required. A serial number must be unique among all devices sharing identical Model and Device Version fields. Manufacturer This field is required. Model This field is required. Device Version This field is required. Design Notes

For implementation details refer to Media Transfer Protocol Specification Revision 1.0. PORTABLE-0064, Version1 A portable device must support defined MTP object properties based on each consumable media format supported Enforcement Date: 6/1/2009 Windows 7 – Required

Details

The following device capabilities must be supported for each format reported by the device. If an MP4 container is supported, the device capability needs to include the proper properties in this entry. Based on this information, Windows can predict the proper transcode profile and transcode a file to the device that can then be played back on the device.

The following table summarizes required and recommended object property support for image, audio, and video objects.

Note that audio files in this context refer to music files; this requirement does not apply to audio files on the system such as voicemail or other recordings. This also does not apply to audio that is part of a container file.

Table 16. Object property support Object property Image Audio Video Artist Not required Required Not required Description Not required Not required Recommended Representative Sample Recommended Not required Not required Format Representative Sample Recommended Not required Not required Size Representative Sample Recommended Not required Not required Height Representative Sample Recommended Not required Not required Width Representative Sample Recommended Not required Not required Data Width Required Not required Required Height Required Not required Required Duration Not required Recommended Recommended User Rating Not required Recommended Recommended Track Not required Required Not required

Genre Not required Recommended Recommended Use Count Not required Recommended Recommended Parental Rating Not required Recommended Recommended Original Release Date Not required Recommended Recommended Album Name Not required Required Not required Album Artist Not required Required Not required Bitrate Type Not required Recommended Not required Sample Rate Not required Required Required Number of Channels Not required Required Required ScanType Not required Not required Required Audio WAVE Codec Not required Required Required Audio Bitrate Not required Required Required Video FourCC Codec Not required Not required Required Video Bitrate Not required Not required Required Frames Per Thousand Not required Not required Required Seconds Key Frame Distance Not required Not required Recommended Encoding Profile Not required If Implemented Required

Design Notes

For implementation details refer to Media Transfer Protocol Specification Revision 1.0, Appendix B – Object Properties. PORTABLE-0065, Version1 A portable device that supports MTP must support object properties for each consumable media format Enforcement Date: 6/1/2009 Windows 7 – Required

Details

Object properties enable metadata that describes objects to be exchanged separately from the objects themselves. The primary benefit of this functionality is to permit the rapid enumeration of large storages, regardless of the file system.

For each format that the device supports, the device must support all mandatory MTP object properties for that format. Additionally, if the device supports a recommended object property, the device must do so in conformance with the MTP specification and guidelines.

The following table summarizes required and recommended object property support for all object formats.

Table 17. Object property support Object property Status Description Storage ID Required The storage area that the object is stored in. Object Format Required The data format for the object. Protection Status Required The protection status of the object. Object Size Required The size of the data component of the object, in bytes. Object File Name Required The file name of the object. Date Modified Recommended The date and time when the object was last

altered. Parent Object Required The parent object of the object. Persistent Unique Required The persistent unique object identifier of the Object Identifier object. Name Required The name of the object. Non-Consumable Required Indicates whether the object was transferred to the portable device for storage only and is, therefore, not available to be consumed (for example, played) by the portable device. Design Notes

For implementation details refer to Media Transfer Protocol Specification Revision 1.0, Appendix B – Object Properties. PORTABLE-0066, Version1 A portable device that supports AbstractAudioAlbum objects must support specific object properties and optional album art Enforcement Date: 6/1/2009 Windows 7 – If Implemented

If Implemented Note

If the device supports AbstractAudioAlbum, this requirement must be met.

Details

Support for the following object properties is mandatory for AbstractAudioAlbum objects:

Genre (0xdc8c) Album Artist (0xdc9b) A device that supports both the AbstractAudioAlbum format and an image format can also support album art. Album art is attached to an AbstractAudioAlbum object by adding the art to the album's RepresentativeSampleData property. To support album art, the device must support the following object properties:

PurchaseFlag (0xd901), an object property in the Windows Media DRM 10 for Portable Devices MTP Extensions RepresentativeSampleFormat (0xdc81) RepresentativeSampleSize (0xdc82) RepresentativeSampleHeight (0xdc83) RepresentativeSampleWidth (0xdc84) RepresentativeSampleData (0xdc86) User Rating (0xdc8a) In addition, the portable device must support the WMPMetadataRoundTrip (0x9201) command.

Design Notes

For implementation details refer to Media Transfer Protocol Specification Revision 1.0. PORTABLE-0068, Version1

Digital cameras that support High-Definition (HD) formats qualify for the Windows HD Imaging additional qualification (AQ) Enforcement Date: 6/1/2009 Windows 7 – If Implemented

Details

To qualify for the Windows HD Imaging additional qualification the Digital Camera must support one (or more) of the following image formats.

Table 18. Required image formats HD Format File Name Specification Notes Extension RAW with WIC Multiple, vendor- See Design Notes The Windows defined for WIC. Imaging Component (WIC) is an imaging codec framework that enables image processing operations of any image format through a set of common APIs. Codec must support both 32-bit and 64-bit Windows. JPEG XR .hdp ISO/IEC 29199-2, JPEG XR Image Coding Specification HD Photo .wdp/.hdp HD Photo Feature This format may also Specification 1.0 be supported for implementations prior to JPEG XR adoption. Design Notes

For information on Windows Imaging Component (WIC), see the Windows Imaging Component Overview.

For information on JPEG XR, refer to the JPEG XR image coding specification.

For information on HD Photo, refer to the HD Photo Feature Specification 1.0.

Glossary The following are definitions of terms used in this document. Although these definitions cover common usage, they are not meant to be exhaustive or definitive. AQ = Additional Qualification Initiator The host computer or other device that initiates MTP operations over a USB (or other hardware interface) bus that connects to a responder.

Certificate A digitally signed statement that contains information about an entity and the entity's public key, thus binding these two pieces of information together. A certificate is issued by a trusted organization (or entity) called a certification authority (CA) after the CA has verified that the entity is who it says it is. Certificates can contain different types of data. For example, an X.509 certificate includes the format of the certificate, the serial number of the certificate, the algorithm used to sign the certificate, the name of the CA that issued the certificate, the name and public key of the entity requesting the certificate, and the CA's signature. Command An MTP operation request issued from the initiator to the responder. Continuous-tone still image A continuous-tone still image is an image whose accurate reproduction requires many gradations of gray or color intensity to avoid contouring artifacts. Data Phase An exchange of data between the initiator and the responder. The direction of the data phase is determined by the command being performed. Design and Implementation Notes The Design and Implementation Notes information provides a reference, a recommendation, or an implementation guideline to provide more information about the logo requirement. This information is not part of the Windows logo program requirement and is provided only for information. Device Container Grouping one or more device functions into a single device container lets Windows 7 represent these functions as a single "piece of plastic”. This closely aligns with the user's perception of the physical device. For example, a multifunction printer (MFP) with printer, scanner, fax, copier, and storage functions can appear in Devices and Printers as a single icon. Users can then interact with applications and services that are related to all the functions of this MFP through the Device Stage interface. In Windows 7, device containers are generated for existing hardware, whereas device makers can take advantage of the extended PnP interface to create device containers that are explicitly for new devices. Device Services “Device Services" is a brand new concept introduced in Windows 7 that provides a framework for device manufacturers to extend device functionality, and new APIs for applications to discover and access that extended functionality using the Windows Portable Devices (WPD) platform. We decided to call these extensions to device functionality "Device Services" because they foster rich interaction between the computer and devices by providing a model for devices to formalize extension capabilities and make these capabilities accessible to applications.

Device Stage Device Stage provides a new way for users to interact with eligible devices in Windows 7. It includes a visual interface that makes it easy for customers to find and use applications and services for their devices. Device Stage also provides a multifunction version of AutoPlay for certain eligible devices. Device makers that develop device experiences for Device Stage use a new set of XML schemas to specify rich branding and customization of the interface, including defining custom tasks to install software and links to services. Device makers can update their custom Device Stage experiences by submitting updates to Microsoft for distribution across the Internet to computers running Windows 7. Devices and Printers The Devices and Printers Control Panel makes it easy for users to view and use the devices that are connected to their computer. Users can open Devices and Printers in two ways: through Control Panel or by clicking the Start button. Devices and Printers gives users a device-centric experience in Windows 7. Through a new set of XML schemas that are supported in Windows 7, device makers can customize how the device is described and presented in Windows. Driver A program that enables a specific device to communicate with the operating system. Effective date This indicates when the requirement will be enforced by the Windows Logo Program. This document currently provides either a Month/Year or a Quarter/Year as the effective date. Future versions of the draft will provide a specific date when the requirement will be enforced. Embedded signed Embedded signed is code signing method which applies the certificate directly to a binary file. Event An MTP status notification issued from the responder to the initiator. Events are by nature out-of-band and may have no direct correlation with the current command being performed. If-implemented The if-implemented definition indicates what conditions cause the requirement to become effective. Any "I" indicates "if-implemented" and this definition will be inserted in the header for those requirements that need further explanation. Initiator The controlling, or host, device in an MTP protocol interaction. It is responsible for “initiating” operations with the attached client. All behavior during an MTP interaction is under the control of the initiator. The role of initiator is determined at the point the MTP protocol interaction is established and cannot change without the current interaction being disconnected or an additional interaction being established.

Media Transfer Protocol (MTP) class driver The MTP class driver is a Microsoft-supplied driver that runs on a Windows-based computer and initiates MTP operations over a USB cable (or other hardware interface bus) that connects to a responder. MTP camera A MTP camera is a Media Transfer Protocol (MTP)-compatible still image or digital video camera. MTP object A container for digital content that resides in a persistent storage area in a responder and can be transferred between the responder and the initiator. Persistent unique object identifier (PUOID) Identifies an MTP object that is stored in the DSC or digital video camera. The camera generates the PUOID at the time that it receives the object. The PUOID should be unique among all objects that the camera has ever received, including those that have since been deleted. PictBridge A CIPA standard (CIPA DC-001) for printing photographs by directly connecting a digital camera to a printer without intervention by a host computer. Picture Transfer Protocol (PTP) class driver The PTP class driver is a Microsoft-supplied driver that runs on a Windows-based computer and initiates PTP operations over a USB cable (or other hardware interface bus) that connects to a responder. PTP camera A PTP camera is a Picture Transfer Protocol (PTP)-compatible digital still image camera. Raw image file A raw image file is a file that contains the "raw" (unprocessed) image data from a digital camera or other image capture device. Responder The digital video camera or other portable device that responds to MTP operations that are initiated by an initiator. Required Items that are denoted as required must be implemented on the device or driver in order to qualify for the Windows Logo Program. Response The answering, or client, device in an MTP protocol interaction is responsible for “responding” to operations and requests from the attached host with a response. Responder The answering, or client, device in an MTP protocol interaction. It is responsible for “responding” to operations and requests from the attached host. The role of responder is determined at the point the MTP protocol interaction is established and cannot change without the current interaction being disconnected or an additional interaction being established.

Session The MTP session defines the lifetime of the MTP interaction and may be used by either the initiator or the responder to optimize interactions with the other party (for example, the initiator may perform caching on behalf of the responder to improve performance). MTP transactions typically occur within the confines of an MTP session. Transaction All MTP operations occur as atomic MTP transactions. In order of operation, each transaction consists of a command phase, an optional data phase, and a response phase. Each transaction must be completed before the start of next transaction. Transaction ID A value that increases monotonically starting from 0x00000001 that is associated with each MTP Transaction. 0x00000000 is reserved and may only be used with OpenSession or GetDeviceInfo operations. 0xFFFFFFFF is also reserved and must be used whenever this parameter is not applicable for the packet.

Acronyms The following is a list of common acronyms used within this document.

ASF – Advanced Systems Format

AVI – Audio Video Interleaved

CIPA – Camera and Imaging Products Association

DRM – Digital rights management

DSC – Digital still camera

DVC – Digital Video Class

Exif – Exchangeable interface file format

FOURCC – Four-character code

JEITA – Japan Electronics and Information Technology Industries Association

MSC – Mass Storage Class

MTP – Media Transfer Protocol

MTP/BT – MTP over Bluetooth

MTP/IP – MTP over Internet Protocol

PIM – Personal information management

PIMA – Photographic and Imaging Manufacturers Association

PTP – Picture Transfer Protocol

PTP/IP – PTP over Internet Protocol

PUOID – Persistent unique object identifier

RIFF – Resource Interchange File Format

TCP/IP – Transmission Control Protocol/Internet Protocol

USB – Universal Serial Bus

WIA – Windows Imaging and Acquisition

WPD – Windows Portable Devices

Resources The following resources provide additional detailed information for the topics that are discussed in this paper. Approved USB Class Specification Documents http://www.usb.org/developers/devclass_docs Capture Device Definition specification http://www.usb.org/ developers /devclass_docs/usb_still_img10.zip Description of the Windows Portable Devices http://support.microsoft.com/kb/971514 Device Management Guidelines http://windows.microsoft.com/en-us/windows7/products/features/device- management DeviceInfo XML document http://msdn.microsoft.com/en-us/library/ff541130(v=VS.85).aspx Devices Profile for Web Services http://specs. xmlsoap .org/ws/2006/02/devprof/devicesprofile.pdf DLNA http://www.dlna.org HD Photo Specification Download http://www.microsoft.com/whdc/xps/wmphoto.mspx Icons http://msdn.microsoft.com/en-us/library/ms997538.aspx ISO/IEC 29199-2:2009 http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm? csnumber=51609&commid=45020 Registered FOURCC Codes and WAVE Formats http://msdn.microsoft.com/library/en- us/dnwmt/html/registeredfourcccodesandwaveformats.asp USB Class Codes http://go.microsoft.com/fwlink/?LinkId=40497 Web Services Description Language (WSDL) 1.1 http://www.w3.org/TR/2001/NOTE-wsdl-20010315 Windows 7 Logo Program for Hardware Overview http://www.microsoft.com/whdc/winlogo/about_win7.mspx Windows 7 Portable Device Enabling Kit for MTP, Version 7R2 Prepared Requirement Reports https://winqual.microsoft.com/member/LogoPoint/Requirements/PreparedRequ irementReport.aspx

Windows Hardware Developer Central http://www.microsoft.com/whdc Windows Imaging Component Overview http://msdn.microsoft.com/en-us/library/ee719654.aspx Windows Portable Devices http://www.microsoft.com/whdc/device/wpd/default.mspx Windows Portable Devices Team Blog http://blogs.msdn.com/b/wpdblog/archive/2009/09/04/multi-transport-devices- in-windows-7.aspx

Development Tools and Support There are several development resources available for portable device manufacturers. For the most up to date information, refer to the WPD Team Blog. The following table provides links to various development resources for portable device manufacturers. Windows 7 Portable Device Enabling Kit for MTP http://www.microsoft.com/whdc/device/wpd/mtp-dek_win7.mspx Windows Portable Device Platform Information http://msdn.microsoft.com/en-us/library/dd388998(VS.85).aspx Windows Device Experience http://www.microsoft.com/whdc/device/DeviceExperience/default.mspx Microsoft Device Experience Development Kit http://www.microsoft.com/whdc/device/deviceexperience/dev-kit.mspx Windows Logo Program http://www.microsoft.com/whdc/winlogo/default.mspx Windows Logo Kit http://www.microsoft.com/whdc/winlogo/WLK/default.mspx If you have general questions about MTP or WPD development, contact [email protected].

Information about MTP Media Transfer Protocol Specification, Version 1.0 (broken) http://www.usb.org/developers/devclass_docs/MTP_1.0.zip MTP Device Services Extension Specification http://www.microsoft.com/whdc/device/wpd/mtpdevservext_spec.mspx MTP Device Services for Windows http://www.microsoft.com/whdc/device/wpd/mtp-devserv_win7.mspx Windows 7 Portable Device Enabling Kit for MTP, Version 7R2 http://www.microsoft.com/whdc/device/wpd/mtp-dek_win7.mspx In this kit, you can find portable device installation considerations, MTP Network Association extension to the MTP specification, and Wi-Fi-provisioning extension to the MTP specification. WPD Device Resource Icon http://msdn.microsoft.com/en-us/library/ms741097

WPD Properties and Attributes http://msdn.microsoft.com/en-us/library/ff597900(v=VS.85).aspx

Windows Logo Program for Hardware Resources There is a wealth of additional information that has been made available for this program. We strongly recommend that anyone participating in the logo program reviews the Windows Logo Program Webcasts. These are a series of videos that can be viewed on demand and that cover logo planning, testing, development, and how to submit logo packages using the qualification page on the Windows Quality Online Services site. The following are some key links that will help you navigate the Windows Logo Program Webcasts. General Windows Development Resources http://msdn.microsoft.com/en-us/library/cc300359.aspx Windows Logo Program: Overview http://www.microsoft.com/whdc/winlogo/default.mspx Windows Logo Program Webcasts http://www.microsoft.com/whdc/winlogo/logocast.mspx Windows Quality Online Services (Winqual) https://winqual.microsoft.com

Related documentation Audio Subtype GUIDS http://msdn.microsoft.com/en-us/library/aa372553 Design Rule for Camera File System, DCF Version 2.0 http://www.jeita.or.jp/english/public_standard Microsoft OS descriptors http://www.microsoft.com/whdc/connect/usb/os_desc.mspx Picture Transfer Protocol (PTP) for Digital Still Photography Devices, Version 1.0 of the PIMA 15740 http://www.i3a.org Picture Transfer Protocol over TCP/IP Networks (CIPA-005/2005) http://www.cipa.jp/ptp-ip/index_e.html Standard of Camera & Imaging Products Association CIPA DC-001—2003 Digital Solutions for Imaging Devices http://www.cipa.jp/english/pictbridge Universal Serial Bus Still Image Capture Device Definition, Version 1.0 http://www.usb.org UPnP Device Architecture version 1.1, Simple Service Discovery Protocol http://upnp.org/sdcps-and-certification/standards/device-architecture- documents

Appendix A: MTP Requirements The MTP specification includes implementation details for each of the required commands, responses and events, and properties that a DVC must implement in order to qualify for the Windows Logo Program.

REQUIREMENT REFERENCE: PORTABLE-0031

Required MTP Commands To provide the best customer experience, Microsoft requires that an MTP DVC implement the following MTP commands. Support for these commands is required to qualify to use the logo.

GetDeviceInfo (0x1001) This command gets the DeviceInfo data set from the MTP device. This data set contains information, such as model and serial number, to identify the device and describe its capabilities.

Typically, GetDeviceInfo is the first command issued by an initiator after connecting to an MTP device. GetDeviceInfo is the only command that an initiator can send without first opening an MTP session by sending an OpenSession command.

For more information about the DeviceInfo data set, see section 3.5.1 of the MTP specification, "DeviceInfo Dataset Description".

OpenSession (0x1002) This command opens a new MTP session for communication between the initiator and the MTP device. An MTP session is a communications context consisting of a persistent connection that has a connection state. Operations that depend on state parameters, such as object handles or storage IDs, require an active session. All operations that are described in this paper require an active session, unless otherwise specified.

CloseSession (0x1003) This command closes an active session. Upon closing the session, the MTP device should discard all of the state information that belongs to the session.

GetStorageIDs (0x1004) This command retrieves a list of storage IDs for the storage areas on the portable device.

GetStorageInfo (0x1005) This command retrieves a StorageInfo data set that describes a storage area on the portable device. When sending the command, the initiator specifies a storage ID to identify the storage area.

For more information about the StorageInfo data set, see section 5.2.2 of the MTP specification, "StorageInfo Dataset Description".

GetNumObjects (0x1006) This command retrieves a count of the number of MTP objects that are stored on the portable device. As an option, the initiator can use the first three command parameters to restrict the command to a subset of the objects on the portable device.

This command is mandated by the PIMA 15740 (PTP) specification but is not currently used by the MTP drivers that ship with Windows Media Player 10 and Windows Media Player 11.

GetObjectHandles (0x1007) This command retrieves an array of object handles that the initiator can use to access the MTP objects that are stored on the portable device. When sending the command, the initiator specifies whether to fetch the handles for all the objects on the portable device or just the objects that are contained in a particular storage area.

GetObjectInfo (0x1008) This command retrieves the ObjectInfo data set for the specified MTP object on the portable device. When sending the command, the initiator specifies an object handle to identify the object.

This command is mandated by the PIMA 15740 (PTP) specification. The MTP drivers that ship with Windows Media Player 10 and Windows Media Player 11 require that a portable device supports either the GetObjectPropList or the GetObjectInfo command, but not both. To improve performance, the drivers preferentially use GetObjectPropList if the device supports it. Otherwise, the drivers use GetObjectInfo.

For more information about the ObjectInfo data set, see section 5.3.1 of the MTP specification, "ObjectInfo Dataset Description”.

GetObject (0x1009) This command retrieves the binary data component of the specified object on the portable device. When sending the command, the initiator specifies an object handle to identify the object.

DeleteObject (0x100B) This command deletes an object or set of objects from the portable device. When sending the command, the initiator specifies an object handle to identify the object or set of objects to delete.

When the portable device deletes an object, it should delete all of the metadata that belongs to that object. In addition, it should remove all internal references to the deleted object (for example, from playlists and associations). The device should avoid assigning the handle value for a deleted object to a new object for the remainder of the session in which the object is deleted. Depending on the internal implementation of this policy, the device might allow the handle for the deleted object to persist until the session ends.

SendObjectInfo (0x100C) This command sends an ObjectInfo data set to the portable device to prepare it to receive a new object. The command provides the portable device with information about the upcoming object transfer and allows the device to indicate whether it can receive the object. Upon successful completion of this command, the initiator sends a SendObject command that sends the binary data component of the object to the device. Finally, the initiator can issue a series of SetObjectPropValue commands to send any additional object properties that are not in the ObjectInfo data set.

The SendObjectInfo command is not required if the portable device supports both the SendObjectPropList command and the set of object properties that replace the metadata in the ObjectInfo data set.

A device that implements the SendObjectInfo command must allow the initiator to specify a destination storage ID and parent handle for the object as optional command parameters.

For more information about the ObjectInfo data set, see section 5.3.1 of the MTP specification, "ObjectInfo Dataset Description”.

SendObject (0x100D) This command sends the binary data component of an MTP object to the portable device. A SendObject command always follows a successfully completed SendObjectInfo or SendObjectPropList command. The data component that is sent in a SendObject command conforms to the object description in the ObjectInfo data set that was sent in the SendObjectInfo or SendObjectPropList command that preceded it.

GetDevicePropDesc (0x1014) This command retrieves a DevicePropDesc data set that describes a device property. When sending the command, the initiator specifies a property code to identify the property.

For more information about the DevicePropDesc data set, see section 5.1.2.1 of the MTP specification, "Device Property Describing Dataset”.

GetDevicePropValue (0x1015) This command retrieves the current value of a device property. When sending the command, the initiator specifies a property code to identify the property.

GetPartialObject (0x101B) This command retrieves a partial object from the portable device. With this command, the initiator can play content that is stored as an MTP object on the portable device. As the initiator plays the content, the portable device streams the object to the initiator as a series of partial objects. This command allows only unprotected content to be played in this fashion.

If the portable device supports the one-wire PlayFromDevice extension to MTP, the MTP driver uses the commands in this extension instead of the GetPartialObject command. With this extension, the device can stream both protected and unprotected content to the initiator. For more information, see section 2.3.4 of this paper, "PlayFromDevice Extension Commands for One-Wire Playback“ which is available as part of the Device Enabling Kit download.

Recommended MTP Commands To provide the best customer experience, we recommend that an MTP DVC implement the following MTP commands, but support for these commands is not required to qualify to use the logo.

SendObjectInfo (0x100C) This command sends an ObjectInfo data set to the MTP device to prepare it to receive a new object. The command provides the device with information about the upcoming object transfer and allows the device to indicate whether it can receive the object. Upon successful completion of this command, the initiator sends a SendObject command that sends the binary data component of the object to the device. Finally, the initiator can issue a series of SetObjectPropValue commands to send any additional object properties that are not in the ObjectInfo data set of the object.

The SendObjectInfo command is not required if the MTP device supports both the SendObjectPropList command and the set of object properties that replaces the metadata in the ObjectInfo data set. The properties in the property set correspond to the fields in the ObjectInfo data set. For more information about ObjectInfo, see section 5.3.1 of the MTP specification, "ObjectInfo Dataset Description”.

InitiateCapture (0x100E) If the DVC supports still image capture, this command instructs the device to initiate the capture of one or more still images.

The DVC stores each image internally as an MTP object. As each newly captured object becomes available as a result of this command, the MTP camera is required to send an ObjectAdded (0x4002) event to the initiator.

After all objects are successfully captured, the device sends a CaptureComplete (0x400D) event to the initiator. If the store becomes full before all of the objects specified in the command have been captured, the device sends a StoreFull (0x400A) event instead of a CaptureComplete event to terminate the capture sequence.

The device should strictly observe the capture sequence that is described in section D.2.14 of the MTP specification, "InitiateCapture”. This section describes the ordering of commands, responses, and events during the capture of one or more still images in response to an InitiateCapture command. For example, the device must transmit its response to the InitiateCapture command before sending an ObjectAdded (0x4002) event to the initiator.

Typically, an MTP device that supports either the InitiateCapture or InitiateOpenCapture command, or both, supports the following device properties.

Table 19. Device properties supported by cameras Device property Description ImageSize (0x5003) Image width and height. CaptureDelay (0x5012) Delay from the receipt of the command to the start of the capture sequence. StillCaptureMode (0x5013) Capture mode—normal, burst, or time lapse. BurstNumber (0x5018) Number of images to capture. BurstInterval (0x5019) Interval between successive capture operations in a capture sequence. If an MTP device implements both the ImageSize property and the ResetDevicePropValue command (0x1017), the ResetDevicePropValue command should reset the ImageSize property to its default value.

FormatStore (0x100F) This command provides a way to quickly purge the MTP device of all content. It is faster than individually deleting each of the objects in the store. In response to this command, the MTP device deletes all user-accessible objects in its store, but it does not delete the license store, DRM software, device firmware, the wmpinfo.xml file (the file that maintains the synchronization relationship with Windows Media Player 11), or other protected information.

SetDevicePropValue (0x1016) This command sets the value of a device property in the MTP device. When sending the command, the initiator specifies both a property code—to identify the property—and a property value. The initiator-supplied property value conforms to the type and range information in the property descriptor that the initiator retrieved during a previous GetDevicePropDesc command.

GetObjectPropsSupported (0x9801) This command gets a list of all of the object properties that the device supports for a class of MTP objects that share a particular object-format type.

When selecting a set of object properties to support for a particular object format, hardware vendors should, if possible, avoid including properties that add significantly to the duration of GetObjectPropList operations. Slow response to GetObjectPropList commands can make the user interface in desktop applications appear unresponsive to users.

GetObjectPropDesc (0x9802) This command gets an ObjectPropDesc data set that describes a particular property of a class of MTP objects that share a particular object-format type. For more information about the ObjectPropDesc data set, see section 5.3.2.3 of the MTP specification, "Defining Object Properties”.

Hardware vendors can often improve device performance significantly by organizing object properties into groups of properties. If a device supports object property groups, the MTP driver can retrieve a group of object properties in a single GetObjectPropList command. For more information, see section 8.1 of the MTP 1.0 specification, "Object Property Groups“.

GetObjectPropValue (0x9803) This command gets the current value of an object property. When sending the command, the initiator specifies the object handle and property code.

SetObjectPropValue (0x9804) This command sets the current value of an object property in the MTP DVC. When sending the command, the initiator specifies the object handle and property code. The initiator-supplied property value conforms to the type and range information in the property descriptor that the initiator retrieved during a previous GetObjectPropDesc command.

GetObjectPropList (0x9805) This command gets an ObjectPropList data set that contains a list of property values from the device. When retrieving the values of several properties, this command is faster than using a series of GetObjectPropValue commands.

When sending this command, the initiator specifies an object identifier and either a property code or a property group code. As an option, the initiator can also specify an object format and a depth. The depth indicates how much of the object hierarchy below the object to traverse in constructing the property list.

For more information about the ObjectPropList data set, see section E.2.1 of the MTP specification, "GetObjectPropList”.

SetObjectPropList (0x9806) This command sets a list of property values in the portable device. When sending the command, the initiator specifies an ObjectPropList data set that contains the property values. When setting the values of several properties, this command provides a performance improvement over using a series of SetObjectPropValue commands.

For more information about the ObjectPropList data set, see section E.2.1 of the MTP specification, "GetObjectPropList”.

GetInterdependentPropDesc (0x9807) This command retrieves information about the interdependent properties of the portable device. Two or more properties are interdependent if changing the value of one property can change the constraints on the values that the other properties can assume. When sending the

November 5, 2010 © 2010 Microsoft Corporation. All rights reserved. Designing Digital Video Cameras to Meet Windows Logo Program Requirements - 63 command, the initiator specifies an object-format code that restricts the response to the list of interdependent properties for objects with the specified format.

For example, the range of allowed values for the bit rate of an audio file might depend on the sample rate, and vice versa. Each possible configuration of bit rate and sample rate values can be represented as a pair of property descriptors:

One descriptor specifies the bit rate value or range of values. The other descriptor specifies a sample rate value or range of values. All of the possible configurations of the two interdependent properties can be represented as a collection of such descriptor pairs.

The GetInterdependentPropDesc command retrieves an array of ObjectPropertyDesc arrays. Each ObjectPropDesc array element is a descriptor that specifies a value or range of values that a particular property can assume. Each ObjectPropDesc array describes a possible configuration of two or more interdependent properties. The array of ObjectPropDesc arrays is an exhaustive list of all of the possible configurations of all of the device's interdependent properties.

For a detailed example of an interdependent-property description, see section 7.5 of the MTP specification, "Multiple Codec Capabilities for the Same Format”.

SendObjectPropList (0x9808) This command sends an ObjectPropList data set to the MTP device to prepare the device to receive a new object. The command supplies the portable device with information about the upcoming object transfer and allows the device to indicate whether it can receive the object. Upon successful completion of this command, the initiator sends a SendObject command that transfers the binary data component of the object to the device.

This command is an optional replacement for the SendObjectInfo command, which is designed primarily to send information about objects that contain digital images. For content other than image data, the SendObjectPropList command typically provides improved performance over the SendObjectInfo command. When writing a new object to the portable device, the MTP driver uses the SendObjectPropList command if the device supports it. Otherwise, the driver uses the SendObjectInfo command to send the object information.

For more information about the ObjectPropList data set, see section B.2 of the MTP specification, "Object Property Descriptions”.

GetObjectReferences (0x9810) The target objects hold references to different objects. This command gets a list of these objects. When sending the command, the initiator specifies an object handle to identify the target object. In response, the device supplies a list of object handles that identify the objects to which the target object holds references.

SetObjectReferences (0x9811) This command replaces the list of objects to which the target object holds references. When sending the command, the initiator specifies an object handle to identify the target object, and a list of object handles that identify the objects to which the target object should hold references.

Responses and Events To qualify to use the logo, an MTP DVC must implement responses and events as described in the following sections.

REQUIREMENT REFERENCE: PORTABLE-0031 PORTABLE-0060

Responses The MTP DVC must return an appropriate response to each MTP command that it implements. For more information, see section 4.7 of the MTP specification, "Responses”.

Events An MTP DVC must meet the requirements for event support that are described in section 4.8 “Events” and G.2 “Event Descriptions” of the MTP specification. In particular, if the device supports removable storage, it must support the following events:

StoreAdded (0x4004) StoreRemoved (0x4005) For information about obtaining this specification, see Resources at the end of this paper.

StorageInfo Requirements The MTP specification requires an MTP device to support the StorageInfo data set. In addition, to qualify to use the logo, a DVC must satisfy the following requirements in its implementation of the VolumeIdentifier field in the StorageInfo data set.

VolumeIdentifier This field contains a volume identifier string that uniquely identifies the storage area across all MTP devices from the same manufacturer. An MTP device that does not handle protected content can set this field to an empty string.

An MTP device that supports content protection must provide a unique volume identifier. Typically, the volume identifier is the serial number of the embedded or plug-in storage device that implements the storage area.

This field can contain a string of up to 255 characters in length (including the terminating null character), but the MTP driver uses only the first 128 characters to identify the portable device. The first 128 characters of the volume identifier must be unique across all storage areas in all devices—regardless of model name or device version—that are made by the same manufacturer. If this field does not contain a string in which the first 128 characters are unique, it must contain an empty string.

DeviceInfo and Device Properties The following device information and properties are required or recommended for an MTP- compatible DVC that qualifies to use the Windows logo.

DeviceInfo Data Set An MTP device must support the DeviceInfo data set. The MTP specification requires all MTP portable devices to set portions of this data set to particular values to indicate that the devices support MTP. For information about obtaining this specification, see "Resources" at the end of this paper.

The device must supply nonempty strings for the Manufacturer, Model, DeviceVersion, and SerialNumber fields in its implementation of the DeviceInfo data set. The following sections describe the specific requirements for each field.

REQUIREMENT REFERENCE: PORTABLE-0031 PORTABLE-0062

Manufacturer These three fields are optional in the PIMA 15740 (PTP) specification, but are required for all DVCs. Each field is expressed as a string of 2-byte, Unicode characters that conforms to the string format that is described in section 5.1 of the MTP specification. The Manufacturer and Model fields should contain the user-friendly names of the device manufacturer and device model. The Device Version field should contain the device version number in a vendor-specific format.

The Manufacturer field must contain a human-readable string that identifies the manufacturer of the MTP device.

Model The Model field must contain a human-readable string that identifies the device model of the MTP device.

Device Version The Device Version field must contain a human-readable string that identifies the software or firmware version of the MTP device. The content of the version string is vendor-specific.

SerialNumber The SerialNumber field must contain a string that specifies a serial number to identify the MTP device. Device serial numbers must be unique among all portable devices that share identical Model and DeviceVersion fields. This field is optional in the PTP specification, but is required for all MTP devices.

For compatibility with legacy portable device drivers and applications, the serial number should be represented by a string of exactly 32 characters, including the terminating null. The string should express the serial number as a hexadecimal number, but no prefix (such as "0x") is required to indicate that the string contains a hexadecimal number. To ensure that the string length is exactly 32 characters, insert zeros (character "0") at the beginning of the string before the serial number to bring the length to 32 characters.

Mandatory MTP Device Properties To qualify to use the logo, a DVC must support the following core MTP device property.

REQUIREMENT REFERENCE: PORTABLE-0031

BatteryLevel (0x5001) This device property specifies the current battery level of the device. This is a get-only property. The constraints on the battery level value can be specified by either an enumeration or a range of integers. The highest value in the enumeration or range indicates that the battery is fully charged, and the lowest value indicates that no battery power remains. A value of 0 indicates that the device has an alternate power source.

The following table shows an example of a DevicePropDesc data set for a GetDevicePropDesc command that retrieves a description of the BatteryLevel property.

Table 20. DevicePropDesc data set for battery level Field Bytes Value OperationCode 2 0x1014 (GetDevicePropDesc) DevicePropCode 2 0X5001 (BatteryLevel) DataType 2 0x0002 (UINT8) GetSet 1 0x00 (get-only) FactoryDefaultValue 1 0x64 (fully charged) CurrentValue 1 0x64 (fully charged) FormFlag 1 0x01 (range form) MinimumValue 1 0x00 (alternate power source) MaximumValue 1 0x64 (fully charged) StepSize 1 0x0A

SynchronizationPartner (0xD401) This device property specifies a human-readable, friendly name of a synchronization partner for the device. A synchronization partner can be another device, a software application on a device, or a server on a network. This is a get-only property. The property value is a string of 2-byte, Unicode characters that conforms to the string format that is described in section 5.3.4 of the PIMA 15740 (PTP) specification, "Strings”. The string is suitable for display by a user-interface application that runs on the initiator.

The following table shows an example of a DevicePropDesc data set for a GetDevicePropDesc command that retrieves a description of the SynchronizationPartner property.

Table 21. DevicePropDesc data set for SynchronizationPartner Field Bytes Value OperationCode 2 0x1014 (GetDevicePropDesc) DevicePropCode 2 0XD401 (SynchronizationPartner) DataType 2 0xFFFF (string) GetSet 1 0x01 (get and set) FactoryDefaultValue 37 "Microsoft Windows" CurrentValue 43 "Longhorn Sync Engine" FormFlag 1 0x00 (no form fields)

DeviceFriendlyName (0xD402) This device property specifies the human-readable, friendly name of the device. The initiator can get and set this property. The property value is a string of 2-byte, Unicode characters that conforms to the string format that is described in section 5.3.4 of the PIMA 15740 (PTP) specification, "Strings”. The string is suitable for display by the user interface of an application that runs on the initiator device.

The following table shows an example of a DevicePropDesc data set for a GetDevicePropDesc command that retrieves a description of the DeviceFriendlyName property.

Table 22. DevicePropDesc data set for DeviceFriendlyName Field Bytes Value OperationCode 2 0x1014 (GetDevicePropDesc) DevicePropCode 2 0XD402 (DeviceFriendlyName) DataType 2 0xFFFF (string) GetSet 1 0x01 (get and set) FactoryDefaultValue 63 "Microsoft MTP Device Simulator" CurrentValue 75 "Microsoft MTP Device Simulator V0.85" FormFlag 1 0x00 (no form fields)

PerceivedDeviceType (0xD407) This device property specifies the device type as the user is likely to perceive it. Desktop applications can use this information to help the user to identify a particular device.

For example, if an MTP portable device is clearly a DVC, but also has a built-in camera function, the perceived device type is "digital video camera" rather than "camera”.

The property value identifies the MTP portable device as one of the perceived device types shown in the following table.

Table 23. DevicePropDesc data set for DeviceFriendlyName Value Perceived device type 0x00000000 Generic MTP device 0x00000001 Digital still camera 0x00000002 Media (audio or video) player 0x00000003 Mobile phone 0x00000004 Digital video camera 0x00000005 Personal information manager or personal digital assistant 0x00000006 Audio recorder A device type is "generic" only if the device does not clearly belong to any of the other device types in the preceding list. This is either a get-only or a get-and-set property.

For more information about this property, see the Windows Explorer and Custom Device Icons section of this paper.

Recommended MTP Device Properties The MTP specification defines a set of core device properties. For information about obtaining this specification, see the Resources section of this paper.

To achieve the best customer experience, we recommend that an MTP DVC supports the following core MTP properties, but they are not required by the Windows Logo Program.

FlashMode (0x500C) This device property specifies the current flash mode of the MTP device for image capture if supported. This can be a get-only or get-and-set property.

DateTime (0x5011) This device property specifies the current date and time settings of the MTP device. The property string is in date-time form, as described in the MTP specification. This can be a get- only or get-and-set property.

DeviceIcon (0xD405) This device property specifies an icon to represent the device. The property value is an icon image that conforms to the Windows .ico file format. This can be a get-only or get-and-set property.

Object Format Support The following object formats are required or recommended for a DVC that qualifies to use the logo.

Mandatory Formats To qualify to use the logo, an MTP DVC must support the following object formats. In addition, the device must support at least one file format that is supported natively in Windows.

REQUIREMENT REFERENCE: PORTABLE-0031

Undefined Object (0x3000) This format allows a portable device to receive an object that is encoded in an arbitrary format regardless of whether the device explicitly supports the format.

Association (0x3001) This format is required for implementing file folders.

Optional Formats The following format types are optional for a DVC; however, the device must implement at least one video format that is supported in natively in Windows.

Unknown Image Object (0x3800) This format is used for raw image files. A raw file contains an image that is in essentially the same format it is produced in by a digital camera or imaging device with little or no additional processing. Note that only an MTP-compatible DSC or digital video camera that supports raw images requires support for this format.

We recommend that MTP devices that support raw image files also support the SessionInitiatorVersionInfo (0xD406) device property. This property indicates the version of the initiator that the camera is connected to. The camera can use this property to determine whether the initiator is a version of Windows that uses a PTP driver or an MTP driver to communicate with the camera. The initial release of Windows XP, and Windows XP with Windows Media Player 10 or Windows Media Player 11, use a PTP driver to communicate with the camera. This driver does not recognize an object with format code 0x3800 as a valid image file. Thus, desktop applications might be unable to access raw image files that use this format code. Windows Vista uses an MTP driver to communicate with the camera, and this driver properly recognizes 0x3800 as the format code for a raw image file. If the camera determines from the value of the SessionInitiatorVersionInfo property that the initiator does not recognize format code 0x3800, the camera can change the format code of its raw image files to another value. For more information, see section C.2.42 of the MTP specification, "Session Initiator Version Info”.

Exif/JPEG (0x3801) This is the format of an Exif/JPEG image file. JEITA has specified this format as part of the DCF standard to enable interoperability between imaging devices.

MP3 (0x3009) MPEG-1 Audio Layer 3 format. This format is recommended for all portable devices.

ASF (0x300C) Advanced Systems Format.

Tiff (0x380D) Tagged Image File Format stores bitmap images in tagged fields. This format is useful for MTP devices that store uncompressed image data.

WIA (0xB881) A file format for continuous-tone still images. We recommend this format for MTP devices that use the Windows Media Photo codec.

WMA (0xB901) We recommend this format for MTP devices that play audio.

AbstractAudioAlbum (0xBA03) The AbstractAudioAlbum format is recommended for two reasons:

It is required to support album art. It enables the device to organize its content to provide a better browsing experience. It enables compilation albums to be consolidated under a Various Artists menu rather than having songs scattered across multiple artist entries one or two tracks at a time. For information about the object property requirements for this format, see section 7.6 of the MTP Specification, "Mandatory Object Properties for AbstractAudioAlbum“.

AbstractAudioVideoPlaylist (0xBA05) The AbstractAudioAlbum format is required in order to receive playlists from Windows Media Player 10 and Windows Media Player 11.

Recommended Formats To achieve the best customer experience, we recommend that an MTP video camera support the following object formats, but these formats are not required by the logo program.

AVI (0x300A) Audio Video Interleaved is a Windows multimedia file format based on RIFF. It is useful for combining audio and video content. We recommend that MTP devices that can capture video support this format.

ASF (0x300C) Advanced Systems Format is an extensible file format that facilitates the transfer of digital media streams. We recommend that MTP devices that can capture video support this format.

Undefined Firmware (0xB802) This format enables users to install firmware updates to upgrade the capabilities of their devices. Device vendors can encode their firmware updates in proprietary data formats.

WMV (0xB981) We recommend this format for MTP devices that capture video.

Other Useful Formats We recommend the following object formats for MTP devices that capture video in MPEG-1, MPEG-2, or MPEG-4 format:

MPEG (0x300B) We recommend this format for MTP devices that capture video in MPEG-1 format.

MP2 (0xB983) We recommend this format for MTP devices that capture video in MPEG-2 format.

MP4 Container (0xB982) We recommend this format for MTP devices that capture video in MPEG-4 format.

Windows Supported Audio and Video Formats Windows has significantly increased its ability to render content to a device over various content types. The goal is to provide users a seamless playback experience when rendering content to the device.

Audio rendering to the device - should support at least one in-box audio format. Video rendering to the device - should support at least one in-box video format. The following tables represent the list of in-box formats that Windows will render to.

Note that we do not recommend that all bit rates and sample rates be supported for each format listed in the tables below. However, we recommend that the selected format fits within the highest quality in the ranges provided. We recommend that you use the highest quality possible.

MP4 Audio Content

Table 24. In-box formats for MP4 audio content Setting Value AAC Codec AAC Standard, AAC Profile level 2 minimum (0x29), compatible with (0x29, 0x2A, 0x2B, 0x2C, 0x2E, 0x2F, 0x30, 0x31, 0x32, 0x33) Bit rate for CBR files 96, 128, 160, or 192 kilobits per second (Kbps) Sample rate 44.1 or 48 kilohertz (kHz) Channels 2

MP3 Audio Content

Table 25. In-box formats for MP3 audio content Setting Value MP3 Codec Version1, Layer3 Bit rate for CBR files From 32 to 320 Kbp) Sample rate 16, 22.05, 24, 32, 44.1, or 48 kHz Channels 2

WMA Audio Content

Table 26. In-box formats for WMA audio content Setting Value WMA Standard Codec WMA9 or later Bit rate for CBR files From 32 to 256 Kbps Average bit rate for VBR files From 48 to 160 Kbps Maximum peak bit rate for VBR 256 Kbps files Sample rate 44.1 or 48 kHz Channels 2

MP4 Container Content

Table 27. In-box formats for MP4 container content Setting Value AAC Codec AAC Standard, minimum AAC Profile level 2 (0x29), compatible with 0x29, 0x2A, 0x2B, 0x2C, 0x2E, 0x2F, 0x30, 0x31, 0x32, 0x33 Bit rate for CBR files 96, 128, 160, or 192 Kbps Sample rate 44.1 or 48 kHz Channels 2 H.264 Codec H.264 Standard Codec profile Baseline, Level 3 Resolution, pixel aspect ratio Any (as long as reported) Frame rate Any (as long as reported) Average bit rate Any (as long as reported)

Mobile WMV Video Content

Table 28. In-box formats for Mobile WMV video content Setting Value WMA Standard Codec WMA9 or later Average bit rate From 48 to 96 Kbps Maximum peak bit rate 192 Kbps Sample rate 44.1 or 48 kHz Channels 2 WMV Codec VC-1 Codec profile Simple Resolution, pixel aspect ratio One of the following: 176×144 pixels, 1:1 220×176 pixels, 1:1 Frame rate 15 or 24 frames per second Average bit rate From 96 to 384 Kbps Maximum peak bit rate 768 Kbps Maximum buffer 3 seconds Maximum key-frame distance 15 seconds Color depth 16 bits per pixel

Portable WMV Video Content

Table 29. In-box formats for portable MWV video content Setting Value WMA Standard Codec WMA9 or later Average bit rate From 48 to 128 Kbps Maximum peak bit rate 256 Kbps Sample rate 44.1 or 48 kHz

Channels 2 WMV Codec VC-1 Codec profile Simple Resolution, pixel aspect ratio One of the following: 320×240 pixels, 1:1 480×270 pixels, 1:1 Frame rate 24, 25, or 29.97 frames per second Average bit rate From 384 to 850 Kbps Maximum peak bit rate 1,700 Kbps Maximum buffer 3 seconds Maximum key-frame distance 15 seconds Color depth 16 bits per pixel

Standard WMV Video Content

Table 30. In-box formats for Standard WMV video content Setting Value WMA Standard Codec WMA9 or later Average bit rate From 64 to 192 Kbps Maximum peak bit rate 360Kbps Sample rate 44.1 or 48 kHz Channels 2 WMV Codec VC-1 Codec profile Main Resolution, pixel aspect One of the following: ratio 640×480 pixels, 1:1 720×480 pixels, 10:11 720×480 pixels, 40:33 Frame rate 24, 25, or 29.97 frames per second Average bit rate From 1,000 to 3,000Kbps Maximum peak bit rate 6,000 Kbps Maximum buffer 2 seconds Maximum key-frame 15 seconds distance Color depth 16 or 24 bits per pixel

High Definition WMV Video Content

Table 31. In-box formats for high definition WMV video content Setting Minimum values WMA Standard Codec WMA9 or later Average bit rate From 64 to 192 Kbps Maximum peak bit rate 360 Kbps Sample rate 44.1 or 48 kHz Channels 2 WMA Professional Codec WMA9 or later Average bit rate From 320 to 1,500 Kbps Maximum peak bit rate 2,500 Kbps Sample rate 44.1, 48, or 96 kHz Channels up to 8 WMV Codec VC-1 Codec profile Advanced Resolution, pixel aspect 1280×720 pixels, 1:1 ratio Frame rate 24, 25, or 29.97 frames per second Average bit rate From 8,000 to 10,000 Kbps Maximum peak bit rate 20,000 Kbps Maximum buffer 2 seconds

Maximum key-frame 15 seconds distance Color depth 24 bits per pixel

Object Property Support The following sections provide information on the object property requirements and recommendations for an MTP-compatible DVC. These properties are defined in the MTP specification.

REQUIREMENT REFERENCE: PORTABLE-0064 PORTABLE-0065

Mandatory Object Properties for All Formats An MTP device must support the following object properties for audio or video objects, regardless of which object formats the device supports.

StorageID (0xDC01) This object property identifies the storage area that the object is stored in. A storage ID is a 4- byte, unsigned integer that the MTP camera assigns to identify a storage area in the camera. A storage ID is unique among all storage areas in a particular camera. This is a get-only property.

The value of this property must be the same as the value in the first field of the ObjectInfo data set.

ObjectFormat (0xDC02) This object property specifies the data format for the object. This is a get-only property.

The value of this property must be the same as the value in the second field of the ObjectInfo data set.

ProtectionStatus (0xDC03) This object property specifies the protection status of the object. This is a get-only property.

The value of this property must be the same as the value in the third field of the ObjectInfo data set.

ObjectSize (0xDC04) This object property specifies the size of the object (that is, the data component of the object) in bytes. This is a get-only property.

The value of this property must be the same as the value in the fourth field of the ObjectInfo data set (that is, the ObjectCompressedSize field), unless it is greater than the maximum size that can be represented in that field.

ObjectFileName (0xDC07) This object property specifies the file name of the object. This is a get-and-set property.

The value of this property must be the same as the value in field 16 of the ObjectInfo data set.

ParentObject (0xDC0B) This object property specifies the parent object of the object. The property value is the object handle of the parent object. If the object has no parent object, the property value is 0x00000000. This is a get-only property.

The value of this property must be identical to the value of field 12 of the ObjectInfo data set.

PersistentUniqueObjectIdentifier (0xDC41) This object property specifies the persistent unique object identifier (PUOID) of the object. The MTP device assigns the PUOID to the object at the time that the device receives the object from the initiator. The initiator cannot alter the PUOID. No two objects in the same device should have the same PUOID. The PUOID should be unique among all objects that the device has ever received, including those that have since been deleted. This is a get-only property.

Name (0xDC44) This object property represents the name of the object. Frequently, the object name is the same as the file name (as represented by the FileName object property). However, the Name property provides a unique and human-readable identifier that is consistently available regardless of whether the object has a file name and the file name is unique. This is a get-and-set property.

Recommended Object Properties for All Formats To achieve the best customer experience, we recommend that all MTP DVCs support the following object properties, but they are not required in order to qualify to use the logo.

DateCreated (0xDC08) This object property specifies the date and time that the object was created. This is either a get-only or a get-and-set property.

The value of this property must be the same as the value in field 17 of the ObjectInfo data set.

We strongly recommend that MTP DVCs support this property. Desktop applications such as the Microsoft Windows Photo Gallery Photo Import wizard use this property to identify new pictures that the device has taken since the previous MTP session. If a device does not support this property, the application might have to treat all pictures on the device as new. In that case, the application might import all of the pictures on the device, causing processing delays. In addition, users might have difficulty finding their new pictures in the longer list of pictures.

DateModified (0xDC09) This object property specifies the date and time that the object was last modified. This is either a get-only or a get-and-set property.

The value of this property must be the same as the value in field 18 of the ObjectInfo data set.

NonConsumable (0xDC4F) This object property indicates whether the object has been placed in the MTP device for storage only and is, therefore, not available to be consumed by the user of the device (that is, displayed or played by the device). This is a get-and-set property.

If an MTP device supports this property for any object, it must support the property for all objects in the device. If the device does not support the property, the lack of support for the property implies that all object data in the device is available to be consumed.

Mandatory Properties for Image Formats An MTP DVC that uses still image formats must support the following object properties.

Width (0xDC87) This object property specifies the image width in pixels. This is either a get-only or a get-and- set property.

Height (0xDC88) This object property specifies the image height in pixels. This is either a get-only or a get-and- set property.

Recommended Object Properties for Image Formats To achieve the best customer experience, we recommend that MTP DVCs that support still image formats also support the following object properties, but they are not required in order to qualify for the logo.

REQUIREMENT REFERENCE: PORTABLE-0031 PORTABLE-0068

CreatedBy (0xDC45) This object property identifies the application, user, or organization that originally created the object. This property does not identify the person who created the intellectual property contained in the object—that information should be specified by the Artist property (0xDC46). This is a get-and-set property.

If the MTP device created the object, the CreatedBy property should contain some combination of the Manufacturer and Model fields of the DeviceInfo data set or, alternatively, the value contained in the DeviceFriendlyName device property.

Artist (0xDC46) This object property identifies the artist or artists who created the intellectual property contained in the object. This is a get-and-set property.

SerialNumber (0xDC51) This object property specifies the serial number for the device that captured the image. This is a get-and-set property.

RepresentativeSampleFormat (0xDC81) This object property specifies the object format of the representative sample for the object. For a portable device that supports the AbstractAudioAlbum format, this property is necessary to support album art. This is a get-only property.

RepresentativeSampleSize (0xDC82) This object property specifies the size, in bytes, of the representative sample for the object. This is either a get-only or a get-and-set property.

RepresentativeSampleHeight (0xDC83) This property specifies the height in pixels of the representative sample for the object. This is either a get-only or a get-and-set property.

RepresentativeSampleWidth (0xDC84) This object property specifies the width in pixels of the representative sample for the object. This is either a get-only or a get-and-set property.

RepresentativeSampleData (0xDC86) This object property is used to store the data for the representative sample for the object. This is either a get-only or a get-and-set property.

ImageBitDepth (0xDCD3) This object property specifies the image depth in bits. This is either a get-only or a get-and-set property.

FNumber (0xDCD4) This object property specifies the aperture setting of the camera lens at the time that the still image was captured. This is a get-and-set property.

ExposureTime (0xDCD5) This object property specifies the shutter speed of the camera at the time that the still image was captured. This is a get-and-set property.

ExposureIndex (0xDCD6) This object property specifies the emulated film speed of the digital video camera at the time that the still image was captured. The settings of this property correspond to the International Organization for Standardization (ISO) definition for film-speed sensitivity. This is a get-and-set property.

Mandatory Object Properties for Video Formats To qualify to use the logo, a DVC must support the following object properties for each video format supported by the device.

Width (0xDC87) This object property specifies the image width in pixels. This is either a get-only or a get-and- set property.

Height (0xDC88) This object property specifies the image height in pixels. This is either a get-only or a get-and- set property.

SampleRate (0xDE93) This object property specifies the audio sampling rate in the data format of the object. This property applies to either an audio file or to a file that combines audio with video or other types of content. An object with no audio content is not required to support this property. This is either a get-only or a get-and-set property.

NumberOfChannels (0xDE94) This object property specifies the number of audio channels in the data format for the object. This property applies to either an audio file or to a file that combines audio with video or other types of content. An object with no audio content is not required to support this property. This is a get-and-set property.

ScanType (0xDE97) This object property specifies the type of progressive or interleaved scan used by the video format. This is a get-and-set property.

AudioWAVECodec (0xDE99) This object property specifies the WAVE codec tag for an object that contains audio content that is encoded in a registered WAVE format. The list of valid WAVE codec tags for this property is presented in the “Registered FOURCC Codes and WAVE Formats” article on MSDN, listed in the Resources section of this paper. This property is useful for managing file container formats that support more than one audio data format. For example, an Advanced Systems Format (ASF) file might contain audio data that has been encoded in Windows Media Audio (WMA) or WMA Pro format. This is a get-and-set property.

AudioBitRate (0xDE9A) This object property specifies the bit rate for the audio content of the object. This property applies to either an audio file or to a file that combines audio with video or other types of content. An object with no audio content is not required to support this property. This is either a get-only or a get-and-set property.

VideoFourCCCodec (0xDE9B) This object property specifies the FOURCC codec tag for the video format. The list of valid WAVE codec tags for this property is presented in the article "Registered FOURCC Codes and WAVE Formats," listed in the Resources section of this paper). This property is useful for managing file container formats that support more than one video data format. For example, an Advanced Systems Format (ASF) file might contain video data that has been encoded in Windows Media Video 9 (WMV3) or Windows Media Video 9 Image (WMVP) format. This is a get-and-set property.

VideoBitRate (0xDE9C) This object property specifies the total number of bits required to store one second of video content. This is either a get-only or a get-and-set property.

FramesPerThousandSeconds (0xDE9D) This object property specifies the number of video frames per second multiplied by a thousand. For example, a value of 29.97 frames per second is expressed as 29970. This is a get-and-set property.

Encoding Profile (0xDEA1) This object property specifies the profile information necessary to decode the bit stream of the encoded media. This is a device-defined property.

Recommended Object Properties for Video Formats To achieve the best customer experience, we recommend that MTP DVCs that support video formats also support the following object properties, but they are not required in order to qualify for the logo.

REQUIREMENT REFERENCE: PORTABLE-0031

Artist (0xDC46) This object property identifies the artist or artists who created the intellectual property contained in the object. This is a get-and-set property.

SerialNumber (0xDC51) This object property specifies the serial number for the device that captured the image. This is a get-and-set property.

RepresentativeSampleSize (0xDC82) This object property specifies the size, in bytes, of the representative sample for the object. This is either a get-only or a get-and-set property.

RepresentativeSampleHeight (0xDC83) This property specifies the height in pixels of the representative sample for the object. This is either a get-only or a get-and-set property.

RepresentativeSampleWidth (0xDC84) This object property specifies the width in pixels of the representative sample for the object. This is either a get-only or a get-and-set property.

RepresentativeSampleDuration (0xDC85) This object property identifies the duration of the representative sample for the object in milliseconds. This is either a get-only or a get-and-set property.

RepresentativeSampleData (0xDC86) This object property is used to store the data for the representative sample for the object. This is either a get-only or a get-and-set property.

Duration (0xDC89) The duration property specifies the running time of the audio content in the object. The property value is the duration in milliseconds of the audio content. This is either a get-only or a get-and-set property.

TotalBitRate (0xDE91) This object property specifies the total number of bits required to store one second of audio, video, or combined audio and video content. For an audio file, this property has the same value as the AudioBitRate object property. For a video file, this property has the same value as the VideoBitRate object property. For a file that combines audio and video, the value of this property is equal to the sum of the AudioBitRate and VideoBitRate property values. This is either a get-only or a get-and-set property.

BitRateType (0xDE92) This object property indicates whether playing the audio, video, or combined-audio-and-video content in the object consumes a constant portion of the MTP device's total available bit rate, consumes a variable portion (which is the case for some compressed formats), or is "free" (consumes none of the device's available bit rate). This is a get-and-set property.

Mandatory Object Properties for Audio Formats To qualify to use the logo, a DVC that uses audio formats must support the following object properties.

Artist (0xDC46) This object property identifies the artist or artists who created the intellectual property contained in the object. This is a get-and-set property.

AudioWAVECodec (0xDE99) This object property specifies the WAVE codec tag for an object that contains audio content that is encoded in a registered WAVE format. The list of valid WAVE codec tags for this property is presented in the Registered FOURCC Codes and WAVE Formats article on MSDN. This property is useful for managing file container formats that support more than one audio data format. For example, an Advanced Systems Format (ASF) file might contain audio data that has been encoded in Windows Media Audio (WMA) or WMA Pro format. This is a get- and-set property.

Recommended Object Properties for Audio Formats To achieve the best customer experience, we recommend that DVCs that support audio formats also support the following object properties, but they are not required in order to qualify for the logo.

REQUIREMENT REFERENCE: PORTABLE-0066

Track (0xDC8B) This object property identifies the track that this object is found on in its distribution media.

AlbumName (0xDC9A) This object property identifies the name of the album that this object was distributed under.

AlbumArtist (0xDC9B) This object property identifies the name of the artist that this object was created by.

November 5, 2010 © 2010 Microsoft Corporation. All rights reserved. Designing Digital Video Cameras to Meet Windows Logo Program Requirements - 80 property is equal to the sum of the AudioBitRate and VideoBitRate property values. This is either a get-only or a get-and-set property.

Recommended Support for Interdependent Property Descriptions As mentioned previously, two or more properties are interdependent if changing the value of one property can change the constraints on the values that the other properties can assume.

For example, consider the case where a portable device supports decoding of audio files in both the WMA and WMA Lossless formats. The portable device can support multiple sampling frequencies for WMA playback. However, to avoid resampling, the device can play the WMA Lossless file only at the internal hardware clock frequency of 48 kHz.

If the portable device reports that it supports a single set of sampling frequencies for all formats, a host might inadvertently send it content that it cannot play (namely, WMA Lossless content recorded at a sampling rate other than 48 kHz).

To avoid this problem, the MTP protocol provides the ability for a portable device to indicate support for combinations of properties using the GetInterdependentPropDesc command, which was described previously.

Example: Interdependent property descriptions In the following example, the initiator sends a GetInterdependentPropDesc command (0x9807) to get the property independencies for objects with the ASF format (format code 0x300C). The portable device reports that it can support 22.05 kHz, 24 kHz, 32 kHz, 44.1 kHz, and 48 kHz sampling frequencies for WMA content, but only 48 kHz for WMA Lossless content. The response data specifies two interdependencies. Each interdependency is described by a pair of ObjectPropDesc data sets (for the SampleRate and AudioFormatCode properties, respectively). The first interdependency description contains the two property descriptions for the WMA format, and the second interdependency description contains the two property descriptions for the WMA Lossless format.

In this example, the GetInterdependentPropDesc command retrieves an InterdependentPropDesc data set that begins with the two fields shown in the following table.

Table 32. InterdependentPropDesc data set Field Bytes Value NumberOfInterdepen 2 0x0002 cies NumberOfPropDescs 2 0x0002 According to the fields in the preceding table, the InterdependentPropDesc data set describes two sets of interdependencies, and the first interdependency description consists of two object property data sets.

The two fields in the preceding table are followed immediately by the two ObjectPropDesc data sets shown in the following two tables, which describe the first configuration of the SampleRate and AudioFormatCode properties for the ASF format. The following table specifies the constraints on the SampleRate property for the WMA format.

Table 33. Sample rate constraints for interdependent properties Field Bytes Value ObjectPropCode 2 0xDE93 (SampleRate) DataType 2 0x0006 (UINT32) GetSet 1 0x00 (get-only) DefaultValue 4 0x00000000 GroupCode 4 0x00000000

FormFlag 1 0x02 (enumeration form) NumberOfValues 2 0x0005 SupportedValue1 4 0x00005622 (22.05 kHz) SupportedValue2 4 0x00005DC0 (24 kHz) SupportedValue3 4 0x00007D00 (32 kHz) SupportedValue4 4 0x0000AC44 (44.1 kHz) SupportedValue5 4 0x0000BB80 (48 kHz) The following table describes the AudioFormatCode property for the WMA format.

Table 34. Audio format code property Field Bytes Value ObjectPropCode 2 AudioFormatCode (0xDE99) DataType 2 0x0006 (UINT32) GetSet 1 0x00 (get-only) DefaultValue 4 0x00000000 GroupCode 4 0x00000000 FormFlag 1 0x02 (enumeration form) NumberOfValues 2 0x0001 SupportedValue1 4 0x00000161 (WMA version 2) The fields in the preceding tables are followed immediately by the field shown in the following table.

Table 35. Number of property descriptions supported Field Bytes Value NumberOfPropDescs 2 0x0002 According to the fields in the preceding table, the second interdependency description consists of two object property data sets.

The fields in the preceding tables are followed by the two ObjectPropDesc data sets shown in the following two tables, which describe the second configuration of the SampleRate and AudioFormatCode properties for the ASF format. The following table specifies the constraints on the SampleRate property for the WMA Lossless format.

Table 36. Object property description data set Field Bytes Value ObjectPropCode 2 0xDE93 (SampleRate) DataType 2 0x0006 (UINT32) GetSet 1 0x00 (get-only) DefaultValue 1 0x00000000 GroupCode 4 0x00000000 FormFlag 1 0x02 (enumeration form) NumberOfValues 2 0x0001 SupportedValue1 4 0x0000BB80 (48 kHz) The following table describes the AudioFormatCode property for the WMA Lossless format.

Table 37. Object property description data set Field Bytes Value ObjectPropCode 2 AudioFormatCode (0xDE99) DataType 2 0x0006 (UINT32) GetSet 1 0x00 (get-only) DefaultValue 4 0x00000000 GroupCode 4 0x00000000

FormFlag 1 0x02 (enumeration form) NumberOfValues 2 0x0001 SupportedValue1 4 0x0163 (WMA Lossless)