RFC 4629

RTP Payload Format for ITU-T Rec. H.263 Video

📅 published January 2007, from ietf

RFC 4629: RTP Payload Format for ITU-T Rec. H.263 Video 🎀

okay bestie, this is RFC 4629, published January 2007 as a Standards Track document in the Network Working Group 🦋 It was written by J. Ott (Helsinki University of Technology), C. Bormann (Universitaet Bremen TZI), G. Sullivan (Microsoft), S. Wenger (Nokia), and R. Even, Ed. (Polycom). It obsoletes RFC 2429 and updates the H263-1998 and H263-2000 media type registrations from RFC 3555 💅

Status of This Memo ✨

This document specifies an Internet standards track protocol for the Internet community, and asks for discussion and suggestions for improvements. Check the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited 💌

Copyright (C) The IETF Trust (2007).

Abstract 🔥

This document describes a scheme to packetize an H.263 video stream for transport using the Real-time Transport Protocol (RTP) with any of the underlying protocols that carry RTP.

The document also describes the syntax and semantics of the Session Description Protocol (SDP) parameters needed to support the H.263 video codec.

The document obsoletes RFC 2429 and updates the H263-1998 and H263-2000 media type in RFC 3555.

Table of Contents 📑

1. Introduction ....................................................3
   1.1. Terminology ................................................3
2. New H.263 Features ..............................................3
3. Usage of RTP ....................................................4
   3.1. RTP Header Usage ...........................................5
   3.2. Video Packet Structure .....................................6
4. Design Considerations ...........................................7
5. H.263+ Payload Header ...........................................9
   5.1. General H.263+ Payload Header ..............................9
   5.2. Video Redundancy Coding Header Extension ..................10
6. Packetization Schemes ..........................................12
   6.1. Picture Segment Packets and Sequence Ending
        Packets (P=1) .............................................12
        6.1.1. Packets that begin with a Picture Start Code .......12
        6.1.2. Packets that begin with GBSC or SSC ................13
        6.1.3. Packets that begin with an EOS or EOSBS Code .......14
   6.2. Encapsulating Follow-on Packet (P=0) ......................15
7. Use of this Payload Specification ..............................15
8. Media Type Definition ..........................................17
   8.1. Media Type Registrations ..................................17
        8.1.1. Registration of Media Type video/H263-1998 .........17
        8.1.2. Registration of Media Type video/H263-2000 .........21
   8.2. SDP Usage .................................................22
        8.2.1. Usage with the SDP Offer Answer Model ..............23
9. Backward Compatibility to RFC 2429 .............................25
   9.1. New Optional Parameters for SDP ...........................25
10. IANA Considerations ...........................................25
11. Security Considerations .......................................25
12. Acknowledgments ...............................................26
13. Changes from Previous Versions of the Documents ...............26
   13.1. Changes from RFC 2429 ....................................26
   13.2. Changes from RFC 3555 ....................................26
14. References ....................................................26
   14.1. Normative References .....................................26
   14.2. Informative References ...................................27

1. Introduction ✨

This document specifies an RTP payload header format for sending video streams based on the 1998 and 2000 versions of International Telecommunication Union-Telecommunication Standardization Sector (ITU-T) Recommendation H.263 [H263]. The 1998 and 2000 versions of H.263 are a superset of the 1996 syntax, so this format can also be used with the 1996 version of H.263, and it is recommended for that use by new implementations 🧚 It replaces the payload format in RFC 2190 [RFC2190], which some existing implementations still use, and it can be useful for backward compatibility. New implementations supporting H.263 SHALL use the payload format described in this document. RFC 2190 has been moved to historic status [RFC4628] 📜

The document updates the media type registration that was previously in RFC 3555 [RFC3555].

This document obsoletes RFC 2429 [RFC2429].

1.1. Terminology 💜

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] and indicate requirement levels for compliant RTP implementations 🫶

2. New H.263 Features 🌈

The 1998 version of ITU-T Recommendation H.263 added numerous coding options to improve codec performance over the 1996 version. In this document, the 1998 version is called H.263+ and the 2000 version is called H.263++ 🍓

Among the new options, the ones with the biggest impact on the RTP payload specification and the error resilience of the video content are the slice structured mode, the independent segment decoding mode, the reference picture selection mode, and the scalability mode. This section summarizes the impact of these new coding options on packetization. Refer to [H263] for more information on coding options 💅

The slice structured mode was added to H.263+ for three purposes: to provide enhanced error resilience capability, to make the bitstream more amenable for use with an underlying packet transport such as RTP, and to minimize video delay. The slice structured mode supports fragmentation at macroblock boundaries 🔥

With the independent segment decoding (ISD) option, a video picture frame is broken into segments and encoded in such a way that each segment is independently decodable. Using ISD in a lossy network environment helps to prevent the propagation of errors from one segment of the picture to others 🦋

The reference picture selection mode allows the use of an older reference picture rather than the one immediately preceding the current picture. Usually, the last transmitted frame is implicitly used as the reference picture for inter-frame prediction. If the reference picture selection mode is used, the data stream carries information on what reference frame should be used, indicated by the temporal reference as an ID for that reference frame. The reference picture selection mode may be used with or without a back channel, which provides information to the encoder about the internal status of the decoder. However, no special provision is made herein for carrying back channel information. The Extended RTP Profile for RTP Control Protocol (RTCP)-based Feedback [RFC4585] MAY be used as a back channel mechanism ✨

H.263+ also includes bitstream scalability as an optional coding mode. Three kinds of scalability are defined: temporal, signal-to-noise ratio (SNR), and spatial scalability. Temporal scalability is achieved via the disposable nature of bi-directionally predicted frames, or B-frames. (A low-delay form of temporal scalability known as P-picture temporal scalability can also be achieved by using the reference picture selection mode, described in the previous paragraph.) SNR scalability permits refinement of encoded video frames, thereby improving the quality (or SNR). Spatial scalability is similar to SNR scalability except that the refinement layer is twice the size of the base layer in the horizontal dimension, vertical dimension, or both 👑

