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 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 Herrero & St.Pierre Expires December 23, 2019 [Page 1] Internet-Draft CCSDS Image RTP Payload Format June 2019 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Header Format . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. RTP Fixed Header Usage . . . . . . . . . . . . . . . . . 3 3.2. RTP Payload Header Format . . . . . . . . . . . . . . . . 4 4. RTP Packetization . . . . . . . . . . . . . . . . . . . . . . 5 5. SDP Parameters . . . . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 7. Normative References . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 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 Herrero & St.Pierre Expires December 23, 2019 [Page 2] Internet-Draft CCSDS Image RTP Payload Format June 2019 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 [RFC2119]. 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.). Herrero & St.Pierre Expires December 23, 2019 [Page 3] Internet-Draft CCSDS Image RTP Payload Format June 2019 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 [RFC3550], 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 If the byte offset is larger than 16 bytes the format of the header is as shown in Figure 4. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| btos | bos | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4 btos (byte offset): 4 or 12 bits This field indicates the number of offset byte units to the first segment (if any). Herrero & St.Pierre Expires December 23, 2019 [Page 4] Internet-Draft CCSDS Image RTP Payload Format June 2019 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 Herrero & St.Pierre Expires December 23, 2019 [Page 5] Internet-Draft CCSDS Image RTP Payload Format June 2019 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 [RFC3550]. 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: r.herrero@northeastern.edu Claude St.Pierre L7TR Manchester, NH US Email: claude@l7tr.com Herrero & St.Pierre Expires December 23, 2019 [Page 6]