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

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

And wrt many times per frame.???.. once per frame would seem to match
rather well. 
Is there not a means to determine that a packet belongs with a
particular frame? <even if it arrives a bit late>

_____________
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