H.263++ added some new functionalities. Among the new functionalities are support for interlace mode, specified in H.263, annex W.6.3.11, and the definition of profiles and levels in H.263 annex X 🌸

3. Usage of RTP 🧚

When transmitting H.263+ video streams over the Internet, the output of the encoder can be packetized directly. All the bits resulting from the bitstream (including the fixed length codes and variable length codes) will be included in the packet. The only exception is that when the payload of a packet begins with a Picture, GOB, Slice, End of Sequence (EOS), or End of Sub-Bit Stream (EOSBS) start code, the first 2 (all-zero) bytes of the start code shall be removed and replaced by setting an indicator bit in the payload header 🙈

For H.263+ bitstreams coded with temporal, spatial, or SNR scalability, each layer may be transported to a different network address. More specifically, each layer may use a unique IP address and port number combination. The temporal relations between layers shall be expressed using the RTP timestamp so that they can be synchronized at the receiving ends in multicast or unicast applications 🎀

The H.263+ video stream will be carried as payload data within RTP packets. A new H.263+ payload header is defined in Section 5; it updates the one specified in RFC 2190. This section defines the usage of the RTP fixed header and H.263+ video packet structure 💖

3.1. RTP Header Usage ✨

okay so every RTP packet starts with a fixed RTP header 💅 these are the fields from the fixed header that H.263+ video streams care about most, so let's zoom in on them 🔍

Marker bit (M bit): the M bit gets set to 1 when the current packet carries the end of the current frame, and it's 0 otherwise 🏁

Payload Type (PT): the RTP profile for a particular class of apps will assign a payload type for this encoding 🎀 and if that doesn't happen, the sender SHALL choose a payload type from the dynamic range 🫶

Timestamp: the RTP Timestamp encodes the sampling instance of the first video frame data in the packet 🕰️ the RTP timestamp SHALL be the same on successive packets if one video frame takes up more than one packet 🎞️ in a multilayer setup, all pictures with the same temporal reference SHOULD use the same timestamp 🌈 if temporal scalability is used (B-frames are present), the timestamp may not be monotonically increasing in the RTP stream 🙈 and if B-frames go out on a separate layer and address, they MUST be synchronized properly with the reference frames 🔥 for info on the required transmission order to a decoder, check ITU-T Recommendation H.263 [H263] 📚

for an H.263+ video stream, the RTP timestamp is based on a 90 kHz clock, same as the RTP payload for H.261 stream [RFC2032] ⏱️ and since both the H.263+ data and the RTP header carry timing info, that timing info MUST run in sync 💜 like, the RTP timestamp and the temporal reference (TR in the H.263 picture header) SHOULD carry the same relative timing information ✨

any H.263+ picture clock frequency can be written as 1800000/(cd*cf) source pictures per second, where cd is an integer from 1 to 127 and cf is either 1000 or 1001 🧮 so with the 90 kHz RTP clock, the time increment between each coded H.263+ picture SHOULD therefore be an integer multiple of (cd*cf)/20 🦋 for any "reasonable" picture clock frequency this will always come out as an integer (for example: 3003 for 30/1.001 Hz NTSC, 3600 for 25 Hz PAL, 3750 for 24 Hz film, and 1500, 1250, or 1200 for the computer display update rates of 60, 72, or 75 Hz, respectively) 🎬 for RTP packetization of hypothetical H.263+ bitstreams with "unreasonable" custom picture clock frequencies, mathematical rounding could become necessary to generate the RTP timestamps 🤓

3.2. Video Packet Structure 🧩

a section of an H.263+ compressed bitstream rides along as the payload in each RTP packet 🚗 so for each RTP packet you get the RTP header, then the H.263+ payload header, then a bunch of bytes from the standard H.263+ compressed bitstream 💖 the payload header's size is variable depending on the payload, as detailed in Section 4 📏 the layout of the RTP H.263+ video packet looks like this:

  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  :    RTP Header                                                 :
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  :    H.263+ Payload Header                                      :
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  :    H.263+ Compressed Data Stream                              :
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

any H.263+ start codes can be byte aligned by an encoder using the stuffing mechanisms of H.263+ 🧸 as specified in H.263+, picture, slice, and EOSBS start codes SHALL always be byte aligned, while GOB and EOS start codes MAY be byte aligned 🌸 for packetization purposes, GOB start codes SHOULD be byte aligned 🍓 but since that's not required in H.263+, there can be cases where GOB start codes aren't aligned, like when transmitting existing content or using H.263 encoders that don't support GOB start code alignment 🙃 in that case, Follow-on Packets (see Section 5.2) SHOULD be used for packetization 🧚

all H.263+ start codes (Picture, GOB, Slice, EOS, and EOSBS) begin with 16 zero-valued bits 0️⃣ if a start code is byte aligned and it shows up at the beginning of a packet, those two bytes SHALL be removed from the H.263+ compressed data stream during packetization 🪄 and they SHALL instead be represented by setting a bit (the P bit) in the payload header 🔥

4. Design Considerations 🎨

the goals of this payload format are to encapsulate an H.263+ standard compliant bitstream efficiently and to boost resiliency against packet losses 💪 because H.263+ has a huge number of possible coding schemes, a copy of the picture header with configuration info gets inserted into the payload header when it makes sense 📋 using that copy along with the payload data lets a received packet get decoded even if another packet with the original picture header gets lost 🫶

there are a few assumptions and constraints tied to this H.263+ payload header design 🧠 this section points out various design issues and also covers several H.263+ coding options that can affect how network-based H.263+ video performs 👑

  • the optional slice structured mode in Annex K of [H263] gives you way more flexibility for packetization ✨ it's similar to a picture segment that starts with a GOB header, since motion vector predictors in a slice are restricted to stay within its boundaries 🧩 but slices offer much more freedom in the size and shape of the area that's a distinct decodable region 🌈 slices can be sized dynamically so the data for each slice fits into a chosen packet size 📦 they can also be rectangular, which helps minimize the impact of errors and packet losses on motion-compensated prediction 🎯 so for these reasons, the slice structured mode is strongly recommended for any app running in environments where significant packet loss happens 🙌
  • in non-rectangular slice structured mode, only complete slices SHOULD be included in a packet 💅 in other words, slices SHOULD NOT be fragmented across packet boundaries 🚫 the only reasonable need for a slice to be fragmented across packet boundaries is when the encoder that generated the H.263+ data stream couldn't be influenced by any awareness of the packetization process (like when sending H.263+ data through a network other than the one the encoder is attached to, as in network gateway implementations) 🌉 ideally, each packet contains only one slice 🦋
  • the independent segment decoding (ISD) in Annex R of [H263] prevents any data dependency across slice or GOB boundaries in the reference picture 🛡️ it can be used to boost resiliency even more in high loss conditions 💥
  • if ISD is used together with the slice structure, the rectangular slice submode SHALL be enabled 🔲 and the dimensions and quantity of the slices in a frame SHALL remain the same between each two intra-coded frames (I-frames), as required in H.263+ 📐 the individual ISD segments MAY also be entirely intra coded from time to time for quick error recovery, without adding the latency of sending complete INTRA-pictures ⚡
  • when the slice structure isn't applied, inserting a (preferably byte-aligned) GOB header can provide resync boundaries in the bitstream 🔁 a GOB header removes the dependency of motion vector prediction across GOB boundaries, and these resync boundaries are natural spots for packet payload boundaries 🎀
  • H.263+ lets picture headers be sent in an abbreviated form to avoid repeating overhead info that doesn't change from picture to picture 🙈 for resiliency though, sending a complete picture header for every frame is often a good idea 💡 this means (especially when packet loss probability is high and picture header contents aren't expected to be very predictable) that the sender MAY find it advisable to always set the subfield UFEP in PLUSPTYPE to '001' in the H.263+ video bitstream 🫧 (see [H263] for the definitions of the UFEP and PLUSPTYPE fields 📖)
  • in a multi-layer scenario, each layer MAY be transmitted to a different network address 🛰️ the configuration of each layer, like the enhancement layer number (ELNUM), reference layer number (RLNUM), and scalability type, SHOULD be determined at the start of the session and SHOULD NOT change during the session 🔒
  • all start codes can be byte aligned, and picture, slice, and EOSBS start codes are always byte aligned 🧱 the boundaries of these syntactic elements are ideal spots for placing packet boundaries 🥰
  • we assume a maximum Picture Header size of 504 bits is sufficient 📏 H.263+ syntax doesn't explicitly prohibit larger picture header sizes, but extremely large picture headers aren't expected 🤷‍♀️

5. H.263+ Payload Header 🎀

for H.263+ video streams, each RTP packet SHALL carry only one H.263+ video packet 📦 the H.263+ payload header SHALL always be present for each H.263+ video packet 💖 it's variable length, which is a whole vibe 🌈 a 16-bit field of the general payload header (defined in 5.1) MAY be followed by an 8-bit field for Video Redundancy Coding (VRC) info, and/or by a variable-length extra picture header as indicated by PLEN 🧁 when present, these optional fields appear in the order given above 🫶

if an extra picture header is included in the payload header, its length in bytes is specified by PLEN 📐 the minimum length of the payload header is 16 bits, with PLEN equal to 0 and no VRC info present 🦋

the rest of this section defines the various components of the RTP payload header 💅 Section 6 defines the various packet types used to carry different kinds of H.263+ coded data, and Section 7 sums up how to tell the packet types apart 🔍

5.1. General H.263+ Payload Header ✨

okay so the H.263+ payload header is built like this, bestie 🎀

         0                   1
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |   RR    |P|V|   PLEN    |PEBIT|
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

RR: 5 bits 🌸

These are reserved bits. They SHALL be zero and MUST be ignored by receivers. Hands off, no cap 🙈

P: 1 bit 💖

This one tells you that a picture starts, or a picture segment (GOB/Slice) starts, or that a video sequence ends (EOS or EOSBS). Two bytes of zero bits then have to be stuck on the front of the payload to make a complete picture/GOB/slice/EOS/EOSBS start code. The bit lets you leave off those first two bytes of the start codes, which is lowkey a genius move because it improves the compression ratio 🔥

V: 1 bit 🦋

This bit says there's an 8-bit field for Video Redundancy Coding (VRC) right after the first 16 bits of the payload header, if it's there. The syntax and semantics for that 8-bit VRC field live in Section 5.2 ✨

PLEN: 6 bits 🧚

This is the length, in bytes, of the extra picture header. No extra picture header attached? Then PLEN is 0. If PLEN>0, the extra picture header sits right after the rest of the payload header. Also, the length already reflects leaving off the first two bytes of the picture start code (PSC), so keep that in mind 💅 See Section 6.1.

PEBIT: 3 bits 🍓

This one counts how many bits get ignored in the last byte of the picture header. If PLEN is not zero, the ignored bits are the least significant bits of that byte. If PLEN is zero, then PEBIT is also zero, periodt ✨

5.2. Video Redundancy Coding Header Extension 🦋

okay so Video Redundancy Coding (VRC) is an optional mechanism for better error resilience over packet networks. If you want to use VRC in H.263+, you'll need the Reference Picture Selection option from Annex N of [H263]. The big idea is having multiple "threads" of pictures that are each inter-frame predicted on their own. So if one frame gets damaged, the mess only stays inside its own thread, and the other threads are totally unaffected 🙌 Every so often, all the threads converge on a so-called sync frame (an INTRA picture, or a non-INTRA picture that's redundantly represented within multiple threads). After that sync frame, the independent threads start up again. For more on codec support for VRC, check [Vredun] 💜

P-picture temporal scalability is another use of the reference picture selection mode, and it's basically a special case of VRC where only one copy of each sync frame gets sent. It's a thread-based way to get temporal scalability without the extra delay that B pictures cause 😭 Here, the sync frames sent in the first thread of pictures are also used to predict a second thread of pictures that sit temporally between the sync frames, which bumps up the resulting frame rate ✨ The pictures in that second thread can be dropped to get a lower bit rate or less decoding complexity, and it won't hurt your ability to decode later pictures. You can also add a third or more threads, but each one is only predicted from the sync frames (which are sent at least in thread 0) or from frames inside the same thread 🎀

