Associating Time-Codes with RTP Streams
RFC 5484

Document Type RFC - Proposed Standard (March 2009; No errata)
Last updated 2013-03-02
Replaces draft-singer-smpte-rtp
Stream IETF
Formats plain text pdf html
Stream WG state (None)
Consensus Unknown
Document shepherd No shepherd assigned
IESG IESG state RFC 5484 (Proposed Standard)
Telechat date
Responsible AD Cullen Jennings
Send notices to avt-chairs@ietf.org, singer@apple.com
Network Working Group                                          D. Singer
Request for Comments: 5484                           Apple Computer Inc.
Category: Standards Track                                     March 2009

                Associating Time-Codes with RTP Streams

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to 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 Notice

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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   This document describes a mechanism for associating time-codes, as
   defined by the Society of Motion Picture and Television Engineers
   (SMPTE), with media streams in a way that is independent of the RTP
   payload format of the media stream itself.

Singer                      Standards Track                     [Page 1]
RFC 5484                  RTP SMPTE Time-Codes                March 2009

Table of Contents

   1. Introduction ....................................................2
   2. Requirements Notation ...........................................3
   3. Design Goals ....................................................3
   4. Requirements and Constraints ....................................4
   5. Signaling Information ...........................................4
   6. In-Stream Information ...........................................6
      6.1. Compact Format of the Time-Code ............................6
      6.2. Full Format of the Time-Code ...............................7
      6.3. Associations in RTCP .......................................8
      6.4. Associations in RTP ........................................9
   7. Implementation Note (Informative) ..............................10
   8. Discussion (Informative) .......................................10
   9. Security Considerations ........................................11
   10. IANA Considerations ...........................................11
   11. Acknowledgments ...............................................12
   12. References ....................................................12
      12.1. Normative References .....................................12
      12.2. Informative References ...................................12

1.  Introduction

   First a brief background on time-codes [SMPTE-12M].

   The time-code system in common use is defined by the Society of
   Motion Picture and Television Engineers (SMPTE); in it, time-codes
   count frames.  A common form of the display looks like a normal clock
   value (hh:mm:ss.frame).  When the frame rate is truly integral, then
   this can be a normal clock value, in that seconds tick by at the same
   rate as the seconds we know and love.

   However, NTSC video infamously runs slightly slower than 30 frames
   per second (fps).  Some people call it 29.97, which isn't quite
   right; to be accurate, a frame takes 1001 ticks of a 30000 tick/
   second clock.  Be that as it may, SMPTE time-codes count 30 of these
   frames and deem that to make a second.

   This causes an SMPTE time-code display to 'run slow' compared to
   real-time.  To ameliorate this, sometimes a format called drop-frame
   is used.  Some of the frame numbers are skipped, so that the counter
   periodically 'catches up' (so some time-code seconds actually only
   have 28 frames in them).

Singer                      Standards Track                     [Page 2]
RFC 5484                  RTP SMPTE Time-Codes                March 2009

   It is worth noting that in neither case is the SMPTE time-code an
   accurate clock; in the first case, it runs slow, and in the second,
   the adjustments are abrupt and periodic -- and still not quite
   accurate.  Hence the rest of this document tries to be clear when
   referring to a second in a time-code as a 'time-code second'.

   However, SMPTE time-codes do run in real-time when used with systems
   with integral fps (e.g., film content at 24 fps or PAL video).

   This specification defines how to carry time-codes in RTP and RTCP
   (RTP Control Protocol), associate them with a media stream, and
   synchronize them with the RTP timestamps.  It uses the general RTP
Show full document text