RFC 6469

RTP Payload Format for DV (IEC 61834) Video

📅 published December 2011, from ietf

RFC 6469: RTP Payload Format for DV (IEC 61834) Video 🎀

Okay bestie, so this is RFC 6469 💖 It's called RTP Payload Format for DV (IEC 61834) Video, and it's a Standards Track doc from December 2011 (ISSN 2070-1721). It's written by K. Kobayashi (AICS, RIKEN), K. Mishima (Keio University), S. Casner (Packet Design), and C. Bormann (Universitaet Bremen TZI) 🧚 It obsoletes RFC 3189, so this one is the new and improved version, periodt 💅

Abstract 🌸

Okay so the whole point of this doc is the packetization scheme for taking the compressed digital video streams people call "DV" and wrapping them up as a payload format for the Real-Time Transport Protocol (RTP) 🎬 It also says straight up that it obsoletes RFC 3189, so no cap, this is the one to read.

Status of This Memo 📜

This is an Internet Standards Track document 🔥

It's a product of the Internet Engineering Task Force (IETF) and it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check out Section 2 of RFC 5741 🦋

For the current status of this doc, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc6469 ✨

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved 💜

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, which you can find at http://trustee.ietf.org/license-info, as they stand on the date this document was published. Please actually read these, because they spell out your rights and restrictions for this document. Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License 🌈

This doc might include material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008. The person or people controlling the copyright in some of that material might not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. So without an adequate license from whoever controls the copyright in those materials, this document must not be modified outside the IETF Standards Process, and derivative works of it must not be created outside the IETF Standards Process. The one exceptions are formatting it for publication as an RFC or translating it into languages other than English 🙈

Table of Contents 🗂️

   1. Introduction ....................................................3
      1.1. Terminology ................................................4
   2. RTP Payload Format ..............................................4
      2.1. The DV Format Encoding .....................................4
      2.2. RTP Header Usage ...........................................5
      2.3. Payload Structures .........................................6
   3. Payload Format Parameters .......................................7
      3.1. Media Type Registration ....................................7
           3.1.1. Media Type Registration for DV Video ................8
           3.1.2. Media Type Registration for DV Audio ................9
      3.2. SDP Parameters ............................................11
           3.2.1. Mapping of Payload Type Parameters to SDP ..........11
           3.2.2. Usage with the SDP Offer/Answer Model ..............12
      3.3. Examples ..................................................12
           3.3.1. Example for Unbundled Streams ......................13
           3.3.2. Example for Bundled Streams ........................13
   4. Security Considerations ........................................14
   5. Congestion Control .............................................14
   6. IANA Considerations ............................................14
   7. Major Changes from RFC 3189 ....................................15
   8. Interoperability with Previous Implementations .................15
   9. Acknowledgment .................................................16
   10. References ....................................................16
      10.1. Normative References .....................................16
      10.2. Informative References ...................................17

1. Introduction ✨

Okay so this spec is all about wrapping up both consumer and professional Digital Video (DV) data streams for the Real-Time Transport Protocol (RTP) [RFC3550] 🎞️ DV compression for audio and video was designed for recording onto helical-scan magnetic tape 📼

The DV standards for consumer devices are the IEC 61883 and 61834 series. They cover a ton of stuff: the mechanical specs of a cassette, the magnetic recording format, error correction on the tape, the Discrete Cosine Transform (DCT) video encoding format, and the audio encoding format [IEC61834]. The digital interface part of IEC 61883 defines an interface on the IEEE 1394 system [IEC61883][IEEE1394]. This spec set supports several video formats: SD-VCR (Standard Definition), HD-VCR (High Definition), SDL-VCR (Standard Definition - Long), PALPlus, DVB (Digital Video Broadcast), and ATV (Advanced Television). North American formats are marked with a number of lines and /60, while European formats use /50 🌍

Professional DV got extended by the Society of Motion Picture and Television Engineers (SMPTE) as 314M and 370M, for different sampling systems, higher color resolution, and higher bit rates [SMPTE314M][SMPTE370M] 💅

