RFC 2448

AT&T's Error Resilient Video Transmission Technique

📅 published November 1998, from ietf

AT&T's Error Resilient Video Transmission Technique 🎀

Okay bestie, here's the header rundown 💖

  • Network Working Group 🌸
  • Number: RFC 2448
  • Authors: M. Civanlar, G. Cash, and B. Haskell
  • Affiliation: AT&T Labs-Research
  • Category: Informational (so it's info, not an Internet standard 🧚)
  • Date: November 1998
  • Obsoletes and updates: the header doesn't list any RFCs this one obsoletes or updates ✨

Status of this Memo

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

Copyright (C) The Internet Society (1998). All Rights Reserved.

Abstract

Okay so this doc describes a set of techniques for packet loss resilient transmission of compressed video bitstreams. The whole trick is based on reliable delivery of their vital information-carrying segments 🛡️. The techniques can be used over packet networks without packet prioritization, which is so iconic ngl 👑. They're related to AT&T/Lucent patents [1, 2].

1. Introduction ✨

It's well known that every bit in a compressed video bitstream is not equal 🙈. Some bits belong to segments defining vital information, like picture types, quantization values, parameter ranges, average intensity values for image blocks, and so on. When compressed video bitstreams travel over packet networks, losing packets from those segments causes a much longer lasting and more severe degradation on the decoder's output than losing packets from other segments. We'll call the vital information-carrying segments "High Priority (HP)" segments 💅. The rest of the bitstream is made of "Low Priority (LP)" segments. Clearly, video outputs from transport techniques that protect the HP segments against packet losses are more resilient to packet losses in general 🫶.

There are a bunch of ways to protect the HP segments. These include:

  • redundant transmission of the HP segments as described in [3] for MPEG RTP payloads
  • using forward error correction (FEC) techniques
  • transmitting HP segments over reserved channels or using differentiated services.

So both redundant transmission and FEC techniques increase the bandwidth needed to transmit the compressed video bitstream. FEC techniques make that extra bandwidth more effective for packet loss protection, but at the cost of more processing at the receiver and transmitter ends and more overall delay 😭. Channel reservations or differentiated services approaches may be the best solutions for protecting the HP segments, but they require network infrastructure changes 💀.

This document outlines another set of HP segment protection techniques, based on AT&T/Lucent patents [1, 2], that can be used for reliable video transmission over packet networks without a built-in prioritization mechanism 🦋. These techniques use reliable transport protocols and "out-of-band" delivery approaches. Here, "out-of-band" means information transmission by means other than the ones used for transmitting the main video stream. The details are in the following sections. An implementation of these, as applied to MPEG-2 video transmission over IP networks, is described in [4] 🧚.

The IESG/IETF take no position regarding the validity or scope of any intellectual property right or other rights that might be claimed to pertain to the implementation or use of the technology, or the extent to which any license under such rights might or might not be available. See the IETF IPR web page at http://www.ietf.org/ipr.html for any additional information that has been forwarded to the IETF. 🌈

2. Identification of the HP segments 🔥

Whether a part of a video bitstream counts as an HP segment depends on two factors. The first is the encoding algorithm used to compress the video data. It's impossible to segment a compressed video bitstream without knowing the syntax and semantics of the encoding algorithm 🤓. The second factor is finding a compromise between the HP segment size and the corresponding loss resilience. As the segment size grows, so does the loss resilience. On the other hand, it may not be feasible to deliver large HP segments reliably 😬.

For example, the "data partitioning" method of the MPEG-2 standard [5] defines the syntax and semantics for one particular way of partitioning an MPEG-2 encoded video bitstream into HP and LP segments. With data partitioning, the smallest useful HP segment can contain only the header information, which is usually less than two percent of the video data. HP segments defined this way carry vital information like picture type, quantization factor, motion vector ranges, and so on, and the rest of the bitstream isn't decodable without them 📦. As an alternative, the DC coefficients (the average values) for each picture macroblock can go in the HP segment, which bumps its size up to about 40% of the bitstream. This way HP segments can carry somewhat usable video information too, but reliably transmitting them can become a demanding task 😤.

Since there's no general technique for identifying the HP segments in any encoded video bitstream, we'll assume that these segments get identified some way before transmission 🗂️. For example, some encoders can generate HP and LP segments separately, or a stored bitstream can already be in the partitioned format. Also, consistent with most of the popular coding techniques, we assume the HP segments (HP1, HP2, ...) are dispersed over the entire bitstream in time, as shown in Fig. 1 🌸.

   +---+----------------+---+----------------------+---+-----
   |HP1|     LP1        |HP2|        LP2           |HP3| ...
   +---+----------------+---+----------------------+---+-----
                                Figure 1
       HP segments dispersed on an encoded video bitstream over time

3. Transmission of HP data using a reliable transport protocol [1] 🚀

In this approach, one or more HP segments get sent with a reliable transport protocol before the LP segments start going out ✨. For point-to-point applications, TCP is used. For multipoint applications, an appropriate reliable multicast protocol [6] may be used to transport the HP segments. How many HP segments get sent before the LP segments start depends on the application's tolerance to start-up delay. Depending on the HP segment size and the path-MTU [7], one or more HP segments can be put in each packet carrying the HP data 💖.

HP segments can be packetized using RTP with the following definitions for the header fields:

  • Payload Type: A distinct payload type number, which may be dynamic, should be assigned to HP segments of each video payload.
  • M Bit: Set for packets containing HP data for key pictures.
  • timestamp: Uses the same format as that of the video payload. Shows the sampling time for the video data following the first HP segment in the packet.

The SSRC field may be defined following the rules developed for transmitting layered media streams in [8]. That means:

  • A single SSRC space is used for the HP segment packets and the main video stream. Only the latter is used for SSRC allocation and conflict resolution. When a source discovers that it has collided, it transmits an RTCP BYE message on only the main video stream.
  • A participant sends sender identification (SDES) on only the main video stream.

Most HP segments are self-identifying and can be packed without any additional headers 🧃. For others, techniques used for packetizing generic payload types may be used, or special payload types may be defined.

It's possible to send the HP data along with the LP data (i.e., the original, unpartitioned bitstream) in addition to sending the HP segments separately. That way, the separately transmitted HP segments are only needed when packet losses occur 🫶.

Part 2 is coming up next, bestie 🧚💜

Authors' Addresses ✨

okay bestie, here are the three people who wrote this thing 🫶 they all worked at AT&T Labs-Research in Red Bank, New Jersey 🦋

M. Reha Civanlar
AT&T Labs-Research
100 Schultz Drive
Red Bank, NJ 07701
USA

EMail: civanlar@research.att.com


Glenn L. Cash
AT&T Labs-Research
100 Schultz Drive
Red Bank, NJ 07701
USA

EMail: glenn@research.att.com


Barry G. Haskell
AT&T Labs-Research
100 Schultz Drive
Red Bank, NJ 07701
USA

EMail: bgh@research.att.com

this part is legal stuff, so I kept the wording exactly as written 📜 no cap, the details matter here 💜

Copyright (C) The Internet Society (1998). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. 🙈
📦 where this page comes from