Network Working Group A. Leung
Request for Comments: 5372 S. Futemma
Category: Standards Track E. Itakura
Sony
October 2008
Network Working Group A. Leung
Request for Comments: 5372 S. Futemma
Category: Standards Track E. Itakura
Sony
October 2008
Payload Format for JPEG 2000 Video: Extensions for Scalability and Main Header Recovery
JPEG 2000视频的有效负载格式：可扩展性和主标头恢复扩展
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Abstract
摘要
This memo describes extended uses for the payload header in "RTP Payload Format for JPEG 2000 Video Streams" as specified in RFC 5371, for better support of JPEG 2000 features such as scalability and main header recovery.
本备忘录描述了RFC 5371中规定的“JPEG 2000视频流RTP有效负载格式”中有效负载标头的扩展用途，以便更好地支持JPEG 2000功能，如可扩展性和主标头恢复。
This memo must be accompanied with a complete implementation of "RTP Payload Format for JPEG 2000 Video Streams". That document is a complete description of the payload header and signaling, this document only describes additional processing for the payload header. There is an additional media type and Session Description Protocol (SDP) marker signaling for implementations of this document.
本备忘录必须附有“JPEG 2000视频流RTP有效负载格式”的完整实现。该文档是有效负载报头和信令的完整描述，本文档仅描述有效负载报头的附加处理。对于本文档的实现，还有一个附加的媒体类型和会话描述协议（SDP）标记信令。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Description of the Mechanisms . . . . . . . . . . . . . . 3
1.1.1. Main Header Compensation . . . . . . . . . . . . . . . 3
1.1.2. Priority Table . . . . . . . . . . . . . . . . . . . . 3
1.2. Motivations for Priority Field Coding . . . . . . . . . . 4
1.2.1. Scenario: Just Enough Resolution . . . . . . . . . . . 4
1.2.2. Scenario: Multiple Clients, Single Source . . . . . . 4
1.3. Conventions Used in This Document . . . . . . . . . . . . 4
2. Payload Format Enhanced Processing . . . . . . . . . . . . . . 5
2.1. Enhanced Processing Markers . . . . . . . . . . . . . . . 5
3. Priority Mapping Table . . . . . . . . . . . . . . . . . . . . 6
3.1. Packet-Number-Based Ordering . . . . . . . . . . . . . . . 7
3.2. Progression-Based Ordering . . . . . . . . . . . . . . . . 7
3.3. Layer-Based Ordering . . . . . . . . . . . . . . . . . . . 9
3.4. Resolution-Based Ordering . . . . . . . . . . . . . . . . 9
3.5. Component-Based Ordering . . . . . . . . . . . . . . . . . 10
4. JPEG 2000 Main Header Compensation Scheme . . . . . . . . . . 10
4.1. Sender Processing . . . . . . . . . . . . . . . . . . . . 11
4.2. Receiver Processing . . . . . . . . . . . . . . . . . . . 11
5. Media Type Registration . . . . . . . . . . . . . . . . . . . 11
6. SDP Parameters . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Mapping of the Optional Parameters to SDP . . . . . . . . 12
6.2. Usage with the SDP Offer/Answer Model . . . . . . . . . . 13
6.2.1. Examples . . . . . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 16
10. Normative References . . . . . . . . . . . . . . . . . . . . . 16
Appendix A. Sample Headers in Detail . . . . . . . . . . . . . . 17
A.1. Sample 1: Progressive Image with Single Tile, 3500
Bytes (i.e., thumbnail) . . . . . . . . . . . . . . . . . 17
A.2. Sample 2: Image with 4 Tiles . . . . . . . . . . . . . . . 19
A.3. Sample 3: Packing Multiple Tiles in Single Payload,
Fragmented Header. No Header Compensation,
Progressive Image . . . . . . . . . . . . . . . . . . . . 20
A.4. Sample 4: Interlace Image, Single Tile . . . . . . . . . . 22
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Description of the Mechanisms . . . . . . . . . . . . . . 3
1.1.1. Main Header Compensation . . . . . . . . . . . . . . . 3
1.1.2. Priority Table . . . . . . . . . . . . . . . . . . . . 3
1.2. Motivations for Priority Field Coding . . . . . . . . . . 4
1.2.1. Scenario: Just Enough Resolution . . . . . . . . . . . 4
1.2.2. Scenario: Multiple Clients, Single Source . . . . . . 4
1.3. Conventions Used in This Document . . . . . . . . . . . . 4
2. Payload Format Enhanced Processing . . . . . . . . . . . . . . 5
2.1. Enhanced Processing Markers . . . . . . . . . . . . . . . 5
3. Priority Mapping Table . . . . . . . . . . . . . . . . . . . . 6
3.1. Packet-Number-Based Ordering . . . . . . . . . . . . . . . 7
3.2. Progression-Based Ordering . . . . . . . . . . . . . . . . 7
3.3. Layer-Based Ordering . . . . . . . . . . . . . . . . . . . 9
3.4. Resolution-Based Ordering . . . . . . . . . . . . . . . . 9
3.5. Component-Based Ordering . . . . . . . . . . . . . . . . . 10
4. JPEG 2000 Main Header Compensation Scheme . . . . . . . . . . 10
4.1. Sender Processing . . . . . . . . . . . . . . . . . . . . 11
4.2. Receiver Processing . . . . . . . . . . . . . . . . . . . 11
5. Media Type Registration . . . . . . . . . . . . . . . . . . . 11
6. SDP Parameters . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Mapping of the Optional Parameters to SDP . . . . . . . . 12
6.2. Usage with the SDP Offer/Answer Model . . . . . . . . . . 13
6.2.1. Examples . . . . . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 16
10. Normative References . . . . . . . . . . . . . . . . . . . . . 16
Appendix A. Sample Headers in Detail . . . . . . . . . . . . . . 17
A.1. Sample 1: Progressive Image with Single Tile, 3500
Bytes (i.e., thumbnail) . . . . . . . . . . . . . . . . . 17
A.2. Sample 2: Image with 4 Tiles . . . . . . . . . . . . . . . 19
A.3. Sample 3: Packing Multiple Tiles in Single Payload,
Fragmented Header. No Header Compensation,
Progressive Image . . . . . . . . . . . . . . . . . . . . 20
A.4. Sample 4: Interlace Image, Single Tile . . . . . . . . . . 22
This document is an extension of "RTP Payload Format for JPEG 2000 Video Streams" [RFC5371]. These are additional mechanisms that can be used with certain parts of the header in [RFC5371] to support JPEG 2000 features such as scalability and a main header compensation method. These mechanisms are described in detail in this document.
本文档是“JPEG 2000视频流的RTP有效负载格式”[RFC5371]的扩展。这些是额外的机制，可用于[RFC5371]中标题的某些部分，以支持JPEG 2000功能，如可伸缩性和主标题补偿方法。本文件详细描述了这些机制。
These are optional extensions to RFC 5371 [RFC5371], which one may use to make better use of JPEG 2000 features. These extensions are not required for any implementations of RFC 5371 [RFC5371].
这些是RFC 5371[RFC5371]的可选扩展，可以使用这些扩展更好地利用JPEG 2000特性。RFC 5371[RFC5371]的任何实现都不需要这些扩展。
JPEG 2000 image header contains essential decoding information for the decoder. If a JPEG 2000 decoder receives JPEG 2000 image data without a JPEG 2000 image header, it could not decode the JPEG 2000 image data properly. Encoders for JPEG 2000 video very rarely change encoding parameters between successive frames. So, the possibility of the decoder successively decoding the new JPEG 2000 image data using a prior JPEG 2000 image header is very high in this situation.
JPEG 2000图像头包含解码器的基本解码信息。如果JPEG 2000解码器接收到的JPEG 2000图像数据没有JPEG 2000图像头，则无法正确解码JPEG 2000图像数据。JPEG 2000视频编码器很少在连续帧之间更改编码参数。因此，在这种情况下，解码器使用先前的JPEG 2000图像头连续解码新的JPEG 2000图像数据的可能性非常高。
The main header compensation scheme used in this document exploits the fact that successive JPEG 2000 video images rarely change encoding parameters. It requires receivers to save past JPEG 2000 image headers to use in case of missing JPEG 2000 image headers in the future. Signaling of changes to the JPEG 2000 image header is done through the payload header. When the mh_id value of the payload header changes, receivers should save the new JPEG 2000 header to use for main header recovery.
本文档中使用的主要报头补偿方案利用了连续JPEG 2000视频图像很少改变编码参数的事实。它要求接收者保存过去的JPEG 2000图像头，以便在将来丢失JPEG 2000图像头时使用。JPEG 2000图像报头的更改信号通过有效载荷报头完成。当有效载荷标头的mh_id值更改时，接收器应保存新的JPEG 2000标头以用于主标头恢复。
JPEG 2000 codestream has rich functionality built into it so decoders can easily handle scalable delivery or progressive transmission. Progressive transmission allows images to be reconstructed with increasing pixel accuracy or spatial resolution. This feature allows the reconstruction of images with different resolutions and pixel accuracy, for different target devices. A single image source can provide a codestream that is easily processed for smaller image display devices.
JPEG 2000码流内置了丰富的功能，因此解码器可以轻松处理可扩展的传输或渐进传输。渐进式传输允许以更高的像素精度或空间分辨率重建图像。此功能允许为不同的目标设备重建具有不同分辨率和像素精度的图像。单个图像源可以提供易于为较小的图像显示设备处理的码流。
JPEG 2000 packets contain all compressed image data from a specific layer, component, resolution level, and/or precinct. The order in which these JPEG 2000 packets are found in the codestream is called the progression order. The ordering of the JPEG 2000 packets can
JPEG 2000数据包包含来自特定层、组件、分辨率级别和/或辖区的所有压缩图像数据。在码流中找到这些JPEG 2000数据包的顺序称为前进顺序。可以对JPEG 2000数据包进行排序
progress along four axes: layer, component, resolution, and precinct (or position).
沿四个轴进行：图层、组件、分辨率和区域（或位置）。
Providing a priority field to indicate the importance of data contained in a given RTP packet can aid in usage of JPEG 2000 progressive and scalable functions.
提供优先级字段以指示给定RTP数据包中包含的数据的重要性有助于使用JPEG 2000渐进式和可伸缩功能。
The JPEG 2000 coding scheme allows one to reorder the codestream in many ways. Even when the coding scheme is determined and arranged by the encoder, a decoder can still re-arrange the code stream on the fly to suit decode parameters such as re-arranging from resolution progressive to quality progressive.
JPEG2000编码方案允许以多种方式对码流重新排序。即使当编码方案由编码器确定和安排时，解码器仍然可以动态地重新安排码流以适应解码参数，例如从分辨率渐进式重新安排到质量渐进式重新安排。
Using the priority field coding, the decoder gains insight into the codestream without access to the full codestream and exposes features of JPEG 2000 to a higher level.
使用优先级字段编码，解码器在不访问完整码流的情况下获得对码流的洞察，并将JPEG 2000的特性公开到更高的级别。
The authors found the scenarios below to utilize this field. The priority field allows more information about the image to be sent without more signaling between sender and receivers to leverage JPEG 2000 capabilities.
作者发现下面的场景可以利用这个字段。优先级字段允许发送有关图像的更多信息，而无需在发送方和接收方之间发送更多信号以利用JPEG 2000功能。
The scenario is when rapid scene access is more important than higher image quality. By using the priority field, the receiver can decode for its own quality level. If the sender cannot determine the receiver's resolution, the receiver can select which parts of the codestream to be decoded or loaded by using the priority field.
在这种情况下，快速场景访问比更高的图像质量更重要。通过使用优先级字段，接收器可以根据自己的质量级别进行解码。如果发送方不能确定接收方的分辨率，接收方可以使用优先级字段选择要解码或加载的码流部分。
In a multicast environment, there are clients with better visual capability than others (i.e., TV conference versus Mobile). The respective clients can use the priority field to determine which packets are vital for their own visual presentation. The sender only has to do work on the priority field to optimally serve all the clients while only managing a single visual stream.
在多播环境中，有一些客户端比其他客户端具有更好的可视能力（例如，电视会议和移动）。各个客户端可以使用优先级字段来确定哪些数据包对于它们自己的视觉呈现至关重要。发送方只需在优先级字段上进行操作，就可以在管理单个可视流的同时为所有客户端提供最佳服务。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119中的说明进行解释。[RFC2119]。
This section of the document describes additional usage in the values of mh_id and priority fields and interpretation that differ from RFC 5371 [RFC5371]. Implementations of this document should follow RFC 5371 [RFC5371] first then add additional header processing as described in this document. Implementations following this document are expected to interoperate with implementations of [RFC5371] and this document as well.
本节描述了mh_id值和优先级字段的附加用法，以及与RFC 5371[RFC5371]不同的解释。本文档的实现应首先遵循RFC 5371[RFC5371]，然后按照本文档所述添加额外的头处理。本文档之后的实现预计将与[RFC5371]和本文档的实现进行互操作。
The RTP payload header format for JPEG 2000 video stream is as follows:
JPEG 2000视频流的RTP有效负载头格式如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|tp |MHF|mh_id|T| priority | tile number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|reserved | fragment offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|tp |MHF|mh_id|T| priority | tile number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|reserved | fragment offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: RTP Payload Header Format for JPEG 2000
图1:JPEG 2000的RTP有效载荷头格式
mh_id (Main Header Identification): 3 bits
mh_id（主标头标识）：3位
Main header identification value. This is used for JPEG 2000 main header recovery.
主标题标识值。这用于JPEG 2000主标题恢复。
The initial value of mh_id MUST be 1 at the beginning of the session.
在会话开始时，mh_id的初始值必须为1。
The same mh_id value is used as long as the coding parameters described in the main header remains unchanged between frames.
只要主报头中描述的编码参数在帧之间保持不变，就使用相同的mh_id值。
The mh_id value MUST be incremented by 1 every time a new main header is transmitted. Once the mh_id value becomes greater than 7, it SHOULD roll over to 1.
每次传输新的主报头时，mh_id值必须增加1。一旦mh_id值大于7，则应滚动至1。
When mh_id is 0, it has special usage for the receiver. This special usage is described in Section 4.2 of this document.
当mh_id为0时，它对接收器有特殊用途。本文件第4.2节描述了这种特殊用途。
Senders should follow Section 4.1 of this document for proper mh_id assignment and usage.
发送方应遵守本文件第4.1节，以正确分配和使用mh_id。
priority: 8 bits
优先级：8位
The priority field indicates the importance of the JPEG 2000 packet included in the payload. Typically, a higher priority value is set in the packets containing JPEG 2000 packets containing the lower sub-bands.
优先级字段指示有效载荷中包括的JPEG 2000分组的重要性。通常，在包含较低子带的JPEG 2000包的包中设置较高的优先级值。
Special values of priority:
优先权的特殊价值：
0: This is reserved for payloads that contain a header (main or tile part header). This is considered the most important.
0：这是为包含标题（主标题或平铺部分标题）的有效负载保留的。这被认为是最重要的。
1 to 255: These values decrease in importance as the values increase (i.e., 1 is more important than 2, etc.). Applying priority values should correlate directly to the JPEG 2000 codestream in importance.
1到255：这些值的重要性随着值的增加而降低（即，1比2更重要，等等）。应用优先级值应与JPEG 2000码流的重要性直接相关。
The lower the priority value, the higher the importance. A priority value of 0 is the highest importance and 255 is the lowest importance. We define the priority value 0 as a special priority value for the headers (the main header or tile-part header). If any headers (the main header or tile-part header) are packed into the RTP payload, the sender MUST set the priority value to 0.
优先级值越低，重要性越高。优先级值0为最高重要性，255为最低重要性。我们将优先级值0定义为标题（主标题或平铺部分标题）的特殊优先级值。如果任何标头（主标头或平铺部分标头）打包到RTP有效负载中，发送方必须将优先级值设置为0。
Assignment of the values is described in Section 3.
第3节描述了值的分配。
For the progression order, the priority value for each JPEG 2000 packet is given by the priority mapping table.
对于级数顺序，每个JPEG 2000数据包的优先级值由优先级映射表给出。
This document specify several commonly used priority mapping tables, pre-defined priority mapping tables: packet-number-based (default), progression-based, layer-based, resolution-based, and component-based.
本文档指定了几种常用的优先级映射表、预定义的优先级映射表：基于数据包编号（默认）、基于进程、基于层、基于分辨率和基于组件。
Packet number priority mapping is REQUIRED to be supported by clients implementing this specification. Other priority mapping tables (progression, layer, resolution, and component-based) are OPTIONAL to implementations of this specification.
实现此规范的客户端需要支持包号优先级映射。其他优先级映射表（进程、层、分辨率和基于组件的）对于本规范的实现是可选的。
Rules that all implementations of this specification MUST follow in all priority modes:
本规范的所有实现在所有优先级模式下必须遵循的规则：
o When there is a header in the packet with a JPEG 2000 packet, the sender MUST set the payload packet priority value to 0.
o 当包含JPEG 2000数据包的数据包中存在报头时，发送方必须将有效负载数据包优先级值设置为0。
o When there are multiple JPEG 2000 packets in the same RTP payload packet, the sender MUST set the payload packet priority value to the lowest JPEG 2000 packet (i.e., if JPEG 2000 packets with priority: 5,6,7 are packed into a single payload, the priority value will be 5).
o 当同一RTP有效载荷数据包中存在多个JPEG 2000数据包时，发送方必须将有效载荷数据包优先级值设置为最低的JPEG 2000数据包（即，如果优先级为5,6,7的JPEG 2000数据包打包到单个有效载荷中，优先级值将为5）。
Packet-number-based ordering assigns the payload packet priority value from the "JPEG 2000 packet value" (note: JPEG 2000 codestreams are stored in units of packets and each packet has a value). This method is the default method for assigning priority value. All implementations of this specification MUST support this method.
基于数据包编号的排序从“JPEG 2000数据包值”分配有效负载数据包优先级值（注意：JPEG 2000码流以数据包为单位存储，每个数据包都有一个值）。此方法是指定优先级值的默认方法。本规范的所有实现都必须支持此方法。
If the JPEG 2000 codestream packet value is greater than 255, the sender MUST set the payload priority value to 255.
如果JPEG 2000码流数据包值大于255，则发送方必须将有效负载优先级值设置为255。
The sender will assign the payload packet priority value only based on layer, resolution, and component ordering of the codestream.
发送方将仅基于码流的层、分辨率和组件顺序来分配有效负载包优先级值。
Progression-based ordering can assign the different priority values in the same layer or the resolution level, which it cannot do in the layer-based ordering or resolution-based ordering.
基于进程的排序可以在同一层或分辨率级别中分配不同的优先级值，而在基于层的排序或基于分辨率的排序中则不能这样做。
Unlike the packet-number-based ordering, the progression-based ordering does not assign a value in the position level, which saves the priority values. The priority value in the position level is not so important because a receiver could recognize the position by checking the tile number field. Therefore, the progression-based ordering would be useful.
与基于数据包编号的排序不同，基于进程的排序不会在位置级别分配值，从而保存优先级值。位置级别中的优先级值并不重要，因为接收者可以通过检查tile number字段来识别位置。因此，基于级数的排序将非常有用。
The general algorithm is that the ordering is based on the triple <layer, resolution, component> and the minimum priority is 1. So, if the codestream is constructed of L layers (layer value ranges from 0 to L-1), R resolutions (resolution value ranges from 0 to R-1), and C components (component value ranges from 0 to C-1), then for a triple <lval, rval, cval>:
一般算法是基于三层<layer，resolution，component>排序，最小优先级为1。因此，如果码流由L层（层值范围从0到L-1）、R分辨率（分辨率值范围从0到R-1）和C分量（分量值范围从0到C-1）构成，那么对于三重<lval，rval，cval>：
the priority value of the codestream in LRCP order is calculated as:
LRCP顺序的码流优先级值计算如下：
priority = 1 + cval + (C * rval) + (C * R * lval)
priority = 1 + cval + (C * rval) + (C * R * lval)
the priority value of the codestream in RLCP order is calculated as:
RLCP顺序的码流优先级值计算如下：
priority = 1 + cval + (C * lval) + (C * L * rval)
priority = 1 + cval + (C * lval) + (C * L * rval)
the priority value of the codestream in RPCL order is calculated as:
RPCL顺序的码流优先级值计算如下：
priority = 1 + lval + (L * cval) + (L * C * rval)
priority = 1 + lval + (L * cval) + (L * C * rval)
the priority value of which codestream in PCRL order is calculated as:
其PCRL顺序的码流的优先级值计算为：
priority = 1 + lval + (L * rval) + (L * R * cval)
priority = 1 + lval + (L * rval) + (L * R * cval)
the priority value of which codestream in CPRL order is calculated as:
CPRL顺序的码流的优先级值计算为：
priority = 1 + lval + (L * rval) + (L * R * cval)
priority = 1 + lval + (L * rval) + (L * R * cval)
For example:
例如：
If the codestream is ordered in LRCP (Layer, Resolution, Component, Position) with 1 layer (L=1), 2 resolutions (R=2), 3 components (C=3), and 2 positions, the priority value should be (1 + cval + 3*rval + 6*lval). Then an example would have packet numbering as so:
如果码流按LRCP（层、分辨率、分量、位置）排序，具有1层（L=1）、2个分辨率（R=2）、3个分量（C=3）和2个位置，则优先级值应为（1+cval+3*rval+6*lval）。然后，示例中的数据包编号如下所示：
All the packets in:
中的所有数据包：
layer.........0
resolution....0
component.....0
position......0 or 1
layer.........0
resolution....0
component.....0
position......0 or 1
then the packet priority value : 1
然后，数据包优先级值为：1
All the packets in:
中的所有数据包：
layer.........0
resolution....0
component.....1
position......0 or 1
layer.........0
resolution....0
component.....1
position......0 or 1
then the packet priority value : 2
然后，数据包优先级值为：2
All the packets in:
中的所有数据包：
layer.........0
resolution....0
component.....2
position......0 or 1
layer.........0
resolution....0
component.....2
position......0 or 1
then the packet priority value : 3
然后包优先级值：3
All the packets in:
中的所有数据包：
layer.........0
resolution....1
component.....0
position......0 or 1
layer.........0
resolution....1
component.....0
position......0 or 1
then the packet priority value : 4
然后，数据包优先级值为：4
All the packets in:
中的所有数据包：
layer.........0
resolution....1
component.....1
position......0 or 1
layer.........0
resolution....1
component.....1
position......0 or 1
then the packet priority value : 5
然后，数据包优先级值为：5
The layer-based priority mapping table simplifies the default mapping to just matching JPEG 2000 packets together from the same layer.
基于层的优先级映射表将默认映射简化为仅匹配来自同一层的JPEG 2000数据包。
For example:
例如：
All the packets in layer 0 : packet priority value : 1
All the packets in layer 1 : packet priority value : 2
All the packets in layer 2 : packet priority value : 3
...
All the packets in layer n : packet priority value : n+1
All the packets in layer 255 : packet priority value : 255
All the packets in layer 0 : packet priority value : 1
All the packets in layer 1 : packet priority value : 2
All the packets in layer 2 : packet priority value : 3
...
All the packets in layer n : packet priority value : n+1
All the packets in layer 255 : packet priority value : 255
Resolution-based priority mapping table is similar to the layer-based order but for JPEG 2000 packets of the same resolution.
基于分辨率的优先级映射表类似于基于层的顺序，但适用于相同分辨率的JPEG 2000数据包。
For example:
例如：
All the packets in resolution 0 : packet priority value : 1
All the packets in resolution 1 : packet priority value : 2
All the packets in resolution 2 : packet priority value : 3
...
All the packets in resolution n : packet priority value : n+1
All the packets in resolution 255 : packet priority value : 255
All the packets in resolution 0 : packet priority value : 1
All the packets in resolution 1 : packet priority value : 2
All the packets in resolution 2 : packet priority value : 3
...
All the packets in resolution n : packet priority value : n+1
All the packets in resolution 255 : packet priority value : 255
Component-based priority mapping table is mapping together JPEG 2000 components of the same component.
基于组件的优先级映射表将同一组件的JPEG 2000组件映射在一起。
For example:
例如：
All the packets in component 0 : packet priority value : 1
All the packets in component 1 : packet priority value : 2
All the packets in component 2 : packet priority value : 3
...
All the packets in component n : packet priority value : n+1
All the packets in component 255 : packet priority value : 255
All the packets in component 0 : packet priority value : 1
All the packets in component 1 : packet priority value : 2
All the packets in component 2 : packet priority value : 3
...
All the packets in component n : packet priority value : n+1
All the packets in component 255 : packet priority value : 255
The mh_id field of the payload header is used to indicate whether the encoding parameters of the main header are the same as the encoding parameters of the previous frame. The same value is set in mh_id of the RTP packet in the same frame. The mh_id and encode parameters are not associated with each other as 1:1, but they are used to indicate whether or not the encode parameters of the previous frame are the same in the event of a lost header.
有效载荷报头的mh_id字段用于指示主报头的编码参数是否与前一帧的编码参数相同。在同一帧中的RTP数据包的mh_id中设置相同的值。mh_id和encode参数不以1:1的比例相互关联，但它们用于指示在丢失报头的情况下前一帧的编码参数是否相同。
The mh_id field value SHOULD be saved from previous frames to be used to recover the current frame's main header. If the mh_id of the current frame has the same value as the mh_id value of the previous frame, the previous frame's main header MAY be used to decode the current frame, in case of a lost header in the current frame.
mh_id字段值应从以前的帧中保存，以用于恢复当前帧的主标头。如果当前帧的mh_id具有与前一帧的mh_id值相同的值，则在当前帧中的报头丢失的情况下，前一帧的主报头可用于解码当前帧。
The sender MUST increment mh_id when parameters in the header change and send a new main header accordingly.
当报头中的参数更改时，发送方必须增加mh_id，并相应地发送一个新的主报头。
The receiver MAY use the mh_id and MAY retain the header for such compensation.
接收机可以使用mh_id，并且可以保留用于这种补偿的报头。
The sender MUST transmit RTP packets with the same mh_id value if the encoder parameters of the current frame are the same as the previous frame. The encoding parameters are the fixed information marker segment (SIZ marker) and functional marker segments (COD, COC, RGN, QCD, QCC, and POC) specified in JPEG 2000 Part 1, Annex A [JPEG2000Pt_1].
如果当前帧的编码器参数与前一帧相同，则发送方必须发送具有相同mh_id值的RTP数据包。编码参数为JPEG 2000第1部分附录A[JPEG2000Pt_1]中规定的固定信息标记段（SIZ标记）和功能标记段（COD、COC、RGN、QCD、QCC和POC）。
If the encode parameters changes, the sender transmitting RTP packets MUST increment the mh_id value by one, but when the mh_id value becomes greater than 7, a sender MUST set the mh_id value back to 1.
如果编码参数改变，发送RTP数据包的发送方必须将mh_id值增加1，但当mh_id值大于7时，发送方必须将mh_id值设置回1。
When the receiver receives the main header completely, the RTP sequence number, the mh_id, and the main header should be saved. Only the last main header that was received completely SHOULD be saved. When the mh_id value is 0, the receiver SHOULD NOT save the header.
当接收器完全接收到主报头时，应保存RTP序列号、mh_id和主报头。仅应保存完全接收的最后一个主标题。当mh_id值为0时，接收方不应保存报头。
When the main header is not received, the receiver may compare the current payload header's mh_id value with the previous saved mh_id value. If the values match, decoding may be performed by using the previously saved main header.
当未接收到主报头时，接收机可将当前有效负载报头的mh_id值与先前保存的mh_id值进行比较。如果值匹配，则可以使用先前保存的主报头执行解码。
If the mh_id field is set to 0, the receiver MUST NOT save the main header and MUST NOT compensate for lost headers.
如果mh_id字段设置为0，则接收器不得保存主标头，也不得补偿丢失的标头。
If the mh_id value changes, receivers SHOULD save the current header and save the new mh_id value. The old saved header should be deleted from storage.
如果mh_id值更改，接收器应保存当前标头并保存新的mh_id值。应从存储器中删除旧保存的标题。
Also, if the decoder detects an inconsistency between the header and payload, it is recommended to clear the saved mh_id and the saved main header. Please see Section 8 for more explanation.
此外，如果解码器检测到报头和有效负载之间不一致，建议清除保存的mh_id和保存的主报头。更多解释请参见第8节。
This document extends the associated media type "video/jpeg2000" from RFC 5371 [RFC5371]. Here are additional optional parameters.
本文档扩展了RFC 5371[RFC5371]中的相关媒体类型“video/jpeg2000”。以下是其他可选参数。
Additional optional parameters:
其他可选参数：
mhc: Main Header Compensation. This option is used when a sender and/or receiver is utilizing the Main Header Compensation technique as specified in this document. Acceptable values when using the Main Header Compensation technique is "1"; otherwise, it should be "0".
主收割台补偿。当发送方和/或接收方使用本文档中指定的主标题补偿技术时，使用此选项。使用主割台补偿技术时的可接受值为“1”；否则，它应该是“0”。
This is a list of options to be included when the sender or receiver is utilizing the priority table option as specified in this document.
这是当发送方或接收方使用本文档中指定的优先级表选项时要包括的选项列表。
pt: Priority Table. This option is followed by a comma-separated list of pre-defined priority table definitions to be used by sender or receiver.
pt：优先级表。此选项后面是由发送方或接收方使用的预定义优先级表定义的逗号分隔列表。
The option appearing front most in the option line is the most important and the next are of decreasing importance.
出现在选项行最前面的选项是最重要的，其次是重要性逐渐降低的选项。
Acceptable values:
可接受值：
progression: this table follows the progression ordering of the codestream.
进度：此表遵循代码流的进度顺序。
layer: this table follows the layer ordering of the codestream.
层：此表遵循代码流的层顺序。
resolution: this table follows the resolution ordering of the codestream.
分辨率：此表遵循码流的分辨率顺序。
component: this table follows the component ordering of the codestream.
组件：此表遵循代码流的组件顺序。
default: this table follows the packet ordering of the codestream.
默认值：此表遵循代码流的数据包顺序。
The new optional parameters mhc and pt, if presented, MUST be included in the "a=fmtp" line of SDP. These parameters are expressed as a media type string, in the form of a semicolon-separated list of parameter=value pairs.
新的可选参数mhc和pt（如有）必须包含在SDP的“a=fmtp”行中。这些参数表示为媒体类型字符串，以分号分隔的参数=值对列表的形式。
In addition to the SDP Offer/Answer section in RFC 5371 [RFC5371]:
除了RFC 5371[RFC5371]中的SDP报价/应答部分外：
When offering JPEG 2000 over RTP using SDP in an Offer/Answer model [RFC3264], the following rules and limitations apply:
在提供/应答模型[RFC3264]中使用SDP通过RTP提供JPEG 2000时，适用以下规则和限制：
o All parameters MUST have an acceptable value for that parameter.
o 所有参数必须具有该参数的可接受值。
o All parameters MUST correspond to the parameters of the payload.
o 所有参数必须与有效载荷的参数相对应。
o If the optional parameter "mhc" is used, it MUST appear in the offer with value "1", and if accepted, it SHOULD appear in the answer.
o 如果使用可选参数“mhc”，它必须以值“1”出现在报价中，如果接受，它应该出现在答案中。
o If the optional parameter "pt" is used, it MUST appear in the offer containing a complete comma-separated list indicating which priority table definitions the sender supports. If accepted, it SHOULD appear in the answer containing a single priority table definition selected from the offer.
o 如果使用可选参数“pt”，则它必须出现在包含完整逗号分隔列表的报价中，该列表指示发送方支持哪些优先级表定义。如果接受，它应出现在包含从报价中选择的单个优先级表定义的答案中。
o If the optional parameter "mhc" is used, it MUST appear in the offer with value "1", and if accepted, it MUST appear in the answer. If the optional parameter "pt" is used, it MUST appear in the offer containing a complete comma-separated list indicating which priority table definitions the sender supports. If accepted, it MUST appear in the answer containing a single priority table definition selected from the offer.
o 如果使用可选参数“mhc”，它必须以值“1”出现在报价中，如果接受，它必须出现在答案中。如果使用可选参数“pt”，则它必须出现在包含完整逗号分隔列表的报价中，该列表指示发送方支持哪些优先级表定义。如果接受，它必须出现在包含从报价中选择的单个优先级表定义的答案中。
o In a multicast environment:
o 在多播环境中：
* Senders should send out one option for a priority table definition for everyone in the group.
* 发件人应为组中的每个人发送一个优先级表定义选项。
* Even if a single client in the group does not support the extensions outlined in this document, senders MAY use these mechanisms. A receiver that doesn't support the mechanisms would safely ignore the values.in mh_id and priority field.
* 即使组中的单个客户端不支持本文档中概述的扩展，发件人也可以使用这些机制。不支持这些机制的接收器将安全地忽略mh_id和priority字段中的值。
Offer/Answer example exchanges are provided.
提供了报价/应答示例交换。
Alice offers Main Header Compensation functionality, YCbCr 422 color space, interlace image with 720-pixel width and 480-pixel height, and several priority table options (default, progression, layer, resolution, component) as below:
Alice提供了主要的标题补偿功能、YCbCr 422颜色空间、720像素宽和480像素高的隔行扫描图像，以及几个优先级表选项（默认、级数、图层、分辨率、组件），如下所示：
v=0
o=alice 2890844526 2890844526 IN IP4 host.example
s=
c=IN IP4 host.example
t=0 0
m=video 49170 RTP/AVP 98
a=rtpmap:98 jpeg2000/90000
a=fmtp:98 mhc=1; sampling=YCbCr-4:2:2; interlace=1;
pt=default,progression,layer,resolution, component;
width=720;height=480
v=0
o=alice 2890844526 2890844526 IN IP4 host.example
s=
c=IN IP4 host.example
t=0 0
m=video 49170 RTP/AVP 98
a=rtpmap:98 jpeg2000/90000
a=fmtp:98 mhc=1; sampling=YCbCr-4:2:2; interlace=1;
pt=default,progression,layer,resolution, component;
width=720;height=480
Bob accepts Main Header Compensation functionality, YCbCr-4:2:2 color space, interlace image, default mapping table and replies:
Bob接受主标题补偿功能、YCbCr-4:2:2颜色空间、隔行扫描图像、默认映射表和回复：
v=0
o=bob 2890844730 2890844731 IN IP4 host.example
s=
c=IN IP4 host.example
t=0 0
m=video 49920 RTP/AVP 98
a=rtpmap:98 jpeg2000/90000
a=fmtp:98 mhc=1; sampling=YCbCr-4:2:2;interlace=1;
pt=default;width=720;height=480
v=0
o=bob 2890844730 2890844731 IN IP4 host.example
s=
c=IN IP4 host.example
t=0 0
m=video 49920 RTP/AVP 98
a=rtpmap:98 jpeg2000/90000
a=fmtp:98 mhc=1; sampling=YCbCr-4:2:2;interlace=1;
pt=default;width=720;height=480
Alice offers Main Header Compensation, YCbCr 420 color space, progressive image with 320-pixel width and 240-pixel height, and layer priority table options as below:
Alice提供了主标题补偿、YCbCr 420颜色空间、320像素宽和240像素高的渐进式图像，以及图层优先级表选项，如下所示：
v=0
o=alice 2890844526 2890844526 IN IP4 host.example
s=
c=IN IP4 host.example
t=0 0
m=video 49170 RTP/AVP 98
a=rtpmap:98 jpeg2000/90000
a=fmtp:98 mhc=1; sampling=YCbCr-4:2:0;
pt=layer;width=320;height=240
v=0
o=alice 2890844526 2890844526 IN IP4 host.example
s=
c=IN IP4 host.example
t=0 0
m=video 49170 RTP/AVP 98
a=rtpmap:98 jpeg2000/90000
a=fmtp:98 mhc=1; sampling=YCbCr-4:2:0;
pt=layer;width=320;height=240
Bob does not accept Main Header Compensation functionality but accepts YCbCr-4:2:0 color space, layer-based priority mapping and replies:
Bob不接受主标题补偿功能，但接受YCbCr-4:2:0颜色空间、基于图层的优先级映射和回复：
v=0
o=bob 2890844730 2890844731 IN IP4 host.example
s=
c=IN IP4 host.example
t=0 0
m=video 49920 RTP/AVP 98
a=rtpmap:98 jpeg2000/90000
a=fmtp:98 mhc=0; sampling=YCbCr-4:2:0;
pt=layer;width=320;height=240
v=0
o=bob 2890844730 2890844731 IN IP4 host.example
s=
c=IN IP4 host.example
t=0 0
m=video 49920 RTP/AVP 98
a=rtpmap:98 jpeg2000/90000
a=fmtp:98 mhc=0; sampling=YCbCr-4:2:0;
pt=layer;width=320;height=240
Alice offers 27 MHz timestamp, Main Header Compensation, YCbCr 420 color space, progressive image with 320-pixel width and 240-pixel height, and layer priority table options as below:
Alice提供27 MHz时间戳、主标题补偿、YCbCr 420颜色空间、320像素宽和240像素高的渐进式图像，以及以下图层优先级表选项：
v=0
o=alice 2890844526 2890844526 IN IP4 host.example
s=
c=IN IP4 host.example
t=0 0
m=video 49170 RTP/AVP 98 99
a=rtpmap:98 jpeg2000/27000000
a=rtpmap:99 jpeg2000/90000
a=fmtp:98 mhc=1; sampling=YCbCr-4:2:0;
pt=layer;width=320;height=240
a=fmtp:99 mhc=1; sampling=YCbCr-4:2:0;
pt=layer;width=320;height=240
v=0
o=alice 2890844526 2890844526 IN IP4 host.example
s=
c=IN IP4 host.example
t=0 0
m=video 49170 RTP/AVP 98 99
a=rtpmap:98 jpeg2000/27000000
a=rtpmap:99 jpeg2000/90000
a=fmtp:98 mhc=1; sampling=YCbCr-4:2:0;
pt=layer;width=320;height=240
a=fmtp:99 mhc=1; sampling=YCbCr-4:2:0;
pt=layer;width=320;height=240
Bob can accept payload type with 27 MHz timestamp, and does not accept Main Header Compensation functionality but accepts YCbCr-4:2:0 color space, layer-based priority mapping and replies:
Bob可以接受带有27 MHz时间戳的有效负载类型，不接受主报头补偿功能，但接受YCbCr-4:2:0颜色空间、基于层的优先级映射和回复：
v=0
o=bob 2890844730 2890844731 IN IP4 host.example
s=
c=IN IP4 host.example
t=0 0
m=video 49920 RTP/AVP 98
a=rtpmap:98 jpeg2000/27000000
a=fmtp:98 mhc=0; sampling=YCbCr-4:2:0;
pt=layer;width=320;height=240
v=0
o=bob 2890844730 2890844731 IN IP4 host.example
s=
c=IN IP4 host.example
t=0 0
m=video 49920 RTP/AVP 98
a=rtpmap:98 jpeg2000/27000000
a=fmtp:98 mhc=0; sampling=YCbCr-4:2:0;
pt=layer;width=320;height=240
This document extends the associated media type "video/jpeg2000" from 5371 [RFC5371]. Additional parameters are specified in Section 5 of this document.
本文档从5371[RFC5371]扩展了相关媒体类型“video/jpeg2000”。本文件第5节规定了其他参数。
Please refer to Section 6 of RFC 5371 [RFC5371] for Security Considerations regarding this RTP format. The security issues regarding enhanced mechanisms presented in this document are discussed in that section.
有关此RTP格式的安全注意事项，请参阅RFC 5371[RFC5371]第6节。该节讨论了本文件中介绍的增强机制的安全问题。
The mh_id field can identify a maximum of 7 different main headers. If severe packet loss (either random or intentionally introduced by an attacker) causes 6 successive updates to the main header to be lost, the decoder will attempt decompression using an incorrect main header. Even if the incorrect main header is passed, the standard JPEG 2000 decoder could detect inconsistency of the codestream and process it properly. It is recommended to clear the saved mh_id and the saved main header if the decoder detects such an inconsistency.
mh_id字段最多可以识别7个不同的主标题。如果严重的数据包丢失（无论是随机的还是攻击者故意引入的）导致主报头的6次连续更新丢失，解码器将尝试使用不正确的主报头进行解压缩。即使传递了不正确的主头，标准JPEG 2000解码器也可以检测码流的不一致性并正确处理。如果解码器检测到这种不一致，建议清除保存的mh_id和保存的主标头。
Please refer to Section 7 of RFC 5371 [RFC5371] for Congestion Control regarding this RTP format.
有关此RTP格式的拥塞控制，请参阅RFC 5371[RFC5371]第7节。
[RFC5371] Futemma, S., Leung, A., and E. Itakura, "RTP Payload Format for JPEG 2000 Video Streams", RFC 5371, October 2008.
[RFC5371]Futemma，S.，Leung，A.，和E.Itakura，“JPEG 2000视频流的RTP有效载荷格式”，RFC 5371，2008年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[JPEG2000Pt_1] ISO/IEC JTC1/SC29, ISO/IEC 15444-1 | ITU-T Rec. T.800, "Information Technology - JPEG 2000 Image Coding System - Part 1: Core Coding System", December 2000.
[JPEG2000Pt_1]ISO/IEC JTC1/SC29，ISO/IEC 15444-1 | ITU-T Rec.T.800，“信息技术-JPEG 2000图像编码系统-第1部分：核心编码系统”，2000年12月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264]Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，2002年6月。
The following figures are sample RTP headers demonstrating values that should appear in the RTP header. The packet priority is Packet-Number-Based Priority.
下图是示例RTP标头，演示了应显示在RTP标头中的值。分组优先级是基于分组编号的优先级。
For reference, the payload header is as follows:
作为参考，有效载荷标题如下所示：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|tp |MHF|mh_id|T| priority | tile number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|reserved | fragment offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|tp |MHF|mh_id|T| priority | tile number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|reserved | fragment offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: JPEG 2000 Payload Header
图2:JPEG2000有效载荷头
A.1. Sample 1: Progressive Image with Single Tile, 3500 Bytes (i.e., thumbnail)
A.1. 示例1：单块渐进图像，3500字节（即缩略图）
First Packet: This packet will have the whole main header 210 bytes
第一个数据包：这个数据包将有整个主报头210字节
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 3 | 1 |1| 0 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|FF4F FF51 002F 0000 .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 3 | 1 |1| 0 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|FF4F FF51 002F 0000 .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Header Sample 1-1 (First Packet)
图3：报头示例1-1（第一个数据包）
Second Packet: This packet will have a tile header and the first tile part LLband 1500 bytes
第二个数据包：这个数据包将有一个tile头和第一个tile部分LLband 1500字节
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 0 | 1 |0| 1 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 210 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|FF90 000A 0000 0000 2DB3 0001 FF93 .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 0 | 1 |0| 1 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 210 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|FF90 000A 0000 0000 2DB3 0001 FF93 .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Header Sample 1-2 (Second Packet)
图4：报头示例1-2（第二个数据包）
Third Packet: This packet will have the next part in the tile, no tile header 1500 bytes
第三个数据包：这个数据包将在磁贴中有下一部分，没有磁贴头1500字节
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 0 | 1 |0| 2 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 1710 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E841 4526 4556 9850 C2EA .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 0 | 1 |0| 2 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 1710 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E841 4526 4556 9850 C2EA .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Header Sample 1-3 (Third Packet)
图5：报头示例1-3（第三个数据包）
Fourth Packet: Last packet for the image 290 bytes
第四个数据包：图像290字节的最后一个数据包
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 0 | 1 |0| 3 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 3210 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A55D 8B73 3B25 25C7 B9EB .... 2FBE B153|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 0 | 1 |0| 3 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 3210 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A55D 8B73 3B25 25C7 B9EB .... 2FBE B153|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Header Sample 1-4 (Fourth Packet)
图6：报头示例1-4（第四个数据包）
First Packet: This packet will have the whole main header 210 bytes
第一个数据包：这个数据包将有整个主报头210字节
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 3 | 1 |1| 0 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|FF4F FF51 002F 0000 .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 3 | 1 |1| 0 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|FF4F FF51 002F 0000 .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Header Sample 2-1 (First Packet)
图7：报头示例2-1（第一个数据包）
Second Packet: This packet will have a first tile part (tile 0) 1400 bytes
第二个数据包：此数据包将具有第一个磁贴部分（磁贴0）1400字节
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 0 | 1 |0| 1 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 210 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|FF90 000A 0000 0000 0578 0001 FF93 .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 0 | 1 |0| 1 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 210 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|FF90 000A 0000 0000 0578 0001 FF93 .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Header Sample 2-2 (Second Packet)
图8：报头示例2-2（第二个数据包）
Third Packet: This packet will have a second tile part (tile 1) 1423 bytes
第三个数据包：该数据包将有第二个磁贴部分（磁贴1）1423字节
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 0 | 1 |0| 1 | 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 1610 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|FF90 000A 0001 0000 058F 0001 FF93 .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 0 | 1 |0| 1 | 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 1610 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|FF90 000A 0001 0000 058F 0001 FF93 .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Header Sample 2-3 (Third Packet)
图9：报头示例2-3（第三个数据包）
Fourth Packet: This packet will have a third tile part (tile 2) 1355 bytes
第四个数据包：该数据包将有第三个磁贴部分（磁贴2）1355字节
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 0 | 1 |0| 1 | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 3033 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|FF90 000A 0002 0000 054B 0001 FF93 .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 0 | 1 |0| 1 | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 3033 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|FF90 000A 0002 0000 054B 0001 FF93 .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Header Sample 2-4 (4th Packet)
图10：标题示例2-4（第4个数据包）
Fifth Packet: This packet will have a fourth tile part (tile 3) 1290 bytes
第五个数据包：这个数据包将有第四个tile部分（tile 3）1290字节
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 0 | 1 |0| 1 | 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 4388 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|FF90 000A 0003 0000 050A 0001 FF93 .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 0 | 1 |0| 1 | 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 4388 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|FF90 000A 0003 0000 050A 0001 FF93 .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Header Sample 2-5 (5th Packet)
图11：标题示例2-5（第5个数据包）
A.3. Sample 3: Packing Multiple Tiles in Single Payload, Fragmented Header. No Header Compensation, Progressive Image
A.3. 示例3：在单个有效负载、碎片标题中打包多个磁贴。无标题补偿，逐行扫描图像
First Packet: This packet will have the first part of the main header 110 bytes
第一个数据包：该数据包将具有主报头的第一部分110字节
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 1 | 0 |1| 0 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|FF4F FF51 002F 0000 .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 1 | 0 |1| 0 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|FF4F FF51 002F 0000 .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Header Sample 3-1 (First Packet)
图12：报头示例3-1（第一个数据包）
Second Packet: This packet has the second part of the main header. 1400 bytes
第二个数据包：这个数据包有主报头的第二部分。1400字节
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 2 | 0 |1| 0 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 110 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|FF64 00FF .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 2 | 0 |1| 0 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 110 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|FF64 00FF .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: Header Sample 3-2 (Second Packet)
图13：报头示例3-2（第二个数据包）
Third Packet: This packet has two tiles, tile 0 and tile 1 1400 bytes
第三个数据包：这个数据包有两个分片，分片0和分片1 1400字节
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 0 | 0 |1| 1 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 1510 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|FF90 000A 0000 0000 02BC 0001 FF93 ... |
// . //
|FF90 000A 0001 0000 02BC 0001 FF93 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 0 | 0 |1| 1 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 1510 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|FF90 000A 0000 0000 02BC 0001 FF93 ... |
// . //
|FF90 000A 0001 0000 02BC 0001 FF93 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: Header Sample 3-3 (Third Packet)
图14：报头示例3-3（第三个数据包）
Fourth Packet: This packet has one tile, tile 2 1395 bytes
第四个数据包：这个数据包有一个磁贴，磁贴2 1395字节
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 0 | 0 |0| 1 | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 2910 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|FF90 000A 0002 0000 0573 0001 FF93 .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 0 | 0 |0| 1 | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 2910 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|FF90 000A 0002 0000 0573 0001 FF93 .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: Header Sample 3-4 (4th Packet)
图15：标题示例3-4（第4个数据包）
The codestream of each image is ordered in LRCP (Layer, Resolution, Component, Position) with 1 layer, 3 resolutions, 3 components and 1 position.
每个图像的码流按LRCP（层、分辨率、分量、位置）排序，具有1层、3个分辨率、3个分量和1个位置。
First packet: This packet will have the whole main header for the odd field 210 bytes
第一个数据包：该数据包将具有奇数字段210字节的整个主报头
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 3 | 1 |1| 0 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|FF4F FF51 002F 0000 .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 3 | 1 |1| 0 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|FF4F FF51 002F 0000 .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: Header Sample 4-1 (First Packet)
图16：报头示例4-1（第一个数据包）
Second packet: This packet will have the first part of the odd field's tile where three jp2-packets are included 1400 bytes
第二个数据包：该数据包将具有奇数字段分片的第一部分，其中包括三个jp2数据包，共1400字节
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 0 | 1 |1| 1 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 210 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|FF90 000A 0000 0000 0578 0001 FF93 .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 0 | 1 |1| 1 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 210 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|FF90 000A 0000 0000 0578 0001 FF93 .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: Header Sample 4-2 (Second Packet)
图17：报头示例4-2（第二个数据包）
Third packet: This packet will have the second part of the odd field's tile 1400 bytes
第三个数据包：这个数据包将有奇数字段的第二部分1400字节
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 0 | 1 |1| 4 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 1610 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|7F04 E708 27D9 D11D 22CB ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 0 | 1 |1| 4 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 1610 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|7F04 E708 27D9 D11D 22CB ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: Header Sample 4-3 (Third Packet)
图18：报头示例4-3（第三个数据包）
Fourth packet: This packet will have the third part of the odd field's tile 1300 bytes
第四个数据包：这个数据包将有奇数字段的第三部分1300字节
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 0 | 1 |1| 7 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 3010 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|98BD EC9B 2826 DC62 D4AB ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 0 | 1 |1| 7 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 3010 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|98BD EC9B 2826 DC62 D4AB ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19: Header Sample 4-4 (4th Packet)
图19：报头示例4-4（第4个数据包）
Fifth packet: This packet will have the whole main header for the even field 210 bytes
第五个数据包：此数据包将具有整个主报头，用于偶数字段210字节
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | 3 | 1 |1| 0 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|FF4F FF51 002F 0000 .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | 3 | 1 |1| 0 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|FF4F FF51 002F 0000 .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 20: Header Sample 4-5 (5th Packet)
图20：标题示例4-5（第5包）
Sixth packet: This packet will have the first part of the even field's tile 1400 bytes
第六个数据包：此数据包将包含偶数字段的第一部分1400字节
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | 0 | 1 |1| 1 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 1610 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|FF90 000A 0000 0000 0578 0001 FF93 .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | 0 | 1 |1| 1 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 1610 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|FF90 000A 0000 0000 0578 0001 FF93 .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 21: Header Sample 4-6 (6th Packet)
图21：标题示例4-6（第6包）
Seventh packet: This packet will have the second part of the even field's tile 1400 bytes
第七个数据包：这个数据包将包含偶数字段的第二部分1400字节
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | 0 | 1 |1| 4 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 3010 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|626C 42F0 166B 6BD0 F8E1 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | 0 | 1 |1| 4 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 3010 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|626C 42F0 166B 6BD0 F8E1 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 22: Header Sample 4-7 (7th Packet)
图22：标题示例4-7（第7包）
Eighth packet: This packet will have the third part of the even field's tile 1300 bytes
第八个数据包：这个数据包将包含偶数字段的第三部分1300字节
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | 0 | 1 |1| 7 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 4410 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|8114 41D5 18AB 4A1B ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | 0 | 1 |1| 7 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 4410 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|8114 41D5 18AB 4A1B ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 23: Header Sample 4-8 (8th Packet)
图23：标题示例4-8（第8包）
Authors' Addresses
作者地址
Andrew Leung Sony Corporation
梁建邦索尼公司
EMail: andrew@ualberta.net
EMail: andrew@ualberta.net
Satoshi Futemma Sony Corporation 1-7-1 Konan Minato-ku Tokyo 108-0075 Japan
Satoshi Futemma索尼公司1-7-1日本东京河南Minato区108-0075
Phone: +81 3 6748-2111
EMail: satosi-f@sm.sony.co.jp
URI: http://www.sony.net/
Phone: +81 3 6748-2111
EMail: satosi-f@sm.sony.co.jp
URI: http://www.sony.net/
Eisaburo Itakura Sony Corporation 1-7-1 Konan Minato-ku Tokyo 108-0075 Japan
东谷荣三郎索尼公司1-7-1日本东京河南町108-0075
Phone: +81 3 6748-2111
EMail: itakura@sm.sony.co.jp
URI: http://www.sony.net/
Phone: +81 3 6748-2111
EMail: itakura@sm.sony.co.jp
URI: http://www.sony.net/
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.