So basically there are two kinds of DV: one for consumers and one for pros 👑 The original consumer "DV" spec, made for consumer digital VCRs, got approved as the IEC 61834 standard set. The professional specs are published as SMPTE 314M and 370M. Both encoding formats are based on consumer DV and get used in SMPTE D-7, D-9, and D-12 video systems. The RTP payload format in this spec supports IEC 61834 consumer DV and professional SMPTE 314M and 370M (DV-based) formats 🦋

IEC 61834 also covers magnetic tape recording for digital TV broadcasting systems (like DVB and ATV) that use MPEG2 encoding. The payload format for putting MPEG2 into RTP is already defined in RFC 2250 [RFC2250] and elsewhere 🧚

So the payload in this doc will support six video formats from the IEC standard: SD-VCR (525/60, 625/50), HD-VCR (1125/60, 1250/50), and SDL-VCR (525/60, 625/50). It also supports eight SMPTE standards: 314M 25 Mbit/s (525/60, 625/50), 314M 50 Mbit/s (525/60, 625/50), and 370M 100 Mbit/s (1080/60i, 1080/50i, 720/60p, and 720/50p) 🌈 Later on, it can be extended into other video formats managed by the 80-byte DV Digital Interface Format (DIF) block ⭐

Quick heads up: this spec uses a ton of IEC and SMPTE terminology. For what those terms actually mean, go to the original references 📚

1.1. Terminology 🔑

Here's the important bit: when this doc says "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL", those are the official key words, and they get interpreted as described in RFC 2119 [RFC2119] 🙌

2. RTP Payload Format 🎀

2.1. The DV Format Encoding 🍓

DV only uses DCT compression within each frame. That's different from the interframe compression used by the MPEG video standards [ISO/IEC11172][ISO/IEC13818]. All video data, including audio and other system data, gets managed within the picture frame unit of video 🎥

The DV video encoding has a three-level hierarchy: DCT super block, DCT macro block, and DCT block. A picture frame is split into rectangle- or clipped-rectangle-shaped DCT super blocks. Those DCT super blocks get divided into 27 rectangle- or square-shaped DCT macro blocks, and each DCT macro block is made of a bunch of DCT blocks. Each DCT block is 8x8 pixels and represents a rectangle region for each color: Y, Cb, and Cr 💜

Audio is encoded in Pulse Code Modulation (PCM) format. The sampling frequency is 32 kHz, 44.1 kHz, or 48 kHz, and the quantization is 12-bit non-linear, 16-bit linear, or 20-bit linear. The number of channels may be up to 8. Only certain combos of these parameters are allowed, depending on the video format, and the restrictions are specified in each document [IEC61834][SMPTE314M][SMPTE370M] 🔊

A frame of data in the DV format stream is split into several "DIF sequences". Each DIF sequence is made of an integral number of 80-byte DIF blocks. The DIF block is the primitive unit for all treatment of DV streams, so it's a big deal ✨ Each DIF block has a 3-byte ID header that says what type of DIF block it is and where it sits in the DIF sequence. Five types of DIF blocks are defined:

  • DIF sequence header
  • Subcode
  • Video Auxiliary (VAUX) information
  • Audio
  • Video

Audio DIF blocks are made of 5 bytes of Audio Auxiliary (AAUX) data and 72 bytes of audio data 🧁

Last but not least, each RTP packet starts with the RTP header as defined in RFC 3550 [RFC3550]. No additional payload-format-specific header is required for this payload format 🌸

2.2. RTP Header Usage ✨

okay bestie, let's see how the RTP header fields get a DV-specific meaning 🎀

Payload type (PT): the payload type is dynamically assigned by means outside the scope of this document 🦋 If you want multiple DV encoding formats in one RTP session, then multiple dynamic payload types MUST be assigned, one for each DV encoding format. The sender MUST change to the corresponding payload type whenever the encoding format changes.

Timestamp: this is a 32-bit 90 kHz timestamp that shows when the first data in the frame was sampled ⏰ All RTP packets within the same video frame MUST have the same timestamp. The timestamp SHOULD increase by a multiple of the nominal interval for one DV frame time, as given in this table:

