Subject: RE: (s22-12m) RE: (s22-list) FW: [AVT] Carrying SMPTE TimeCode in RTP

From: "Patrick Waddell" <[email-masked]>
Date: Fri, 3 Mar 2006 06:31:11 -0800

Bill/Colin:
 
Let's begin by asking:  what, exactly, is the IETF group wishing to
carry?  Is it the timecode sample of a given frame of video?  well then,
how's about the audio?  what is the application targeted?   if it is VOD
or similar, then velocity and direction information may also be useful.
So, some additional background, please!
 
Pat Waddell
Chair, SMPTE 12M Revision AHG

________________________________

	From: Miller, William C [mailto:[email-masked]] 
	Sent: Thursday, March 02, 2006 11:53 PM
	To: Colin Perkins
	Cc: [email-masked]; Patrick Waddell
	Subject: RE: (s22-12m) RE: (s22-list) FW: [AVT] Carrying SMPTE
TimeCode in RTP

	Colin,
	 
	I agree that would be wise.  Pat, perhaps we should all look at
it.
	 
	Best regards,
	Bill

		-----Original Message----- 
		From: Colin Perkins [mailto:[email-masked]] 
		Sent: Thu 3/2/2006 6:37 PM 
		To: Miller, William C 
		Cc: [email-masked] 
		Subject: Re: (s22-12m) RE: (s22-list) FW: [AVT] Carrying
SMPTE TimeCode in RTP

		Bill,
		
		Okay - if there are reasonable use cases where the date
can jump from 
		frame to frame, I'm not going to argue against including
it. That has 
		been listed as an open issue in the draft for several
months now 
		though, so it seemed there was no need to support it.
Perhaps someone 
		from SMPTE S22 could do a review of the entire draft to
ensure there 
		are no more such problems waiting?
		
		Colin

		On 2 Mar 2006, at 21:15, Miller, William C wrote:
		> Colin,
		>
		> With respect, you're assuming that timecode is
continuous.  Thais 
		> may not be the case; spliced video streams will not
have continuous 
		> timecode (unless its been restriped.)  The only way to
know the 
		> date associated with a given frame under these
circumstances is to 
		> code it with every frame.
		>
		> The user bits are also used for a lot of things
besides the date, 
		> including secondary time codes.  As you've seen from
the other 
		> responses I've forwarded, there is serious concern
among the 
		> individuals who participate in SMPTE S22 that the
usability of 
		> SMPTE timecode will be seriously compromised if you
don't pass all 
		> of it through the transport.
		>
		> That said, I'm sure there are applications, primarily
retail, where 
		> this will not be an issue.  However, I wonder whether
the savings 
		> in overhead (32 bits per frame) is worth having to
maintain two 
		> separate timecode transports, full and partial.
		>
		> Best regards,
		> Bill
		> -----Original Message-----
		> From: Colin Perkins [mailto:[email-masked]]
		> Sent: Thu 3/2/2006 3:38 PM
		> To: Miller, William C
		> Cc: [email-masked]
		> Subject: Re: (s22-12m) RE: (s22-list) FW: [AVT]
Carrying SMPTE 
		> TimeCode in RTP
		>
		> RTCP includes a mapping to an NTP format timestamp,
which gives you
		> the date. I don't see any need to include it in every
data packet,
		> perhaps many times per frame, at the expense of
considerable waste in
		> bandwidth, rather than in a periodic (every 5 seconds
or so) control
		> packet.
		>
		> Colin
		>
		>
		> On 2 Mar 2006, at 19:50, Miller, William C wrote:
		> > Forwarded for Peter Vince.
		> >
		> > Bill
		> >
		> >
		> > -----Original Message-----
		> > From: [email-masked] on behalf of Peter
Vince
		> > Sent: Thu 3/2/2006 2:13 PM
		> > To: [email-masked]
		> > Cc:
		> > Subject: (s22-12m) RE: (s22-list) FW: [AVT] Carrying
