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

["Allison, Art" <AAllison at nab.org>]

That may accomplish your purpose. 
That method requires reassembly for a device rebuilding the time code
(and disassembly at the source).
Complexity or efficiency?
But it is hard to see how it can be asserted that is carrying SMPTE time
code if parts are here and parts are over there.    
_____________
Art Allison
Director, Advanced Engineering
Science & Technology
National Association of Broadcasters
1771 N Street, NW
Washington, D.C. 20036
Phone: 202.429.5418
Fax: 202.777.4981
aallison at nab.org

The National Association of Broadcasters is a trade association that
advocates on behalf of more than 8,300 free, local radio and television
stations and also broadcast networks before Congress, the Federal
Communications Commission and the Courts.

-----Original Message-----
From: Colin Perkins [mailto:csp at csperkins.org] 
Sent: Thursday, March 02, 2006 3:39 PM
To: Miller, William C
Cc: avt at ietf.org
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: owner-s22-12m at eng.smpte.org on behalf of Peter Vince
> Sent: Thu 3/2/2006 2:13 PM
> To: s22-12m at eng.smpte.org
> 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: peter.vince.01 at bbc.co.uk
>
>
> -----Original Message-----
> From: owner-s22-list at eng.smpte.org [mailto:owner-s22- 
> list at eng.smpte.org] On Behalf Of Miller, William C
> Sent: 02 March 2006 18:02
> To: s22-list at eng.smpte.org
> Subject: (s22-list) FW: [AVT] Carrying SMPTE TimeCode in RTP
>
> Anyone want to comment?
>
> Bill
> -----Original Message-----
> From: avt-bounces at ietf.org on behalf of Colin Perkins
> Sent: Thu 3/2/2006 12:23 PM
> To: Dave Singer
> Cc: avt at ietf.org
> 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
> avt at ietf.org
> 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
> avt at ietf.org
> https://www1.ietf.org/mailman/listinfo/avt


_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt

_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt