Internet DRAFT - draft-herrero-avt-ccsds
draft-herrero-avt-ccsds
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,
<https://www.rfc-editor.org/info/rfc2119>.
[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, <https://www.rfc-editor.org/info/rfc3550>.
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]