SMPTE TimeCode
		> > in RTP
		> >
		> > I would argue that the date IS needed.  Time code is
highly
		> > redundant, with the full   HH:MM:SS:FF time being
encoded every
		> > frame.  By this means, the full time can be decoded
from even a
		> > single frame.  24-hour broadcasting has been the
norm for a long
		> > time now, and therefore larger units of time than in
the time part
		> > of the time code are needed to ensure a contiguous
and unambiguous
		> > sequence.  Further, to regenerate the original time
code at the
		> > other end, all the data needs to be carried.
		> >
		> >     Peter Vince (Snr.Engr., BBC TV, London)
		> > Addr: Room 3057, BBC TV Centre, Wood Lane,
Shepherd's Bush, London,
		> > W12 7RJ
		> > Tel.: +44-20-8576-0000
		> > Fax.: +44-20-8576-0018
		> > email: [email-masked]
		> >
		> >
		> > -----Original Message-----
		> > From: [email-masked]
[mailto:owner-s22-
		> > [email-masked]] On Behalf Of Miller, William C
		> > Sent: 02 March 2006 18:02
		> > To: [email-masked]
		> > Subject: (s22-list) FW: [AVT] Carrying SMPTE
TimeCode in RTP
		> >
		> > Anyone want to comment?
		> >
		> > Bill
		> > -----Original Message-----
		> > From: [email-masked] on behalf of Colin
Perkins
		> > Sent: Thu 3/2/2006 12:23 PM
		> > To: Dave Singer
		> > Cc: [email-masked]
		> > Subject: Re: [AVT] Carrying SMPTE TimeCode in RTP
		> >
		> > On 2 Mar 2006, at 00:42, Dave Singer wrote:
		> > > Answering my own email here, I'm assuming that the
answer is 
		> yes to
		> > > the 2nd question.
		> > >
		> > > The extra bits in an 8-byte SMPTE time-code can be
used to
		> > > a) maintain the polarity of the code (numbers of
1s and 0s)
		> > > b) indicate the relationship of the codes to color
fields
		> > > c) indicate whether it's drop-frame coding
		> > > d) and then do one of
		> > >    i) carry 4 characters more
		> > >    ii) carry a date and time-zone indication
(SMPTE 309M)
		> > >    iii) carry some general SMPTE 262M data
(control codes, text,
		> > > production info etc.)
		> > >
		> > > I don't believe we need color and polarity
handling in RTP.
		> > > We have drop-frame in the signalling.
		> > >
		> > > If we want to carry something as slowly-changing
as a date or as
		> > > unchanging as a time-zone, I on't believe that
embedding it 
		> here is
		> > > right.  Certainly thought should be applied before
blindly 
		> applying
		> > > it.  If a date is needed, it's not needed inline;
at most it 
		> would
		> > > be in RTCP, and then I would argue for a new RTCP
packet type to
		> > > carry it.
		> > >
		> > > The other two possibilities are 'general
meta-data' and should not
		> > > be sub-embedded in a time-code, in RTP, but
elevated and properly
		> > > labelled at the stream level.
		> > >
		> > > So, my answer is no, we do not need the full
8-byte SMPTE time-
		> code.
		> >
		> > Seems reasonable.
		> >
		> > Colin
		> >
		> > _______________________________________________
		> > Audio/Video Transport Working Group
		> > [email-masked]
		> > https://www1.ietf.org/mailman/listinfo/avt
		> >
		> >
		> > http://www.bbc.co.uk/
		> >
		> > This e-mail (and any attachments) is confidential
and may contain
		> > personal views which are not the views of the BBC
unless 
		> specifically
		> > stated.
		> > If you have received it in error, please delete it
from your system.
		> > Do not use, copy or disclose the information in any
way nor act in
		> > reliance on it and notify the sender immediately.
Please note 
		> that the
		> > BBC monitors e-mails sent or received.
		> > Further communication will signify your consent to
