FW: (s22-list) FW: [AVT] Carrying SMPTE TimeCode in RTP

["Miller, William C" <[e-mail]>]

Forwarded for Bill Hayes.  As an aside, note that iptv has a meaning other than video over IP.
 
Bill

	-----Original Message----- 
	From: Bill Hayes [mailto:[e-mail]] 
	Sent: Thu 3/2/2006 2:26 PM 
	To: Miller, William C 
	Cc: 
	Subject: RE: (s22-list) FW: [AVT] Carrying SMPTE TimeCode in RTP
	
	
	In life there are few certainties. Death, taxes and SMPTE timecode. If the proposed modification fixes the first two than I am in favor of it. But if I still have to pay taxes and die...than I'd like to see all of the SMPTE timecode carried.
	 
	Bill 
	 
	William T. Hayes
	Director of Engineering and Technology
	Iowa Public Television
	P.O. Box 6450
	Johnston, IA 50131-6450
	515-242-3116 (v)
	515-242-3109 (f)
	 
	<http://www.iptv.org/dtv/2006> 
	 

  _____  

	From: [e-mail] [mailto:[e-mail]] On Behalf Of Miller, William C
	Sent: Thursday, March 02, 2006 12:02 PM
	To: [e-mail]
	Subject: (s22-list) FW: [AVT] Carrying SMPTE TimeCode in RTP
	
	
	Anyone want to comment?
	 
	Bill

		-----Original Message----- 
		From: [e-mail] on behalf of Colin Perkins 
		Sent: Thu 3/2/2006 12:23 PM 
		To: Dave Singer 
		Cc: [e-mail] 
		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
		[e-mail]
		https://www1.ietf.org/mailman/listinfo/avt
		

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