Now, a VRC data stream is totally self-contained (like all H.263+ data), but it can still help the transport hierarchy to know the current damage status of each thread. On the Internet, you can figure that out by looking at the marker bit, the sequence number of the RTP header, the thread-id, and a circling "packet per thread" number. The last two of those are coded in the VRC header extension 👑

Here's the format of the VRC header extension:

         0 1 2 3 4 5 6 7
        +-+-+-+-+-+-+-+-+
        | TID | Trun  |S|
        +-+-+-+-+-+-+-+-+

TID: 3 bits 🌈

This is the Thread ID, and up to 7 threads are allowed. Each frame of H.263+ VRC data only uses sync frames or frames from the same thread as reference information. By convention, thread 0 is the "canonical" thread, the one the sync frame should ideally come from. If thread 0 gets corrupted or lost, the decoder can use a representation of the sync frame from a higher thread number instead. Lower thread numbers are expected to hold representations of the sync frames that are equal to or better than the higher ones, as long as there's no corruption or loss. For a detailed VRC discussion, see [Vredun] 🧠

Trun: 4 bits 🔥

This is a monotonically increasing (modulo 16) 4-bit number that counts the packet number within each thread.

S: 1 bit 💅

This bit says the packet content is for a sync frame. An encoder using VRC can send several representations of the same "sync" picture, so that no matter which thread gets hit by errors or packet losses, at least one representation of that picture still arrives (inside at least one thread). The sync picture can then be used to predict any thread. If no packet losses happened, the sync frame contents of thread 0 can be used, and the ones from the other threads can be thrown out (and the same goes for the other threads). Thread 0 is the "canonical" thread, and it's the one you'd rather use over all the others. The contents of packets with lower thread numbers shall be considered as having a higher processing and delivery priority than those with higher thread numbers. So packets with lower thread numbers for a given sync frame shall be delivered first to the decoder under loss-free and low-time-jitter conditions, and that's what leads to discarding the sync contents of the higher-numbered threads, as specified in Annex N of [H263] 🦋

6. Packetization Schemes ✨

6.1. Picture Segment Packets and Sequence Ending Packets (P=1) 💖

A picture segment packet is a packet that starts at the location of a Picture, GOB, or slice start code in the H.263+ data stream. This matches the definition of the start of a video picture segment in H.263+. For these packets, P=1 always 🎀

Sometimes an extra picture header gets attached in the payload header of these packets. Whenever one is attached (signified by PLEN>0), only the last six bits of its picture start code, '100000', are included in the payload header. A complete H.263+ picture header with a byte-aligned picture start code can be easily put together on the receiving end by prepending the sixteen leading '0' bits 🧚

When PLEN>0, the end bit position for the last byte of the picture header data is marked by PEBIT. The actual bitstream data shall begin on an 8-bit byte boundary following the payload header 🌸

A sequence ending packet is a packet that starts at the location of an EOS or EOSBS code in the H.263+ data stream. It marks the end of a sequence of H.263+ video data (though more H.263+ video data may still follow later, as specified in ITU-T Recommendation H.263) 😭 For these packets, P=1 and PLEN=0 always.

The optional header extension for VRC may or may not be present, as shown by the V bit flag 💜

6.1.1. Packets that begin with a Picture Start Code 🍓

Any packet that contains the whole or the start of a coded picture shall start at the location of the picture start code (PSC), and it should normally be encapsulated with no extra copy of the picture header. In other words, normally PLEN=0 in that case. But if the coded picture has an incomplete picture header (UFEP = "000"), then a representation of the complete (UFEP = "001") picture header may be attached during packetization for extra error resilience 🛡️ So for packets that start at the location of a picture start code, PLEN shall be zero unless both of these conditions apply:

  1. The picture header in the H.263+ bitstream payload is incomplete (PLUSPTYPE present and UFEP="000").
  2. The additional picture header that's attached is not incomplete (UFEP="001").

A packet that begins at the location of a Picture, GOB, slice, EOS, or EOSBS start code shall omit the first two (all zero) bytes from the H.263+ bitstream, and signify their presence by setting P=1 in the payload header ✨

Here's an example of encapsulating the first packet in a frame (without an attached redundant complete picture header):

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   RR    |1|V|0|0|0|0|0|0|0|0|0| bitstream data without the    :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     : first two 0 bytes of the PSC
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

6.1.2. Packets that begin with GBSC or SSC 🦋

For a packet that begins at the location of a GOB or slice start code (GBSC), PLEN may be zero or nonzero, depending on whether a redundant picture header is attached to the packet. In environments with very low packet loss rates, or when the picture header contents are very unlikely to change (except as can be detected from the GOB Frame ID (GFID) syntax of H.263+), a redundant copy of the picture header isn't required 💖 But in less ideal situations, a redundant picture header should be attached for enhanced error resilience, and its presence is shown by PLEN>0 🔥

Assuming a PLEN of 9 and P=1, here's an example of a packet that begins with a byte-aligned GBSC or a Slice Start Code (SSC):

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   RR    |1|V|0 0 1 0 0 1|PEBIT|1 0 0 0 0 0| picture header    :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       : starting with TR, PTYPE ...                                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | ...                                           | bitstream     :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       : data starting with GBSC/SSC without its first two 0 bytes
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Notice that only the last six bits of the picture start code, '100000', are included in the payload header. A complete H.263+ picture header with a byte-aligned picture start code can be easily assembled on the receiving end, if needed, by prepending the sixteen leading '0' bits 🌈

6.1.3. Packets that begin with an EOS or EOSBS Code 🧚

okay so when a packet starts with an EOS or EOSBS code, PLEN SHALL be zero 🎀 and no Picture, GOB, or Slice start codes SHALL be included in that same packet. Like with the other packets that begin with start codes, the two all-zero bytes at the front of the EOS or EOSBS code SHALL be omitted, and their presence SHALL be indicated by setting the P bit to 1 in the payload header. bestie, that's the whole rule 💅

