Internet Engineering Task Force R. Herrero
Internet-Draft Northeastern University
Intended status: Informational C. St.Pierre
Expires: December 23, 2019 L7TR
June 21, 2019

RTP Payload Format for CCSDS Compressed Image Data


This memo describes an RTP payload format for the Consultative Committee for Space Data Systems (CCSDS) Compressed Image Data standard [CCSDS122.0]. The compression is typically applied to two-dimensional and three-dimensional data cubes resulting from multispectral and hyperspectral imagining instruments.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on December 23, 2019.

Copyright Notice

Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents ( in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1. Introduction

The CCSDS compressed image data standard can be used to produce both lossy and lossless compression in a scenario that targets high-rate instruments used on board of spacecraft. Moreover it provides a trade-off between compression performance and complexity with particular emphasis on spacecraft applications. As a low complexity mechanism it supports fast and low power hardware implementations.

The compressor consists of two functional parts, shown in Figure 1, a Discrete Wavelet Transform module that performs decorrelation and a Bit-Plane Encoder which encodes the decorrelated data. It is outside the scope of this document to further describe in detail this procedure. Please refer to [CCSDS122.0] for more information.

              +----------+    +----------+
              | Discrete |    |   Bit    | 
Raw Image ==> |   Wave   |--->|  Plane   | ==> Compressed Image
              | Transform|    |  Encoder |
              +----------+    +----------+

Block diagram of the CCSDS encoder[CCSDS122.0].

Figure 1

The coded data that results from each CCSDS compressed image is composed of a sequence of self-contained and self-defined segments. Depending on the size of the segments several RTP packetization scenarios are possible; (1) Each RTP packet transports a single segment, (2) Each RTP packet transports several fragments or (3) Each fragment is transported across several RTP packets. In particular, for cases (2) and (3), if segments are packetized directly over RTP there is potential for corruption that extends beyond segments affected by packet loss.

	   Packet #1: [RTP Header][1][2][3]
	   Packet #2: [RTP Header][3]
	   Packet #3: [RTP Header][3][4][5]

Five Segments over RTP

Figure 2

For example, Figure 2 shows five segments being transported over three RTP packets. If RTP packet #2 is lost due to network packet loss, not only segment 3 in RTP packet #2 is lost but also subsequent segments 3 and 4 carried in received RTP packet #3 are lost due to the fact the decoder cannot determine the beginning of either one of these segments.

This document specifies a payload format for packetization of CCSDS compressed images that relies on identifying the boundaries between segments inside RTP packets.

2. Conventions

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.

3. Header Format

3.1. RTP Fixed Header Usage

For each RTP packet, the RTP fixed header is followed by the CCSDS Image RTP payload header. This header is, in turns, followed by the image payload consisting of a full or partial sequence of segments. The RTP header fields that have a meaning specific to a CCSDS image are described as follows:

3.2. RTP Payload Header Format

The RTP payload header format for CCSDS compressed images indicates the offset to the beginning of the first new segment carried in the packet. If the packet doesn't contain the beginning of a new segment, the offset is 0. The offset is specified as byte and bit units. If the byte offset is between 0 and 15 bytes the format of the header is as shown in Figure 3

 0 1 2 3 4 5 6 7  
|0|  btos | bos |

Figure 3

 0                   1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 
|1|          btos         | bos |

Figure 4

If the byte offset is larger than 16 bytes the format of the header is as shown in Figure 4.

4. RTP Packetization

The sender must packetize the CCSDS compressed images appropriately according to initial media type parameters. A sender divides the codestream into segments by parsing the codestream or by getting information from the encoder, and packs the segments into RTP packets. A sender can put an arbitrary number of segments into an RTP packet, but it MUST preserve the codestream order. An example of this kind of RTP packet format is shown in Figure 5

|RTP   |payload|     image     |     image     |
|header|header |    segment    |    segment    |

An example with multiple segments

Figure 5

If a segment is larger than the MTU size, it MAY be fragmented as shown in Figure 6

|RTP   |payload|                  image segment                  |
|header|header |                     fragment                    |
|RTP   |payload|                  image segment                  |
|header|header |                     fragment                    |
|RTP   |payload|            image segment           |
|header|header |            end fragment            |

An example with multiple segments

Figure 6

5. SDP Parameters

The MIME media type image/ccsds string is mapped to fields in the Session Description Protocol (SDP) as follows:

The media name in the "m=" line of SDP MUST be image.

The encoding name in the "a=rtpmap" line of SDP MUST be ccsds (the MIME subtype).

6. Security Considerations

RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification RFC 3550.

7. Normative References

[CCSDS122.0] Consultative Committee for Space Data Systems, "CCSDS 122.0-B-2: Image Data Compression", September 2017.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003.

Authors' Addresses

Rolando Herrero Northeastern University Boston, MA US EMail:
Claude St.Pierre L7TR Manchester, NH US EMail: