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

From: "Miller, William C" <[email-masked]>
Date: Thu, 2 Mar 2006 14:50:32 -0500

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] <mailto:[email-masked]> 

		-----Original Message-----
		From: [email-masked] [mailto:[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

---

From: Colin Perkins <[email-masked]>
Date: Thu, 2 Mar 2006 20:38:46 +0000

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:
> 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.
>
> email: [email-masked]
>
>
> From: [email-masked] [mailto:owner-s22- 
> [email-masked]] On Behalf Of Miller, William C

---

From: "Miller, William C" <[email-masked]>
Date: Thu, 2 Mar 2006 16:15:55 -0500

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

	Colin

---

From: Colin Perkins <[email-masked]>
Date: Thu, 2 Mar 2006 23:37:27 +0000

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

---

From: Dave Singer <[email-masked]>
Date: Thu, 2 Mar 2006 16:00:41 -0800

At 23:37  +0000 2/03/06, Colin Perkins wrote:
>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 the question of overhead, you can't assume it will always be with 
video (compressed or uncompressed);  the original request was for 
carrying it with audio, for example.

I also note it's only one of many things that can be carried in the 
binary groups (including nothing).

We have several choices here;  always carry date+time-zone, which 
seems wasteful;  allow it when it is needed, which is a slight 
complexity increase;  or insist that if is needed, it can be computed 
(e.g. from NTP).  I think the last is a non-starter;  the program 
time-codes may be unrelated to real-time, be discontinuous, and so 
on.  So, maybe the second is what is needed.

One issue that has come up also concerns the frame counter;  the 
draft allows for more bits for the frame count than does 12M.  I am 
aware that there may be 'work-arounds' for this in 12M (e.g. using 
the color bit to extend the frame-count bits?), but not sure what 
they are.

Thanks for the comments and feedback;  it was beginning to feel lonely!

-- 
David Singer
Apple Computer/QuickTime

---

From: "Miller, William C" <[email-masked]>
Date: Fri, 3 Mar 2006 02:52:40 -0500

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,

	Colin