System designers SHOULD be aware that some decoders might think a lost packet containing only EOS or EOSBS info is a loss of important video data 😭 so they could stop displaying some of the video that comes after. Here's the tea: EOS and EOSBS codes don't actually change how the pictures get decoded, so they're kinda unnecessary to send at all 🙈 Because of that risk of misreading a lost packet (you can spot the loss with the sequence number), encoders are generally to be discouraged from sending EOS and EOSBS. Not a vibe 💀

Here's an example of a packet containing an EOS code:

      0                   1                   2
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   RR    |1|V|0|0|0|0|0|0|0|0|0|1|1|1|1|1|1|0|0|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

6.2. Encapsulating Follow-on Packet (P=0) 🦋

6.2. Encapsulating Follow-on Packet (P=0) 🦋

okay so a Follow-on Packet holds some bytes of coded H.263+ data that DON'T start at a sync point 🌸 It doesn't start with a Picture, GOB, Slice, EOS, or EOSBS header, and it might or might not start on a macroblock boundary. Since it's not at a sync point, the data at the front of a Follow-on Packet can't be decoded on its own. For these packets, P=0 always. If the packet right before a Follow-on Packet got lost, the receiver may toss that Follow-on Packet, plus all the other Follow-on Packets after it. Lowkey harsh, but valid 😭

Better behavior would be for the receiver to scan inside the payload to see if there are any start codes it can use as resync points ✨ Attaching a copy of a picture header to a Follow-on Packet is only useful if the inside of the packet, or some later Follow-on Packet, has a resync code like a GOB or slice start code. PLEN>0 is allowed, since it might let the decoder resync partway through the packet 🙌 The decoder can also resync at the next segment or picture packet.

Here's an example of a Follow-on Packet (with PLEN=0):

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
  |   RR    |0|V|0|0|0|0|0|0|0|0|0| bitstream data
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

7. Use of this Payload Specification 💜

There's zero syntactical difference between a picture segment packet and a Follow-on Packet 🙈 The only difference is the P bit: P=1 for picture segment or sequence ending packets, and P=0 for Follow-on Packets. Here's a summary of all the packet types and how to tell them apart.

You can tell the packet types apart by checking the P bit and the first 6 bits of the payload, along with the header info 👑 The table below shows the packet type for each combo (also check the picture/GOB/Slice header descriptions in H.263+ for the details):

-------------+--------------+----------------------+----------------
First 6 bits | P-Bit | PLEN |  Packet              |  Remarks
of Payload   |(payload hdr.)|                      |
-------------+--------------+----------------------+----------------
100000       |   1   |  0   |  Picture             | Typical Picture
100000       |   1   | > 0  |  Picture             | Note UFEP
1xxxxx       |   1   |  0   |  GOB/Slice/EOS/EOSBS | See possible GNs
1xxxxx       |   1   | > 0  |  GOB/Slice           | See possible GNs
Xxxxxx       |   0   |  0   |  Follow-on           |
Xxxxxx       |   0   | > 0  |  Follow-on           | Interior Resync
-------------+--------------+----------------------+----------------

The details on the possible values of the five bit Group Number (GN) field (the one right after the initial "1" bit when the P-bit is "1" for a GOB, Slice, EOS, or EOSBS packet) are in Section 5.2.3 of H.263 [H263]. Slay the details 🎀

