[MS-RDPNSC]:
Remote Desktop Protocol: NSCodec Extension
Intellectual Property Rights Notice for Open Specifications Documentation
§ Technical Documentation. Microsoft publishes Open Specifications documentation (“this documentation”) for protocols, file formats, data portability, computer languages, and standards support. Additionally, overview documents cover inter-protocol relationships and interactions.
§ Copyrights. This documentation is covered by Microsoft copyrights. Regardless of any other terms that are contained in the terms of use for the Microsoft website that hosts this documentation, you can make copies of it in order to develop implementations of the technologies that are described in this documentation and can distribute portions of it in your implementations that use these technologies or in your documentation as necessary to properly document the implementation. You can also distribute in your implementation, with or without modification, any schemas, IDLs, or code samples that are included in the documentation. This permission also applies to any documents that are referenced in the Open Specifications documentation.
§ No Trade Secrets. Microsoft does not claim any trade secret rights in this documentation.
§ Patents. Microsoft has patents that might cover your implementations of the technologies described in the Open Specifications documentation. Neither this notice nor Microsoft's delivery of this documentation grants any licenses under those patents or any other Microsoft patents. However, a given Open Specifications document might be covered by the Microsoft Open Specifications Promise or the Microsoft Community Promise. If you would prefer a written license, or if the technologies described in this documentation are not covered by the Open Specifications Promise or Community Promise, as applicable, patent licenses are available by contacting .
§ License Programs. To see all of the protocols in scope under a specific license program and the associated patents, visit the Patent Map.
§ Trademarks. The names of companies and products contained in this documentation might be covered by trademarks or similar intellectual property rights. This notice does not grant any licenses under those rights. For a list of Microsoft trademarks, visit www.microsoft.com/trademarks.
§ Fictitious Names. The example companies, organizations, products, domain names, email addresses, logos, people, places, and events that are depicted in this documentation are fictitious. No association with any real company, organization, product, domain name, email address, logo, person, place, or event is intended or should be inferred.
Reservation of Rights. All other rights are reserved, and this notice does not grant any rights other than as specifically described above, whether by implication, estoppel, or otherwise.
Tools. The Open Specifications documentation does not require the use of Microsoft programming tools or programming environments in order for you to develop an implementation. If you have access to Microsoft programming tools and environments, you are free to take advantage of them. Certain Open Specifications documents are intended for use in conjunction with publicly available standards specifications and network programming art and, as such, assume that the reader either is familiar with the aforementioned material or has immediate access to it.
Support. For questions and support, please contact .
Revision Summary
Date / Revision History / Revision Class / Comments /4/23/2010 / 0.1 / Major / First Release.
6/4/2010 / 0.1.1 / Editorial / Changed language and formatting in the technical content.
7/16/2010 / 1.0 / Major / Updated and revised the technical content.
8/27/2010 / 1.0 / None / No changes to the meaning, language, or formatting of the technical content.
10/8/2010 / 2.0 / Major / Updated and revised the technical content.
11/19/2010 / 2.0 / None / No changes to the meaning, language, or formatting of the technical content.
1/7/2011 / 3.0 / Major / Updated and revised the technical content.
2/11/2011 / 4.0 / Major / Updated and revised the technical content.
3/25/2011 / 5.0 / Major / Updated and revised the technical content.
5/6/2011 / 5.0 / None / No changes to the meaning, language, or formatting of the technical content.
6/17/2011 / 5.1 / Minor / Clarified the meaning of the technical content.
9/23/2011 / 5.1 / None / No changes to the meaning, language, or formatting of the technical content.
12/16/2011 / 6.0 / Major / Updated and revised the technical content.
3/30/2012 / 6.0 / None / No changes to the meaning, language, or formatting of the technical content.
7/12/2012 / 6.0 / None / No changes to the meaning, language, or formatting of the technical content.
10/25/2012 / 7.0 / Major / Updated and revised the technical content.
1/31/2013 / 7.0 / None / No changes to the meaning, language, or formatting of the technical content.
8/8/2013 / 8.0 / Major / Updated and revised the technical content.
11/14/2013 / 8.0 / None / No changes to the meaning, language, or formatting of the technical content.
2/13/2014 / 8.0 / None / No changes to the meaning, language, or formatting of the technical content.
5/15/2014 / 8.0 / None / No changes to the meaning, language, or formatting of the technical content.
6/30/2015 / 9.0 / Major / Significantly changed the technical content.
10/16/2015 / 9.0 / None / No changes to the meaning, language, or formatting of the technical content.
7/14/2016 / 9.0 / None / No changes to the meaning, language, or formatting of the technical content.
6/1/2017 / 9.0 / None / No changes to the meaning, language, or formatting of the technical content.
Table of Contents
1 Introduction 5
1.1 Glossary 5
1.2 References 5
1.2.1 Normative References 5
1.2.2 Informative References 6
1.3 Protocol Overview (Synopsis) 6
1.4 Relationship to Other Protocols 7
1.5 Prerequisites/Preconditions 7
1.6 Applicability Statement 7
1.7 Versioning and Capability Negotiation 8
1.8 Vendor-Extensible Fields 8
1.9 Standards Assignments 8
2 Messages 9
2.1 Transport 9
2.2 Message Syntax 9
2.2.1 NSCodec Capability Set (TS_NSCODEC_CAPABILITYSET) 9
2.2.2 NSCodec Compressed Bitmap Stream (NSCODEC_BITMAP_STREAM) 9
2.2.2.1 NSCodec RLE Segments (NSCODEC_RLE_SEGMENTS) 13
2.2.2.2 NSCodec RLE Segment 13
2.2.2.2.1 NSCodec RLE Run Segment (NSCODEC_RLE_RUN_SEGMENT) 13
2.2.2.2.2 NSCodec RLE Literal Segment (NSCODEC_RLE_LITERAL_SEGMENT) 14
3 Protocol Details 15
3.1 Common Details 15
3.1.1 Abstract Data Model 16
3.1.1.1 Lossy Bitmap Compression Ability 16
3.1.1.2 Chroma Subsampling Ability 16
3.1.1.3 Maximum Supported Color Loss Level 16
3.1.2 Timers 16
3.1.3 Initialization 16
3.1.4 Higher-Layer Triggered Events 16
3.1.5 Processing Events and Sequencing Rules 17
3.1.5.1 NSCodec Capability Set 17
3.1.5.2 NSCodec Compressed Bitmap Stream 17
3.1.6 Timer Events 17
3.1.7 Other Local Events 17
3.1.8 NSCodec Bitmap Compression 17
3.1.8.1 NSCodec Run-Length Encoding 18
3.1.8.1.1 Encoding Run-Length Sequences 18
3.1.8.2 Padding the Red, Green, and Blue Color Planes 20
3.1.8.3 Compressing a Bitmap 21
3.1.8.4 Decompressing a Bitmap 22
4 Protocol Examples 25
5 Security 27
5.1 Security Considerations for Implementers 27
5.2 Index of Security Parameters 27
6 Appendix A: Product Behavior 28
7 Change Tracking 29
8 Index 30
1 Introduction
The Remote Desktop Protocol: NSCodec Extension is an extension to the Remote Desktop Protocol: Basic Connectivity and Graphics Remoting (as specified in [MS-RDPBCGR]). The aim of this extension is to specify an image codec that can be used to encode screen images by utilizing efficient and effective compression.
Sections 1.5, 1.8, 1.9, 2, and 3 of this specification are normative. All other sections and examples in this specification are informative.
1.1 Glossary
This document uses the following terms:
ANSI character: An 8-bit Windows-1252 character set unit.
ARGB: A color space wherein each color is represented as a quad (A, R, G, B), where A represents the alpha (transparency) component, R represents the red component, G represents the green component, and B represents the blue component. The ARGB value is typically stored as a 32-bit integer, wherein the alpha channel is stored in the highest 8 bits and the blue value is stored in the lowest 8 bits.
AYCoCg: A color space in which each color is represented as a quad (A, Y, Co, Cg), where A represents the alpha (transparency) component, Y represents the luma (intensity) component, and Co and Cg represent the two chrominance (color) components orange and green, respectively.
color plane: A two-dimensional surface containing a collection of values that represent a single component of the ARGB or AYCoCg color space.
color space: A mapping of color components to a multidimensional coordinate system. The number of dimensions is generally two, three, or four. For example, if colors are expressed as a combination of the three components red, green, and blue, a three-dimensional space is sufficient to describe all possible colors. If transparency is considered one of the components of an RGB color, four dimensions are appropriate.
little-endian: Multiple-byte values that are byte-ordered with the least significant byte stored in the memory location with the lowest address.
run-length encoding (RLE): A form of data compression in which repeated values are represented by a count and a single instance of the value.
MAY, SHOULD, MUST, SHOULD NOT, MUST NOT: These terms (in all caps) are used as defined in [RFC2119]. All statements of optional behavior use either MAY, SHOULD, or SHOULD NOT.
1.2 References
Links to a document in the Microsoft Open Specifications library point to the correct section in the most recently published version of the referenced document. However, because individual documents in the library are not updated at the same time, the section numbers in the documents may not match. You can confirm the correct section numbering by checking the Errata.
1.2.1 Normative References
We conduct frequent surveys of the normative references to assure their continued availability. If you have any issue with finding a normative reference, please contact . We will assist you in finding the relevant information.
[MS-RDPBCGR] Microsoft Corporation, "Remote Desktop Protocol: Basic Connectivity and Graphics Remoting".
[MS-RDPEGDI] Microsoft Corporation, "Remote Desktop Protocol: Graphics Device Interface (GDI) Acceleration Extensions".
[MS-RDPNSC] Microsoft Corporation, "Remote Desktop Protocol: NSCodec Extension".
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, http://www.rfc-editor.org/rfc/rfc2119.txt
1.2.2 Informative References
None.
1.3 Protocol Overview (Synopsis)
The Remote Desktop Protocol: NSCodec Codec Extension reduces the bandwidth associated with desktop remoting by efficiently compressing 24 bits per pixel (bpp) and 32 bpp images. This is achieved by using the NSCodec bitmap codec. This bitmap codec is based on the bitmap compression techniques introduced in [MS-RDPEGDI] section 3.1.9.
The [MS-RDPBCGR] PDUs that encapsulate [MS-RDPNSC] structures are summarized in the following figure.
Figure 1: Encapsulation and sequencing of NSCodec settings and bitmaps
[MS-RDPNSC] settings are encapsulated in an NSCodec Capability Set (section 2.2.1), which is ultimately transported in a server-to-client Demand Active PDU ([MS-RDPBCGR] section 2.2.1.13.1) or client-to-server Confirm Active PDU ([MS-RDPBCGR] section 2.2.1.13.2). The Demand Active PDU and Confirm Active PDU are transmitted during the Capabilities Exchange Phase of the RDP Connection Sequence ([MS-RDPBCGR] section 1.3.1.1).
When the RDP Connection Sequence has run to completion, bitmap images of the user's session are transmitted from the server to the client ([MS-RDPBCGR] section 1.3.6). NSCodec compression techniques (section 3.1.8) and structures (section 2.2.2) are used to efficiently transport these bitmaps so that they can be rendered on the client. NSCodec-compressed bitmaps that cannot be cached are sent encapsulated in Set Surface Bits Surface Commands ([MS-RDPBCGR] section 2.2.9.2.1), which are ultimately transported in a server-to-client Fast-Path Surface Commands Update ([MS-RDPBCGR] section 2.2.9.1.2.1.10). NSCodec-compressed bitmaps that can be cached are sent encapsulated in Cache Bitmap – Revision 3 ([MS-RDPEGDI] section 2.2.2.2.1.2.8) Secondary Drawing Orders, which are ultimately transported in a server-to-client Fast-Path Orders Update ([MS-RDPEGDI] section 2.2.2.2). Bitmap caching is discussed in [MS-RDPEGDI] section 3.1.1.1.1.
1.4 Relationship to Other Protocols
This protocol extends the Remote Desktop Protocol: Basic Connectivity and Graphics Remoting (as specified in [MS-RDPBCGR]) by adding advanced compression techniques.
1.5 Prerequisites/Preconditions
All multiple-byte fields within a message are assumed to contain data in little-endian byte order unless otherwise specified.
The following client prerequisites are mandatory:
§ The client MUST advertise support for the NSCodec codec by sending the NSCodec Capability Set (section 2.2.1) to the server as specified in section 3.1.5.1.
§ The client MUST support a color depth of 32 bits per pixel. This means that the RNS_UD_32BPP_SUPPORT (0x0008) flag must be set in the supportedColorDepths field of the Client Core Data structure ([MS-RDPBCGR] section 2.2.1.3.2).
In order to receive NSCodec-compressed bitmaps within the Stream Surface Bits Surface Command ([MS-RDPBCGR] section 2.2.9.2.2), the following client prerequisites are mandatory:
§ The client MUST support fast-path graphics output ([MS-RDPBCGR] section 2.2.9.1.2) and acknowledge this support by specifying the FASTPATH_OUTPUT_SUPPORTED (0x0001) flag in the General Capability Set ([MS-RDPBCGR] section 2.2.7.1.1).
§ The client MUST support the Stream Surface Bits Surface Command ([MS-RDPBCGR] section 2.2.9.2.2). Support for this surface command MUST be advertised in the Surface Commands Capability Set ([MS-RDPBCGR] section 2.2.7.2.9).
In order to use NSCodec-compressed bitmaps in conjunction with Bitmap Cache Secondary Drawing Orders ([MS-RDPEGDI] sections 1.3.1.1 and 1.3.1.2.2), the following client prerequisite is mandatory:
§ The client MUST support the Cache Bitmap - Revision 3 ([MS-RDPEGDI] section 2.2.2.2.1.2.8) Secondary Drawing Order. Support for this caching order MUST be advertised in the Surface Commands Capability Set ([MS-RDPBCGR] section 2.2.7.2.9).
1.6 Applicability Statement
This protocol is applicable in situations in which it is necessary to optimize the bandwidth required for graphics remoting. The advanced compression techniques specified in this document enable the efficient transfer of server-side images and video.
1.7 Versioning and Capability Negotiation
This protocol builds on the basic Remote Desktop Protocol. The features provided by this extension are negotiated during the Capabilities Exchange Phase of the RDP connection sequence ([MS-RDPBCGR] section 1.3.1.1). In effect, this extension merely expands the set of capabilities used by the base RDP. (RDP versioning and capability negotiation is described in [MS-RDPBCGR] section 1.7.)
1.8 Vendor-Extensible Fields
None.