|
Bill/Colin:
Let's begin by asking: what, exactly, is the IETF
group wishing to carry? Is it the timecode sample of a given frame of
video? well then, how's about the audio? what is the application
targeted? if it is VOD or similar, then velocity and direction
information may also be useful. So, some additional background,
please!
Pat Waddell
Chair, SMPTE 12M Revision AHG
Colin,
I agree that would be wise. Pat, perhaps we should all look at
it.
Best regards,
Bill
-----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
|