idnits 2.17.1 draft-singer-smpte-rtp-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 284. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 295. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 302. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 308. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 7 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 8 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'SMPTE' is mentioned on line 57, but not defined == Unused Reference: 'SMPTE-12M' is defined on line 330, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'SMPTE-12M' Summary: 6 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force 3 INTERNET-DRAFT D. Singer 4 draft-singer-smpte-rtp-01.doc Apple Computer 6 May 25 2005 7 Expires: Nov 25 2005 9 Associating SMPTE time-codes with RTP streams 11 IPR Notice 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware have 15 been or will be disclosed, and any of which he or she becomes aware will 16 be disclosed, in accordance with Section 6 of BCP 79. 18 Status of This Memo 20 This document is an Internet-Draft and is in full conformance with 21 all provisions of Section 10 of RFC2026. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than a "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/1id-abstracts.html 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html 39 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 40 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 41 document are to be interpreted as described in RFC 2119. 43 Distribution of this document is unlimited. 45 Copyright Notice 47 Copyright (C) The Internet Society (2005). 49 Abstract 51 This document describes a mechanism for associating SMPTE time-codes 52 with media streams, in a way that is independent of the RTP payload 53 format of the media stream itself. 55 1 Introduction 57 First a brief background on SMPTE time-codes [SMPTE]. 59 SMPTE time-codes count frames. There are two common forms of 60 display: either a simple counter, or what looks like a normal clock 61 value (hh:mm:ss.frame). When the frame rate is truly integer, then 62 this can be a normal clock value, in that seconds tick by at the same 63 rate as the seconds we know and love. 65 However, NTSC video infamously runs slightly slower than 30 66 frames/second. Some people call it 29.97 (which isn't quite right) 67 and some say that a frame takes 1001 ticks of a 30000 tick/second 68 clock (which is closer). Be that as it may, SMPTE time codes count 69 30 of these frames and deem that to make a second. 71 This causes a SMPTE time-code display to 'run slow' compared to real- 72 time. To ameliorate this, sometimes a format called drop-frame is 73 used. Some of the frame numbers are skipped, so that the counter 74 periodically 'catches up' (so some time-code-seconds actually only 75 have 28 or 29 frames in them). 77 It is worth noting that in neither case is the SMPTE time-code an 78 accurate clock; in the first case, it runs slow, and in the second, 79 the adjustments are abrupt and periodic - and still not quite 80 accurate. Hence in the rest of this document I try to be clear when 81 referring to a second in a time-code as a 'time-code second'. 83 However, SMPTE time-codes do run in real-time when used with systems 84 with integral frames/second (e.g. film content at 24 frames/second, 85 or PAL video). The 'drift' issue is (I believe) unique to NTSC 86 video. 88 2 Design Goals 90 What we desire is a system that allows us to associate a SMPTE time- 91 code with some media in an RTP [RTP] stream. Since in RTP all media 92 has a clock already, we can often leverage that fact. If we treat 93 the media as having 'segments' of time in which the time-code is 94 simply counting up, then the time-code anywhere within a segment can 95 be calculated if you know: 97 1. the RTP timestamp of the start of the segment; 98 2. the time-code of the start of the segment; 99 3. the counting rate and other parameters of the time-code; 100 4. the RTP timestamp where you want to know the time-code. 102 There are two cases to consider: 103 1. the time-codes are piece-wise continuous with only occasional 104 discontinuities; 105 2. the continuity of the time-codes is not certain (or not known). 107 The first can be handled by providing details of the time-code axis 108 and an initial mapping from RTP time to time-code time, and periodic 109 mappings in RTCP packets. 111 The second requires in-band signaling within the RTP packets 112 themselves. 114 Both cases are covered by this specification. 116 3 Signaling (setup) information 118 If the recipient must ever calculate time-codes based on the RTP 119 times, then some setup information is needed. This is sent out-of- 120 band (e.g. in SDP; the SDP mapping is TBD). 122 The setup information includes: 123 1. the duration, in the RTP timescale, timescale, of a single 124 frame-count in the 'frames' portion of the time-code (frame- 125 duration) 126 2. the number of those frames that make a time-code-second 127 (frames-per-tc-second) 128 3. the following booleans: 129 3.1 is-NTSC-drop-frame: should the usual 'left out numbers' of 130 drop-frame be applied or not? 131 3.2 display-time-code-as-counter: should the display be an 132 integer frame-count, or hh:mm:ss.fr format? 133 3.3 time-code-displayed: is it intended that this time-code be 134 displayed somehow? 136 Note that other information we need to do the calculation (e.g. the 137 clock rate of the RTP timestamp) is supplied already and assumed to 138 be available. 140 For example, if associated with a video track with the common time- 141 scale of 90000, then frame-duration of 3003 and frames-per-tc-second 142 of 30 would yield a 'normal' SMPTE time-code for NTSC video. 143 Similarly values of 3750 and 24 yield a time-code for 24 fps film 144 content, and so on. 146 4 In-stream information 148 4.1 Format of the Time-code 150 A binary SMPTE time-code in this design occupies 24 bits. It is NOT 151 formatted in the BCD system, but uses binary fixed-width fields. If 152 the SMPTE time-code has been signaled as a simple counter (see 153 above), then the 24 bits are a signed integer frame-count. If it is 154 a 'classic' time-code, it has the following structure: 156 sign(1) -- 1 for negative, 0 for positive 157 hours (5 bits) -- 0 to 23; the values 24-31 are reserved 158 minutes (6 bits) -- 0 to 59; 60-63 are reserved 159 seconds (6 bits) -- 0 to 59; 60-63 are reserved 160 frames(6 bits) -- 0 to (frames-per-tc-second - 1) 162 Note that these fields are larger than the provision in SMPTE 12M 163 where binary-coded decimal is used (and notably, only two bits are 164 provided for the tens digit of the frame count, so frame numbers 165 above 39 cannot be represented). 167 4.2 Associations in RTCP 169 When the time-codes are piece-wise continuous, we then supply in RTCP 170 packets an RTP timestamp and an SMPTE time-code, for the start of 171 each run of calculable time-codes. This establishes the time-code 172 for all RTP times greater than or equal to the one given, until a 173 subsequent APP packet reestablishes the mapping. 175 Note that the RTP time-stamp in the RTCP mapping may not match the 176 time-stamp of any frame in the media stream. For video, it normally 177 would; but a time-stamp transition may happen part-way through a 178 decoded audio frame. Since they share the same clock, the timing of 179 that transition and the timing of the audio stream itself have the 180 same accuracy. 182 4.3 Associations in RTP 184 When the time-codes are not known to be piece-wise continuous, or 185 absolute surety of mapping is desired, then the mapping can be placed 186 into some or all of the RTP packets. This is a less desirable route; 187 it uses the RTP header extension, which some terminals may find 188 problematic. And clearly placing mapping information in every packet 189 uses more bandwidth. 191 In as many RTP packets as needed (possibly all), a named header 192 extension is used to associate an RTP time to a SMPTE time-code. 193 (See related specification of named header extensions for RTP). 195 There are two forms of this header extension. The first ('short') 196 form associates the time-code with the RTP timestamp of the packet. 197 The second ('long') form allows associates the time-code with a 198 timestamp offset from the RTP timestamp of the packet. 200 The short form has the name "org.smpte.12M.short", and contains 201 solely a 24-bit time-code as defined above. 203 The long form has the name "org.smpte.12M.long", and contains the 204 24-bit time-code as defined above, followed by a signed 32-bit offset 205 D from the RTP timestamp. If the packet has timestamp T, this 206 establishes an RTP to time-code association for the RTP time T+D. 208 5 Discussion 210 This design has the advantage of not requiring the introduction of 211 new IP packets into the sessions or new data into the main data 212 channel, using low-bandwidth (vanishingly low in the case of streams 213 with no discontinuities), and is independent of the design of the RTP 214 packets themselves: the RTP profile (including possibly encryption) 215 and the RTP payload format. SMPTE time-codes can be associated with 216 any RTP stream, including those with existing payload formats. 218 It might be argued that we could set the initial mapping also in the 219 SDP, since RTCP packets might get lost. But this means that the SDP 220 now has to have knowledge of the RTP random offset, which is nasty; 221 and if one puts this APP packet into all sender reports, it's 222 probably good enough. Then if you don't have time-codes, you don't 223 have audio-video-sync either. 225 This associates the time-code with a particular media stream. An 226 alternative would be to make it an RTP stream in its own right; but 227 the data rate is so low, this seems egregious. And by packing it 228 inline, we can do this backwards-compatible for gateways etc. that 229 already handle dual-stream. 231 The APP packets (or the in-band codes) need not use the same RTP 232 timestamp as the sender report (or transmission time) in the same 233 RTCP packet. They can be sent 'ahead of need' if possible (e.g. for 234 stored content, when the server can look-ahead) or just-in-time - 235 send an RTCP immediately a discontinuity in the time-code is 236 detected, and allow media-buffering in the client the chance to 237 'catch' the RTCP before the matching RTP packet is processed and 238 displayed, 239 There is no way in this draft to detect that an RTCP packet has been 240 lost, and that a mapping may be being used outside its intended 241 range. The likelihood of this happening can be reduced, however, by 242 permitting a pair of RTP times in the mapping, and defining that the 243 mapping is only valid between those times. This only works for 244 stored media, when look-ahead is possible, of course. It is a 245 discussion item whether it is worthwhile. 247 The design assumes that clients will hold mappings until they are 248 superseded, and that a client may need to buffer some number of 249 upcoming mappings. It may be necessary to introduce explicit 250 statements about the amount of buffering needed. 252 For trick modes, it may be desirable to signal that a given section 253 of media has the time-code running in reverse; this would require a 254 new sign bit in the mapping record. 256 6 Security Considerations 258 SMPTE time-codes are only informative and it is hard to see security 259 considerations from associating them with media streams. 261 7 IANA Considerations 263 None, unless the domain-reversed names for the time-codes should be 264 centrally documented somewhere. 266 8 RFC Editor Considerations 268 None. 270 9 Full Copyright Statement 272 Copyright (C) The Internet Society (2005). 274 This document is subject to the rights, licenses and restrictions 275 contained in BCP 78, and except as set forth therein, the authors 276 retain all their rights. 278 This document and the information contained herein are provided on an 279 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 280 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 281 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 282 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 283 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 284 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 286 10 Intellectual Property Notice 288 The IETF takes no position regarding the validity or scope of any 289 Intellectual Property Rights or other rights that might be claimed to 290 pertain to the implementation or use of the technology described in 291 this document or the extent to which any license under such rights 292 might or might not be available; nor does it represent that it has 293 made any independent effort to identify any such rights. Information 294 on the procedures with respect to rights in RFC documents can be 295 found in BCP 78 and BCP 79. 297 Copies of IPR disclosures made to the IETF Secretariat and any 298 assurances of licenses to be made available, or the result of an 299 attempt made to obtain a general license or permission for the use of 300 such proprietary rights by implementers or users of this 301 specification can be obtained from the IETF on-line IPR repository at 302 http://www.ietf.org/ipr. 304 The IETF invites any interested party to bring to its attention any 305 copyrights, patents or patent applications, or other proprietary 306 rights that may cover technology that may be required to implement 307 this standard. Please address the information to the IETF at ietf- 308 ipr@ietf.org. 310 Acknowledgments 312 Both Brian Link and John Lazzaro provided helpful comments on an 313 initial draft. 315 Authors' Contact Information 316 David Singer 317 Apple Computer, Inc. 318 One Infinite Loop, MS:302-3MT 319 Cupertino CA 95014 320 USA 321 Email: singer@apple.com 322 Tel: +1 408 974 3162 324 6. References 325 [RTP] 326 RFC3550, STD0064, RTP: A Transport Protocol for Real-Time 327 Applications, H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, 328 July 2003 330 [SMPTE-12M] 331 SMPTE 12M-1999, Television, Audio and Film - Time and Control Code 333 Dates 334 Written: May 25 2005 335 Expires: Nov 25 2005