|
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
|