+----------+----------------+---------------------------------------+
|   Mode   |   Frame rate   |  Increase of 90 kHz timestamp per DV  |
|          |      (Hz)      |                 frame                 |
+----------+----------------+---------------------------------------+
|  525-60  |      29.97     |                  3003                 |
|  625-50  |       25       |                  3600                 |
|  1125-60 |       30       |                  3000                 |
|  1250-50 |       25       |                  3600                 |
| 1080-60i |      29.97     |                  3003                 |
| 1080-50i |       25       |                  3600                 |
|  720-60p |      59.94     |                3003(*)                |
|  720-50p |       50       |                3600(*)                |
+----------+----------------+---------------------------------------+

(*) Heads up, this one's a bit of a plot twist 👀 Even in the 720-line DV system, the data in two video frames shall be processed within one DV frame duration of the 1080-line system. Audio data and subcode data in the 720-line system are processed the same way as in the 1080-line system. So in the 720-line system, the timestamp increase in the third column corresponds to two video frames' worth of time.

Marker bit (M): the marker bit of the RTP fixed header is set to one on the last packet of a video frame. On other packets, it MUST be zero. This lets the receiver know it has the last packet of a frame, so it can display the image without waiting for the first packet of the next frame to show up and reveal the frame change 🖼️ However, detection of a frame change MUST NOT rely on the marker bit, since the last packet of the frame might get lost 💀 Detection of a frame change MUST be based on a difference in the RTP timestamp.

2.3. Payload Structures 📦

so the integral DIF blocks get placed into the RTP payload, starting right after the RTP header. You can pack any number of DIF blocks into one RTP packet, but all DIF blocks in one RTP packet MUST be from the same video frame. DIF blocks from the next video frame MUST NOT be packed into the same RTP packet, even if there's still payload space left 🙅‍♀️ Why? The move from one frame to the next is flagged by a change in the RTP timestamp, and keeping frames separate also cuts down on processing complexity for the receiver 🧠 Since the RTP payload holds an integral number of DIF blocks, the length of the RTP payload will be a multiple of 80 bytes.

Audio and video can be sent as one bundled RTP stream or in separate RTP streams (unbundled) 🎶 The choice MUST be indicated as part of assigning the dynamic payload type, and it MUST remain unchanged for the whole duration of the RTP session. That way you avoid messy sequence number synchronization drama 😭 The RTP sender could leave out the DIF sequence header and subcode DIF blocks from a stream when that info is known from out-of-band sources or isn't needed for the application. Note that time code in DIF blocks is mandatory for professional video applications 🎬 When unbundled audio and video streams are sent, any DIF sequence header and subcode DIF blocks MUST be included and sent in the video stream.

DV streams have "source" and "source control" packs that carry info that's indispensable for proper decoding, like video signal type, frame rate, aspect ratio, picture position, quantization of audio sampling, number of audio samples in a frame, number of audio channels, audio channel assignment, and audio language. Describing all of these with a signaling protocol would need huge descriptions to list every combination, so no Session Description Protocol (SDP) [RFC4566] parameters for these attributes are defined in this document. Instead, the RTP sender MUST transmit at least those VAUX (Video Auxiliary) DIF blocks and/or audio DIF blocks with AAUX (Audio Auxiliary) information bytes that include "source" and "source control" packs holding the indispensable decoding info ✨

With one bundled stream, DIF blocks for both audio and video get packed into RTP packets in the same order they were encoded 🎀

With an unbundled stream, only the header, subcode, video, and VAUX DIF blocks are sent within the video stream. Audio can go in a different stream if you want, using a different RTP payload type. It's also possible to send audio duplicated in a separate stream, on top of bundling it with the video stream 🦋

When you're using unbundled mode, it is RECOMMENDED that the audio stream data be pulled out of the DIF blocks and repackaged into the matching RTP payload format for the audio encoding (DAT12, L16, L20) [RFC3551][RFC3190]. This maximizes interoperability with non-DV-capable receivers while keeping the original source quality 🌈