As defined in this spec, every start of a coded frame (you'll know it by the PSC) HAS to be wrapped up as a picture segment packet 🍓 If the whole coded picture fits in one packet of reasonable size (which depends on the connection), that's the only packet type you might need. Thanks to the high compression ratio of H.263+, that's often possible, especially for small picture formats like Quarter Common Intermediate Format (QCIF) and typical Internet packet sizes around 1500 bytes. Iconic efficiency 🔥

If the complete coded frame doesn't fit in a single packet, there are two ways to packetize it 🌈 If the packet loss probability is very low or zero, you can use one or more Follow-on Packets for the rest of the picture. That gives minimal coding and packetization overhead, plus an optimal use of the maximal packet size, but it doesn't add any error resilience.

The other option is to break the picture into reasonably small partitions called Segments (using the Slice or GOB mechanism). Those give you synchronization points ✨ With that and the Picture Segment payload using PLEN>0, the transmitted packets can still be decoded even if the Picture packet with the picture header got lost (as long as any needed reference picture is available) 🫶 Picture Segment packets can also be paired with Follow-on Packets for large segment sizes.

8. Media Type Definition 🌸

This section spells out optional parameters that MAY be used to pick optional features of the H.263 codec 💖 The parameters are part of the Media Type registration for the ITU-T H.263 codec. There's also a mapping of the parameters into the Session Description Protocol (SDP) [RFC4566] for apps that use SDP. When you have multiple parameters, they SHOULD be written as a media type string: a semicolon-separated list of parameter=value pairs. Clean ✨

8.1. Media Type Registrations 🦋

This section describes the media types and names tied to this payload format 🧚 It updates the previous registered version in RFC 3555 [RFC3555]. Main character update 👑

8.1.1. Registration of Media Type video/H263-1998 💖

Type name: video 🎀

Subtype name: H263-1998 🌸

Required parameters: None ✨

Optional parameters:

OK so this is the big one, bestie. The optional parameters are where all the good stuff lives 🧚

SQCIF: Specifies the MPI (Minimum Picture Interval) for SQCIF resolution. Permissible values are integer values from 1 to 32, which correspond to a maximum frame rate of 30/(1.001 * the specified value) frames per second.

QCIF: Specifies the MPI (Minimum Picture Interval) for QCIF resolution. Permissible values are integer values from 1 to 32, which correspond to a maximum frame rate of 30/(1.001 * the specified value) frames per second.

CIF: Specifies the MPI (Minimum Picture Interval) for CIF resolution. Permissible values are integer values from 1 to 32, which correspond to a maximum frame rate of 30/(1.001 * the specified value) frames per second.

CIF4: Specifies the MPI (Minimum Picture Interval) for 4CIF resolution. Permissible values are integer values from 1 to 32, which correspond to a maximum frame rate of 30/(1.001 * the specified value) frames per second.

CIF16: Specifies the MPI (Minimum Picture Interval) for 16CIF resolution. Permissible values are integer values from 1 to 32, which correspond to a maximum frame rate of 30/(1.001 * the specified value) frames per second.

CUSTOM: Specifies the MPI (Minimum Picture Interval) for a custom-defined resolution. The custom parameter receives three comma-separated values, Xmax, Ymax, and MPI. The Xmax and Ymax parameters describe the number of pixels in the X and Y axis and must be evenly divisible by 4. The permissible values for MPI are integer values from 1 to 32, which correspond to a maximum frame rate of 30/(1.001 *the specified value).

A system that declares support of a specific MPI for one of the resolutions SHALL also implicitly support a lower resolution with the same MPI. 🔥

A list of optional annexes specifies which annexes of H.263 are supported. The optional annexes are defined as part of H263-1998, H263-2000. H.263 annex X [H263] defines profiles that group annexes for specific applications. A system that supports a specific annex SHALL specify its support using the optional parameters. If no annex is specified, then the stream is Baseline H.263. 🦋

The allowed optional parameters for the annexes are "F", "I", "J", "T", "K", "N", and "P". 🌈

"F", "I", "J", and "T" if supported, SHALL have the value "1". If not supported, they should not be listed or SHALL have the value "0". 💅

"K" can receive one of four values 1 - 4:

  • 1: Slices In Order, Non-Rectangular
  • 2: Slices In Order, Rectangular
  • 3: Slices Not Ordered, Non-Rectangular
  • 4: Slices Not Ordered, Rectangular

"N": Reference Picture Selection mode. Four numeric choices (1 - 4) are available, representing the following modes:

  • 1: NEITHER: No back-channel data is returned from the decoder to the encoder.
  • 2: ACK: The decoder returns only acknowledgment messages.
  • 3: NACK: The decoder returns only non-acknowledgment messages.
  • 4: ACK+NACK: The decoder returns both acknowledgment and non-acknowledgment messages.

No special provision is made herein for carrying back channel information. The Extended RTP Profile for RTCP-based Feedback [RFC4585] MAY be used as a back channel mechanism. 👑

"P": Reference Picture Resampling, in which the following submodes are represented as a number from 1 to 4:

  • 1: dynamicPictureResizingByFour
  • 2: dynamicPictureResizingBySixteenthPel
  • 3: dynamicWarpingHalfPel
  • 4: dynamicWarpingSixteenthPel

Example: P=1,3 ✨

PAR: Arbitrary Pixel Aspect Ratio. Defines the width:height ratio by two colon-separated integers between 0 and 255. Default ratio is 12:11, if not otherwise specified. 🍓

CPCF: Arbitrary (Custom) Picture Clock Frequency. CPCF is a comma-separated list of eight parameters specifying a custom picture clock frequency and the MPI (minimum picture interval) for the supported picture sizes when using that picture clock frequency. The first two parameters are cd, which is an integer from 1 to 127, and cf, which is either 1000 or 1001. The custom picture clock frequency is given by the formula 1800000/(cd*cf) provided in the RTP Timestamp semantics in Section 3.1 above (as specified in H.263 section 5.1.7). Following the values of cd and cf, the remaining six parameters are SQCIFMPI, QCIFMPI, CIFMPI, CIF4MPI, CIF16MPI, and CUSTOMMPI, which each specify an integer MPI (minimum picture interval) for the standard picture sizes SQCIF, QCIF, CIF, 4CIF, 16CIF, and CUSTOM, respectively, as described above. The MPI value indicates a maximum frame rate of 1800000/(cd*cf*MPI) frames per second for MPI parameters having a value in the range from 1 to 2048, inclusive. An MPI value of 0 specifies that the associated picture size is not supported for the custom picture clock frequency. If the CUSTOMMPI parameter is not equal to 0, the CUSTOM parameter SHALL also be present (so that the Xmax and Ymax dimensions of the custom picture size are defined). 🌸

BPP: BitsPerPictureMaxKb. Maximum number of bits in units of 1024 bits allowed to represent a single picture. If this parameter is not present, then the default value, based on the maximum supported resolution, is used. BPP is integer value between 0 and 65536. 🧚

HRD: Hypothetical Reference Decoder. See annex B of H.263 specification [H263]. This parameter, if supported, SHALL have the value "1". If not supported, it should not be listed or SHALL have the value "0". 💜

Encoding considerations:

This media type is framed and binary; see Section 4.8 in [RFC4288]. 📦

Security considerations: See Section 11 of RFC 4629. 🔐

Interoperability considerations:

These are receiver options; current implementations will not send any optional parameters in their SDP. They will ignore the optional parameters and will encode the H.263 stream without any of the annexes. Most decoders support at least QCIF and CIF fixed resolutions, and they are expected to be available almost in every H.263-based video application. 🫶

Published specification: RFC 4629 📚

Applications that use this media type:

Audio and video streaming and conferencing tools. 🎥

Additional information: None

Person and email address to contact for further information:

Roni Even: roni.even@polycom.co.il 💌

Intended usage: COMMON

Restrictions on usage:

This media type depends on RTP framing and thus is only defined for transfer via RTP [RFC3550]. Transport within other framing protocols is not defined at this time. 🚫

Author: Roni Even 🙌

Change controller:

IETF Audio/Video Transport working group, delegated from the IESG. 🏛️

8.1.2. Registration of Media Type video/H263-2000 🌷

Type name: video 🎀

Subtype name: H263-2000 🌸

Required parameters: None ✨

Optional parameters:

The optional parameters of the H263-1998 type MAY be used with this media subtype. Specific optional parameters that may be used with the H263-2000 type are as follows: 🦋

PROFILE: H.263 profile number, in the range 0 through 10, specifying the supported H.263 annexes/subparts based on H.263 annex X [H263]. The annexes supported in each profile are listed in table X.1 of H.263 annex X. If no profile or H.263 annex is specified, then the stream is Baseline H.263 (profile 0 of H.263 annex X). 🌈

LEVEL: Level of bitstream operation, in the range 0 through 100, specifying the level of computational complexity of the decoding process. The level are described in table X.2 of H.263 annex X. 💅

According to H.263 annex X, support of any level other than level 45 implies support of all lower levels. Support of level 45 implies support of level 10. 🧠

A system that specifies support of a PROFILE MUST specify the supported LEVEL. 🔥

INTERLACE: Interlaced or 60 fields indicates the support for interlace display mode, as specified in H.263 annex W.6.3.11. This parameter, if supported SHALL have the value "1". If not supported, it should not be listed or SHALL have the value "0". 👑

Encoding considerations:

This media type is framed and binary; see Section 4.8 in [RFC4288]. 📦

Security considerations: See Section 11 of RFC 4629

Interoperability considerations:

The optional parameters PROFILE and LEVEL SHALL NOT be used with any of the other optional parameters. 🙅‍♀️

Published specification: RFC 4629 📚

Applications that use this media type:

Audio and video streaming and conferencing tools. 🎥

Additional information: None

Person and email address to contact for further information :

Roni Even: roni.even@polycom.co.il 💌

Intended usage: COMMON

Restrictions on usage:

This media type depends on RTP framing and thus is only defined for transfer via RTP [RFC3550]. Transport within other framing protocols is not defined at this time. 🚫

Author: Roni Even 🙌

Change controller:

IETF Audio/Video Transport working group delegated from the IESG. 🏛️

8.2. SDP Usage 🎶

The media types video/H263-1998 and video/H263-2000 are mapped to fields in the Session Description Protocol (SDP) as follows:

  • The media name in the "m=" line of SDP MUST be video. 🎬
  • The encoding name in the "a=rtpmap" line of SDP MUST be H263-1998 or H263-2000 (the media subtype). 🏷️
  • The clock rate in the "a=rtpmap" line MUST be 90000. ⏰
  • The optional parameters, if any, MUST be included in the "a=fmtp" line of SDP. These parameters are expressed as a media type string, in the form of a semicolon-separated list of parameter=value pairs. The optional parameters PROFILE and LEVEL SHALL NOT be used with any of the other optional parameters. 🧁

8.2.1. Usage with the SDP Offer Answer Model ✨

okay so if you wanna offer H.263 over RTP using SDP in an Offer/Answer model [RFC3264], there are a few things you need to keep in mind 💅

Codec options (F,I,J,K,N,P,T): these options MUST NOT appear unless the sender of these SDP parameters can actually decode them 🙅‍♀️ and they describe what the receiver can handle even when they show up in a "sendonly" offer 👀

Profile: offering the profile parameter basically says "I can decode a stream that uses this profile" 🦋 each profile uses different H.263 annexes, so there's no implied relationship between them (no one-size-fits-all lol). An answerer SHALL NOT change the profile parameter, and it MUST reject the payload type that has a profile it doesn't support. A decoder that supports a profile SHALL also support H.263 baseline profile (profile 0). An offerer is RECOMMENDED to offer each profile it's interested in as its own payload type. And if an offerer sends an offer using the PROFILE optional parameter, it is RECOMMENDED to offer profile 0 too 🌸 that's what makes communication work, and it lets the answerer add whichever profiles it supports in the answer.

LEVEL: the LEVEL parameter in an offer shows the maximum computational complexity the offerer can handle when decoding for the given PROFILE 🧠 an answerer MAY change the value (both up and down) of LEVEL in its answer to show the highest value it supports ⭐

INTERLACE: this one MAY be included in either the offer or the answer to say that the offerer or answerer can receive interlaced content 🎀 whether it shows up in the offer or the answer doesn't depend on the other one.

Picture sizes and MPI: supported picture sizes and their minimum picture interval (MPI) info can be combined 🍓 you can advertise all the picture sizes or just a subset. The terminal only announces the sizes (with their MPIs) that it's actually willing to receive. For example, MPI=2 means the max decodable picture rate per second is 15/1.001 (approximately 14.985) 🧚

If the receiver doesn't specify the picture size/MPI optional parameter, it SHOULD be ready to receive QCIF resolution with MPI=1 🌈

Parameters offered first are the most preferred picture mode to be received 👑 here's an example:

CIF=4;QCIF=3;SQCIF=2;CUSTOM=360,240,2

so basically the encoder SHOULD send CIF picture size (which it can decode at MPI=4). If that's not possible, QCIF with MPI value 3 should be sent. If neither works, go with SQCIF with MPI value=2. The receiver can decode custom picture sizes (max 360x240) at MPI=2, but that's the least preferred option 💀 and fun fact: most decoders support at least QCIF and CIF fixed resolutions, and they're expected to be available in almost every H.263-based video application 💖

Here's an H.263 SDP example in an offer:

a=fmtp:xx CIF=4;QCIF=2;F=1;K=1

this means the sender can decode an H.263 bit stream with these options and parameters: the preferred resolution is CIF (at up to 30/4.004 frames per second), but if that's not possible, QCIF is also supported (at up to 30/2.002 frames per second) 🦋 and the Advanced Prediction mode (AP) and slicesInOrder-NonRect options MAY be used.

Now here's an offer that includes the CPCF parameter:

a=fmtp:xx CPCF=36,1000,0,1,1,0,0,2;CUSTOM=640,480,2;CIF=1;QCIF=1

this means the sender can decode an H.263 bit stream with a preferred custom picture size of 640x480 at a max frame rate of 25 frames per second, using a custom picture clock frequency of 50 Hz 🔥 if that's not possible, the 640x480 picture size is also supported at up to 30/2.002 frames per second using the ordinary picture clock frequency of 30/1.001 Hz. If neither of those works, then the CIF and QCIF picture sizes are also supported at up to 50 frames per second using the custom picture clock frequency of 50 Hz, or up to 30/1.001 frames per second using the ordinary picture clock frequency of 30/1.001 Hz, and CIF is preferred over QCIF 🫶

one more limitation for multicast: when you're doing offer/answer for sessions using multicast transport, an answerer SHALL NOT change any of the parameters in an answer. Instead, if the indicated values aren't supported, the payload type MUST be rejected 🚫

9. Backward Compatibility to RFC 2429 ✨

this document is a revision of RFC 2429 and it obsoletes it 🍓 this section covers the backward compatibility issues.

9.1. New Optional Parameters for SDP

this document adds new optional parameters to the H263-1998 and H263-2000 payload types, which are defined in RFC 3555 [RFC3555] 🎀 since they're optional, we expect old implementations to just ignore them. And new implementations that receive the H263-1998 and H263-2000 payload types with no parameters will act as if the other side can accept H.263 at QCIF resolution at a frame rate not exceeding 15/1.001 (approximately 14.985) frames per second 🌸

10. IANA Considerations 📋

this document updates the H.263 (1998) and H.263 (2000) media types, which are described in RFC 3555 [RFC3555]. The updated media type registrations are in Section 8.1 💖

11. Security Considerations 🔐

RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [RFC3550] and any appropriate RTP profile (for example, [RFC3551]). This means confidentiality of the media streams is achieved by encryption. Because the data compression used with this payload format is applied end-to-end, encryption may be performed after compression, so there's no conflict between the two operations 🔒

⚠️ a potential denial-of-service threat exists for data encoding that uses compression techniques with non-uniform receiver-end computational load. An attacker can inject pathological datagrams into the stream that are complex to decode and overload the receiver 😭 the usage of authentication of at least the RTP packet is RECOMMENDED. Please don't skip this one bestie 🫠

As with any IP-based protocol, in some circumstances a receiver may be overloaded simply by receiving too many packets, whether they're desired or undesired. Network-layer authentication may be used to discard packets from undesired sources, but the processing cost of the authentication itself may be too high 💀 In a multicast environment, pruning of specific sources may be implemented in future versions of IGMP [RFC2032] and in multicast routing protocols, so a receiver can select which sources are allowed to reach it 🌈

A security review of this payload format found no additional considerations beyond those in the RTP specification ✅

12. Acknowledgements 🙌

big thank yous to Chad Zhu, Linda Cline, Gim Deisher, Tom Gardos, Christian Maciocco, and Donald Newell from Intel Corp., who co-authored RFC 2429 💜

We'd also like to shout out Petri Koskelainen from Nokia and Nermeen Ismail from Cisco, who helped compose the text for the new media types 🫶

13. Changes from Previous Versions of the Documents 🦋

13.1. Changes from RFC 2429

the changes from RFC 2429 are:

  1. The H.263 1998 and 2000 media types are now in the payload specification.
  2. Optional parameters were added to the H.263 1998 and 2000 media types.
  3. Mandate the usage of RFC 2429 for all H.263. RFC 2190 payload format should be used only to interact with legacy systems 🧸

13.2. Changes from RFC 3555

this document adds new optional parameters to the H263-1998 and H263-2000 payload types ✨

14. References 📚

14.1. Normative References

  • [H263] International Telecommunications Union - Telecommunication Standardization Sector, "Video coding for low bit rate communication", ITU-T Recommendation H.263, January 2005.
  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
  • [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
  • [RFC3555] Casner, S. and P. Hoschka, "MIME Type Registration of RTP Payload Formats", RFC 3555, July 2003.
  • [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.

14.2. Informative References

  • [RFC2032] Turletti, T., "RTP Payload Format for H.261 Video Streams", RFC 2032, October 1996.
  • [RFC2190] Zhu, C., "RTP Payload Format for H.263 Video Streams", RFC 2190, September 1997.
  • [RFC2429] Bormann, C., Cline, L., Deisher, G., Gardos, T., Maciocco, C., Newell, D., Ott, J., Sullivan, G., Wenger, S., and C. Zhu, "RTP Payload Format for the 1998 Version of ITU-T Rec. H.263 Video (H.263+)", RFC 2429, October 1998.
  • [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
  • [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
  • [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2006.
  • [RFC4628] Even, R., "RTP Payload Format for H.263 Moving RFC 2190 to Historic Status", RFC 4628, January 2007.
  • [Vredun] Wenger, S., "Video Redundancy Coding in H.263+", Proc. Audio-Visual Services over Packet Networks, Aberdeen, U.K. 9/1997, September 1997.

Authors' Addresses 🌷

Joerg Ott
Helsinki University of Technology
Networking Laboratory
PO Box 3000
02015 TKK, Finland

EMail: jo@netlab.tkk.fi


Carsten Bormann
Universitaet Bremen TZI
Postfach 330440
D-28334 Bremen, GERMANY

Phone: +49.421.218-7024
Fax: +49.421.218-7000
EMail: cabo@tzi.org


Gary Sullivan
Microsoft Corp.
One Microsoft Way
Redmond, WA 98052
USA

EMail: garysull@microsoft.com


Stephan Wenger
Nokia Research Center
P.O. Box 100
33721 Tampere
Finland

EMail: stewe@stewe.org


Roni Even (editor)
Polycom
94 Derech Em Hamoshavot
Petach Tikva  49130
Israel

EMail: roni.even@polycom.co.il

Copyright (C) The IETF Trust (2007).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.

Intellectual Property ✨

okay so this part is the legal-ish bit, but it's important bestie 🫶 The IETF takes no position on whether any Intellectual Property Rights or other rights might apply to building or using the tech in this doc, or whether any license for them exists or doesn't. It also doesn't claim it went looking for those rights itself 🙈 If you want the details on how rights work for RFC documents, check out BCP 78 and BCP 79 💅

IPR disclosures sent to the IETF Secretariat, any licence assurances, and the results of attempts to get a general license or permission for implementers or users of this spec can all be found in the IETF online IPR repository at http://www.ietf.org/ipr 🔗

The IETF also invites anyone to tell it about copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org 📬

Acknowledgement

and last but not least, the RFC Editor function is currently funded by the Internet Society 🌈 Thank you for the support, Internet Society 💖

📦 where this page comes from