I agree that would be wise. Pat, perhaps we should all look at
it.
-----Original Message-----
From: Colin Perkins
[mailto:csp at csperkins.org]
Sent: Thu 3/2/2006 6:37 PM
To: Miller, William C
Cc: avt at ietf.org
Subject: Re: (s22-12m) RE: (s22-list) FW: [AVT] Carrying SMPTE
TimeCode in RTP
Bill,
Okay - if there are reasonable use cases where
the date can jump from
frame to frame, I'm not going to argue against
including it. That has
been listed as an open issue in the draft for
several months now
though, so it seemed there was no need to support
it. Perhaps someone
from SMPTE S22 could do a review of the entire
draft to ensure there
are no more such problems
waiting?
Colin
On 2 Mar 2006, at 21:15, Miller, William
C wrote:
> 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