For unbundled transmission that's stuck using both audio and video in the DV format, the same timestamp SHOULD be used for both audio and video data within the same frame. This makes lip sync way easier on the receiver 👄 Lip synchronization can also be achieved using reference timestamps passed in RTP Control Protocol (RTCP), as described in [RFC3550]. In that case, the audio stream uses the 90 kHz clock rate, and the timestamp uses the same clock rate as the video.

The sender MAY reduce the video frame rate by discarding the video data and VAUX DIF blocks for some of the video frames. The RTP timestamp MUST still be incremented to account for the discarded frames ⏭️ The sender MAY alternatively reduce bandwidth by discarding video data DIF blocks for portions of the image that haven't changed from the previous image. To make this bandwidth reduction work, receivers SHOULD implement an error-concealment strategy to handle lost or missing DIF blocks, e.g., repeating the corresponding DIF block from the previous image 🩹

3. Payload Format Parameters 🧁

This section specifies the parameters that MAY be used to select optional features of the payload format and certain features of the bitstream. The parameters are specified here as part of the media type registration for the DV encoding. A mapping of the parameters into the Session Description Protocol (SDP) [RFC4566] is also provided for applications that use SDP. Equivalent parameters could be defined elsewhere for use with control protocols that don't use SDP.

3.1. Media Type Registration

This registration is done using the template defined in RFC 4288 [RFC4288] and following RFC 4855 [RFC4855].

3.1.1. Media Type Registration for DV Video

Type name: video

Subtype name: DV

Required parameters:

encode: type of DV format. Permissible values for encode are:

SD-VCR/525-60
SD-VCR/625-50
HD-VCR/1125-60
HD-VCR/1250-50
SDL-VCR/525-60
SDL-VCR/625-50
314M-25/525-60
314M-25/625-50
314M-50/525-60
314M-50/625-50
370M/1080-60i
370M/1080-50i
370M/720-60p
370M/720-50p
306M/525-60 (for backward compatibility)
306M/625-50 (for backward compatibility)

Optional parameters:

audio: whether the DV stream includes audio data or not. Permissible values for audio are bundled and none. Defaults to none.

Encoding considerations: DV video can be transmitted with RTP as specified in RFC 6469 (this document). Other transport methods are not specified.

Security considerations: See Section 4 of RFC 6469 (this document).

Interoperability considerations: Interoperability with previous implementations is discussed in Section 8.

Public specifications:

  • IEC 61834 Standard
  • SMPTE 314M
  • SMPTE 370M
  • RFC 6469 (this document)
  • SMPTE 306M (for backward compatibility)

Applications that use this media type: Audio and video streaming and conferencing tools.

Additional information: NONE

Person & email address to contact for further information:

Katsushi Kobayashi ikob@riken.jp

Intended usage: COMMON

Restrictions on usage: This media type depends on RTP framing and hence is only defined for transfer via RTP [RFC3550]. Transfer within other framing protocols is not defined at this time.

Author:

Katsushi Kobayashi

Change controller:

IETF Audio/Video Transport working group delegated from the IESG

3.1.2. Media Type Registration for DV Audio

Type name: audio

Subtype name: DV

Required parameters:

encode: type of DV format. Permissible values for encode are:

SD-VCR/525-60
SD-VCR/625-50
HD-VCR/1125-60
HD-VCR/1250-50
SDL-VCR/525-60
SDL-VCR/625-50
314M-25/525-60
314M-25/625-50
314M-50/525-60
314M-50/625-50
370M/1080-60i
370M/1080-50i
370M/720-60p
370M/720-50p
306M/525-60 (for backward compatibility)
306M/625-50 (for backward compatibility)

Optional parameters:

audio: whether the DV stream includes audio data or not. Permissible values for audio are bundled and none. Defaults to none.

Encoding considerations: DV audio can be transmitted with RTP as specified in RFC 6469 (this document). Other transport methods are not specified.

Security considerations: See Section 4 of RFC 6469 (this document).

Interoperability considerations: Interoperability with previous implementations is discussed in Section 8.

