RTP Payload Format for CCSDS Compressed Image Data
draft-herrero-avt-ccsds-00

Abstract

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 https://datatracker.ietf.org/drafts/current/.

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 (https://trustee.ietf.org/license-info) 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
• 2. Conventions
• 3. Header Format
• 3.1. RTP Fixed Header Usage
• 3.2. RTP Payload Header Format
• 4. RTP Packetization
• 5. SDP Parameters
• 6. Security Considerations
• 7. Normative References
• Authors' Addresses

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:

• Marker bit (M): The marker bit of the RTP fixed header MUST be set to 1 for the last RTP packet of an image frame; otherwise, it MUST be 0. When transmission is performed by multiple RTP sessions, this bit is 1 in the last packet of the frame in each session.
• Payload type (PT): The payload type is dynamically assigned by means outside the scope of this document. A payload type in the dynamic range shall be chosen by means of an out-of-band signaling protocol (i.e., Real Time Streaming Protocol (RTSP), SIP, etc.).
• Timestamp: Timestamp indicates the presentation time of the frame contained in the RTP packet. The same timestamp value MUST appear in each RTP packet carrying a fragment of a given frame. Following the RTP specification RFC 3550, the initial value of the timestamp should be randomly chosen.
  
  As for the clock rate, senders and receivers MUST support the 90kHz RTP timestamp rate, and MAY support other rates. RTP timestamp rates below 1000 Hz SHOULD NOT be used because they will result in insufficient resolution for RTP Control Protocol (RTCP) measurements based on the RTP timestamp, such as the interarrival jitter. The clock rate MUST be negotiated at the start of the session. When using the Session Description Protocol (SDP), it MUST be expressed using the "rtpmap" attributes. If a non-90kHz clock rate is to be used, it is RECOMMENDED to present not only a preferable clock rate but also 90kHz clock rate with a different RTP payload type.

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.

• btos (byte offset): 4 or 12 bits
  This field indicates the number of offset byte units to the first segment (if any).
• bos (bit offset): 3 bits
  This field indicates the number of offset bit units to the first segment (if any).

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

Authors' Addresses