this.
		> >
		> > _______________________________________________
		> > Audio/Video Transport Working Group
		> > [email-masked]
		> > https://www1.ietf.org/mailman/listinfo/avt
		>
		>
		> _______________________________________________
		> Audio/Video Transport Working Group
		> [email-masked]
		> https://www1.ietf.org/mailman/listinfo/avt

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Dave Singer <[email-masked]>
Date: Fri, 3 Mar 2006 10:06:30 -0800

At 6:31  -0800 3/03/06, Patrick Waddell wrote:
>Content-class: urn:content-classes:message
>Content-Type: multipart/alternative;
>	boundary="----_=_NextPart_001_01C63ECF.1E709504"
>
>Bill/Colin:
>
>carry?  Is it the timecode sample of a given frame of video?  well 
>then, how's about the audio?  what is the application targeted?   if 
>it is VOD or similar, then velocity and direction information may 
>also be useful.  So, some additional background, please!
>
>Pat Waddell

Pat, hi!

the original impetus was a draft that had codec-specific provision 
for carrying time-code (an audio codec, as it happens).  Since 
time-code is logically neither codec nor even media-type specific, we 
asked whether there was a way of carrying it that was independent of 
them, and indeed that could be used with codecs aand media types that 
already had an RTP payload format, and in existing RTP 'profiles' 
(i.e. something that was an upwards-compatible extension).

One obvious answer, since it may be associated to a group of 
synchronized media streams (e.g. video and audio) is to say that it's 
a third stream.  However, given that even if it's carried with every 
frame its bandwidth is low, and often it can be computed so the 
bandwidth is even lower, this seemed very heavy for the problem. 
Also, adding a stream may upset some receivers built to expect only 
(for example) an audio stream.

Hence the genesis of the draft,  As we have for many years carried TC 
in QuickTime using structures like the ones I proposed (compact 
binary representations, and the ability to compute time-codes), I 
volunteered to write a draft.  You see the result.

I'm not aware that we had ever been asked here of time-zone, date, 
4-character, or 262M handling, so I concluded (wrongly) that they may 
not be important.  But that was just one person's perspective, so it 
worried me.

Does that give you enough background?

What I am ignorant of is "normal industry practice" that is not 
expressed by the current 12M.  For example, what are the four 
characters used for?  What is 262M used for, and so on?  What 
proportion of streams put dates into the binary groups, 262M, 4 
chars, or nothing...?

Many thanks for the look and review.