Published specifications:

  • IEC 61834 Standard
  • SMPTE 314M
  • SMPTE 370M
  • RFC 6469 (this document)
  • SMPTE 306M (for backward compatibility).

Applications that use this media type: Audio and video streaming and conferencing tools.

Additional information: NONE

Person & email address to contact for further information:

Katsushi Kobayashi ikob@riken.jp

Intended usage: COMMON

Restrictions on usage: This media type depends on RTP framing and hence is only defined for transfer via RTP [RFC3550]. Transfer within other framing protocols is not defined at this time.

Author:

Katsushi Kobayashi

Change controller:

IETF Audio/Video Transport working group delegated from the IESG

3.2. SDP Parameters

3.2.1. Mapping of Payload Type Parameters to SDP ✨

okay so the media type info has to get translated into SDP fields, since SDP is what everyone uses to describe RTP sessions 🎀 when you're using SDP for DV encoding, the mapping goes like this:

  • The media type ("video") goes in SDP "m=" as the media name.
  • The media subtype ("DV") goes in SDP "a=rtpmap" as the encoding name. The RTP clock rate in "a=rtpmap" MUST be 90000, which for the payload format defined in this document is a 90 kHz clock. 🕘
  • Any remaining parameters go in the SDP "a=fmtp" attribute by copying them straight from the media type string as a semicolon-separated list of parameter=value pairs. 💅

in the DV video payload format, the "a=fmtp" line is where you show the encoding type inside the DV video, and it looks like this 👇

a=fmtp:<payload type> encode=<DV-video encoding>

the "encode" parameter is required, and it tells you which type of DV format you're getting. the DV format name is always one of these values, no cap, you gotta pick from this list 📋

SD-VCR/525-60
SD-VCR/625-50
HD-VCR/1125-60
HD-VCR/1250-50
SDL-VCR/525-60
SDL-VCR/625-50
314M-25/525-60
314M-25/625-50
314M-50/525-60
314M-50/625-50
370M/1080-60i
370M/1080-50i
370M/720-60p
370M/720-50p
306M/525-60 (for backward compatibility)
306M/625-50 (for backward compatibility)

if you want to show whether the audio is bundled into the DV stream, there's a format-specific parameter for that too 🎶

a=fmtp:<payload type> encode=<DV-video encoding> audio=<audio
bundled>

the "audio" parameter is optional, and it'll be one of these values 🌸

bundled
none (default)

so here's the big one 💀 if the fmtp "audio" parameter isn't there at all, then audio data MUST NOT be bundled into the DV video stream. no bundling, no drama. ✨

3.2.2. Usage with the SDP Offer/Answer Model 🤝

these are the things to keep in mind when you're using the SDP offer/answer procedures [RFC3264] to negotiate the DV payload in RTP 🦋

  • The "encode" parameter can be used for sendrecv, sendonly, and recvonly streams. Each encode type MUST use a separate payload type number. 🔢
  • Any unknown parameter in an offer MUST be ignored by the receiver and MUST NOT be included in the answer. the receiver just politely skips it 🙈

for an offer with unbundled streams, you can use the group attribute from the Session Description Protocol (SDP) Grouping Framework [RFC5888] to link the related audio and video together. the example usage of SDP grouping is detailed in [RFC5888] 🫶

3.3. Examples 🧚

okay now the fun part, some example SDP session descriptions using the DV encoding formats 💖

3.3.1. Example for Unbundled Streams 🎬

when you're in unbundled mode, the RTP streams for video and audio get sent separately, to different ports or different multicast groups 😭 when the audio and video are unbundled, SDP has a few "m=" lines, one for each media type in the session (see [RFC4566]).

here's an SDP description that uses these attributes 👇

  v=0
  o=ikob 2890844526 2890842807 IN IP4 192.0.2.1
  s=POI Seminar
  i=A Seminar on how to make Presentations on the Internet
  u=http://www.example.net/~ikob/POI/index.html
  e=ikob@example.net (Katsushi Kobayashi)
  c=IN IP4 233.252.0.1/127
  t=2873397496 2873404696
  m=audio 49170 RTP/AVP 112
  a=rtpmap:112 L16/32000/2
  m=video 50000 RTP/AVP 113
  a=rtpmap:113 DV/90000
  a=fmtp:113 encode=SD-VCR/525-60 audio=none

