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:csp at csperkins.org]
Sent: Thu 3/2/2006 3:38 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