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