so this session has audio and video streams sent separately 🎧 it goes to the multicast group 233.252.0.1. the audio uses L16 format, and the video uses SD-VCR 525/60 format, which is the NTSC format in consumer DV 📺✨

3.3.2. Example for Bundled Streams 📦

when you send a bundled stream, all the DIF blocks, system data included, go through one single RTP stream 💜

here's an SDP description for a bundled DV stream 👇

  v=0
  o=ikob 2890844526 2890842807 IN IP4 192.0.2.1
  s=POI Seminar
  i=A Seminar on how to make Presentations on the Internet
  u=http://www.example.net/~ikob/POI/index.html
  e=ikob@example.net (Katsushi Kobayashi)
  c=IN IP4 233.252.0.1/127
  t=2873397496 2873404696
  m=video 49170 RTP/AVP 112 113
  a=rtpmap:112 DV/90000
  a=fmtp:112 encode=SD-VCR/525-60 audio=bundled
  a=fmtp:113 encode=314M-50/525-60 audio=bundled

this SDP record describes a session where the audio and video are sent bundled 🌈 it goes to the multicast group 233.252.0.1. the video uses both 525/60 consumer DV and SMPTE standard 314M 50 Mbit/s formats, with payload types 112 and 113 respectively 🍓

4. Security Considerations 🔐

RTP packets using the payload format from this spec are subject to the security considerations in the RTP specification [RFC3550] and any appropriate RTP profile. so 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. no drama between them 🫶

this is a real one, bestie 😭 a potential denial-of-service threat exists for data encodings that use 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. however, this encoding does not exhibit any significant non-uniformity, so it's giving safe 💅

as with any IP-based protocol, a receiver can sometimes get overloaded just from receiving too many packets, whether they're wanted or not 💀 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, mechanisms for joining and pruning specific sources are specified in IGMPv3, Multicast Listener Discovery Version 2 (MLDv2) [RFC3376][RFC3810] or Lightweight-IGMPv3 (LW-IGMPv3), LW-MLDv2 [RFC5790], and in multicast routing protocols, so a receiver can pick which sources are allowed to reach it [RFC4607] 🦋

5. Congestion Control 🌊

the general congestion control considerations for transporting RTP data apply. see RTP [RFC3550] and any applicable RTP profile, like the Audio-Visual Profile (AVP) [RFC3551] ✨

6. IANA Considerations 📝

this document obsoletes [RFC3189], and some registration forms have been updated by this document. the registration forms (based on the RFC 4855 [RFC4855] definition) for the media types for both video and audio are in Section 3.1 🎀

7. Major Changes from RFC 3189 🔄

the changes from [RFC3189] are:

  1. Specified that support for SMPTE 306M is only for backward interoperability, since it is covered by SMPTE 314M format. 🙃
  2. Added SMPTE 370M 100 Mbit/s High Definition Television (HDTV) (1080/60i, 1080/50i, 720/60p, and 720/50p) format. 📺
  3. Incorporated the Source-Specific Multicast (SSM) specification for avoiding overloaded traffic source in multicast usage. Added a reference to the Source-Specific Multicast (SSM) specification as a way to reduce unwanted traffic in a multicast application. 🚫
  4. Clarified the case where a sender omits subcode DIF block data from the stream. 🧩
  5. Added considerations for the offer/answer model. 🤝
  6. Revised media types registration form based on new registration rule [RFC4855]. 📋

8. Interoperability with Previous Implementations 🧃

in this section we talk about interoperability with implementations based on [RFC3189], which is obsoleted by this document 💖

[RFC3189] regards SMPTE 306M [SMPTE306M] and SMPTE 314M [SMPTE314M] as different encoding formats, even though the format of SMPTE 306M is already covered by SMPTE 314M 🤔 so this document recommends that the definition depending on SMPTE 306M SHOULD NOT be used, and that SMPTE 314M SHOULD be used instead. an RTP application could handle a stream identified in SMPTE 306M encoding as SMPTE 314M encoding instead 🦋