>Subject: RE: (s22-12m) RE: (s22-list) FW: [AVT] Carrying SMPTE TimeCode in RTP
>
>Colin,
>
>I agree that would be wise.  Pat, perhaps we should all look at it.
>
>Best regards,
>Bill
>
>Subject: Re: (s22-12m) RE: (s22-list) FW: [AVT] Carrying SMPTE TimeCode in RTP
>
>Bill,
>
>Okay - if there are reasonable use cases where the date can jump from 
>frame to frame, I'm not going to argue against including it. That has 
>been listed as an open issue in the draft for several months now 
>though, so it seemed there was no need to support it. Perhaps someone 
>from SMPTE S22 could do a review of the entire draft to ensure there 
>>  With respect, you're assuming that timecode is continuous.  Thais 
>>  may not be the case; spliced video streams will not have continuous 
>>  timecode (unless its been restriped.)  The only way to know the 
>>  date associated with a given frame under these circumstances is to 
>>  The user bits are also used for a lot of things besides the date, 
>>  including secondary time codes.  As you've seen from the other 
>>  responses I've forwarded, there is serious concern among the 
>  > individuals who participate in SMPTE S22 that the usability of 
>>  SMPTE timecode will be seriously compromised if you don't pass all 
>>  That said, I'm sure there are applications, primarily retail, where 
>>  this will not be an issue.  However, I wonder whether the savings 
>>  in overhead (32 bits per frame) is worth having to maintain two 
>>  From: Colin Perkins [<mailto:[email-masked]>mailto:[email-masked]]
>>  Subject: Re: (s22-12m) RE: (s22-list) FW: [AVT] Carrying SMPTE 
>>  TimeCode in RTP
>>
>>  RTCP includes a mapping to an NTP format timestamp, which gives you
>>  the date. I don't see any need to include it in every data packet,
>>  perhaps many times per frame, at the expense of considerable waste in
>>  bandwidth, rather than in a periodic (every 5 seconds or so) control
>>  packet.
>>
>>  Colin
>>
>>
>>  > From: [email-masked] on behalf of Peter Vince
>>  > Subject: (s22-12m) RE: (s22-list) FW: [AVT] Carrying SMPTE TimeCode
>>  > in RTP
>>  >
>>  > I would argue that the date IS needed.  Time code is highly
>>  > redundant, with the full   HH:MM:SS:FF time being encoded every
>>  > frame.  By this means, the full time can be decoded from even a
>>  > single frame.  24-hour broadcasting has been the norm for a long
>>  > time now, and therefore larger units of time than in the time part
>>  > of the time code are needed to ensure a contiguous and unambiguous
>>  > sequence.  Further, to regenerate the original time code at the
>>  > Addr: Room 3057, BBC TV Centre, Wood Lane, Shepherd's Bush, London,
>>  > W12 7RJ
>>  > Tel.: +44-20-8576-0000
>>  > Fax.: +44-20-8576-0018
>>  > From: [email-masked] [<mailto:owner-s22->mailto:owner-s22-
>>  > Subject: (s22-list) FW: [AVT] Carrying SMPTE TimeCode in RTP
>>  >
>>  > Anyone want to comment?
>>  >
>>  > Bill
>>  > From: [email-masked] on behalf of Colin Perkins
>>  > > Answering my own email here, I'm assuming that the answer is 
>>  yes to
>>  > > the 2nd question.
>>  > >
>>  > > The extra bits in an 8-byte SMPTE time-code can be used to
>>  > > a) maintain the polarity of the code (numbers of 1s and 0s)
>>  > > b) indicate the relationship of the codes to color fields
>>  > >    ii) carry a date and time-zone indication (SMPTE 309M)
>>  > >    iii) carry some general SMPTE 262M data (control codes, text,
>>  > > production info etc.)
>>  > >
>>  > > I don't believe we need color and polarity handling in RTP.
>>  > > If we want to carry something as slowly-changing as a date or as
>>  > > unchanging as a time-zone, I on't believe that embedding it 
>>  here is
>>  > > right.  Certainly thought should be applied before blindly 
>>  applying
>>  > > it.  If a date is needed, it's not needed inline;  at most it 
>>  would
>>  > > be in RTCP, and then I would argue for a new RTCP packet type to
>>  > > carry it.
>>  > >
>>  > > The other two possibilities are 'general meta-data' and should not
>>  > > be sub-embedded in a time-code, in RTP, but elevated and properly
>>  > > So, my answer is no, we do not need the full 8-byte SMPTE time-
>>  code.
>  > >
>>  > Seems reasonable.
>>  >
>>  > Colin
>>  >
>><https://www1.ietf.org/mailman/listinfo/avt>https://www1.ietf.org/mailman/listinfo/avt
>>  >
>>  >
>>  > <http://www.bbc.co.uk/>http://www.bbc.co.uk/
>>  >
>>  > This e-mail (and any attachments) is confidential and may contain
>>  > personal views which are not the views of the BBC unless 
>>  specifically
>>  > stated.
>>  > If you have received it in error, please delete it from your system.
>>  > Do not use, copy or disclose the information in any way nor act in
>>  > reliance on it and notify the sender immediately. Please note 
>>  that the
>>  > Further communication will signify your consent to this.
>>  >
>><https://www1.ietf.org/mailman/listinfo/avt>https://www1.ietf.org/mailman/listinfo/avt
>>
>>
>><https://www1.ietf.org/mailman/listinfo/avt>https://www1.ietf.org/mailman/listinfo/avt
>
>

-- 
David Singer
Apple Computer/QuickTime