an offer MAY include SMPTE 306M encoding coming from a legacy system, and receivers SHOULD support this value 🕰️

if an initial offer that did not include SMPTE 306M was rejected, the offerer MAY try a new offer with SMPTE 306M. for this case, an RTP application MAY handle a stream identified in SMPTE 306M encoding as SMPTE 314M encoding instead 🔁

also, the SDP examples in [RFC3189] give incorrect SDP "a=fmtp" attribute usage 🙈

9. Acknowledgment 💜

thanks to Akimichi Ogawa, a former author of this document 🫶

10. References 📚

10.1. Normative References

  • [IEC61834] IEC, "IEC 61834, Helical-scan digital video cassette recording system using 6,35 mm magnetic tape for consumer use (525-60, 625-50, 1125-60 and 1250-50 systems)".
  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC3190] Kobayashi, K., Ogawa, A., Casner, S., and C. Bormann, "RTP Payload Format for 12-bit DAT Audio and 20- and 24-bit Linear Sampled Audio", RFC 3190, January 2002.
  • [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
  • [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.
  • [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
  • [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
  • [RFC4855] Casner, S., "Media Type Registration of RTP Payload Formats", RFC 4855, February 2007.
  • [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description Protocol (SDP) Grouping Framework", RFC 5888, June 2010.
  • [SMPTE306M] SMPTE, "SMPTE 306M, 6.35-mm Type D-7 Component Format - Video Compression at 25Mb/s - 525/60 and 625/50".
  • [SMPTE314M] SMPTE, "SMPTE 314M, Data Structure for DV-Based Audio and Compressed Video - 25 and 50Mb/s".
  • [SMPTE370M] SMPTE, "SMPTE 370M, Data Structure for DV-Based Audio, Data and Compressed Video at 100 Mb/s 1080/60i, 1080/50i, 720/60p, and 720/50p".

10.2. Informative References ✨

okay bestie, these are the "extra reading" references 📚 they're not required to implement the spec, but they're where the MPEG, DV, and multicast stuff lives 🦋

  • [IEC61883] IEC, "IEC 61883, Consumer audio/video equipment - Digital interface". 🎀
  • [IEEE1394] IEEE, "IEEE Std 1394-1995, Standard for a High Performance Serial Bus". 🔥
  • [ISO/IEC11172] ISO/IEC, "ISO/IEC 11172, Coding of moving pictures and associated audio for digital storage media up to about 1,5 Mbit/s". 🎬
  • [ISO/IEC13818] ISO/IEC, "ISO/IEC 13818, Generic coding of moving pictures and associated audio information". 🌈
  • [RFC2250] Hoffman, D., Fernando, G., Goyal, V., and M. Civanlar, "RTP Payload Format for MPEG1/MPEG2 Video", RFC 2250, January 1998. 🌸
  • [RFC3189] Kobayashi, K., Ogawa, A., Casner, S., and C. Bormann, "RTP Payload Format for DV (IEC 61834) Video", RFC 3189, January 2002. 💜 this one's giving "the DV format I've been obsessed with" energy
  • [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002. 🫶
  • [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. ✨
  • [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006. 🧚
  • [RFC5790] Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2) Protocols", RFC 5790, February 2010. 💅

Authors' Addresses 🍓

Meet the squad behind this doc! 👑 Here are their details, exactly as they're written:

Katsushi Kobayashi
Advanced Institute for Computational Science, RIKEN
7-1-26 Minatojima-minami
Chuo-ku, Kobe, Hyogo  760-0045
Japan

EMail: ikob@riken.jp


Kazuhiro Mishima
Keio University
5322 Endo
Fujisawa, Kanagawa  252-8520
Japan

EMail: three@sfc.wide.ad.jp


Stephen L. Casner
Packet Design
2455 Augustine Drive
Santa Clara, CA  95054
United States

EMail: casner@acm.org


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

Phone: +49 421 218 63921
Fax:   +49 421 218 7000
EMail: cabo@tzi.org
📦 where this page comes from