Subject: [AVT] RE: (s22-list) Re: Comments, draft-pfeiffer-temporal-fragments-00

From: "Oliver Morgan" <[email-masked]>
Date: Sat, 3 May 2003 16:39:57 -0400

Dear Ms. Pfeiffer and Mr. Parker,

I have read and concur with Bill Miller's comments on your draft on
temporal fragments.

As an additional input, you might like to contemplate recommending a
notation for fragments of known duration.

It is conventional to express these in television systems as two SMPTE
timecodes, an IN and an OUT time. The IN time specifies the first frame
or field that is included in the interval; the OUT time specifies the
first frame or field that is *not* included in the interval.

Thus an interval of duration 10 frames might be specified as
#@smpte=01:00:00.00-01:00:00.10

best regards
Oliver Morgan
Metaglue Corporation
+1 781 862 2106 voice/fax
+1 781 962 3997 cell
[email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> Sent: Sunday, March 16, 2003 11:15 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: (s22-list) Re: Comments, draft-pfeiffer-temporal-fragments-00
> 
> 
> Dear Mr. Miller,
> 
> I am delighted to get feedback from you and the SMPTE 
> community on our 
> timed URI fragment specification proposal. I would like to thank you 
> very much for your well elaborated comments which we are more 
> than happy 
> to include into our proposal.
> 
> We will be developing another version of the document over 
> the next few 
> weeks. If I may, I would like to forward you the next 
> version, just to 
> make sure we haven't overlooked anything.
> 
> Also, in case there are any relevant changes in the new 
> version of SMPTE 
> 12M, I would be very happy if you could make me aware of them.
> 
> Thank you very much indeed.
> 
> Best Regards,
> 
> Silvia Pfeiffer.
> 
> 
> Miller, William C wrote:
> > Dear Ms. Pfeiffer and Mr. Parker,
> > 
> > Your draft was recently passed on to me by a SMPTE 
> colleague.  I'd like 
> > to offer a couple of comments.  I am not familiar with all of the 
> > practices of the IETF community, so forgive me if I commit 
> a solecism or 
> > two along the way.
> > 
> > I'm chairman of SMPTE S22, the TV Systems Technology 
> Committee, which 
> > has responsibility for SMPTE time code.  I'm writing as an 
> individual 
> > commenter.
> > 
> > 1.  SMPTE has about 400 Standards, Recommended Practices 
> and Engineering 
> > Guidelines, of which SMPTE time code is just one.  The 
> reference you 
> > should cite is SMPTE 12M-1999, Time and Control Code.  Be 
> aware that we 
> > are in the process of considering revisions to this document.
> > 
> > 2.  The current version of SMPTE 12M defines time code for 
> 24, 25 and 30 
> > frames per second (fps).  Video production standards for 
> all of these 
> > exist and are in use.  A drop-frame mode is defined for 30 
> fps (actually 
> > 30/1.001 fps) to cover 525-line systems (NTSC 
> time-compensated mode).  
> > However, there are now 50,  60 and 60/1.001 fps video production 
> > standards, and practices have evolved to deal with these within the 
> > structure of SMPTE 12M.  These practices will be added to 
> 12M as it is 
> > revised.  A possibility also exists that there will be 
> 24/1.001 fps video.
> > 
> > To be safe you should define syntax to handle all 8 of 
> these rates (all 
> > are allowable under MPEG-2, for instance).  Recapping them in order:
> > 
> > 24/1.001 "24-drop" (this algorithm is not defined)
> > 24
> > 25
> > 30/1.001 "30-drop"
> > 30
> > 50
> > 60/1.001 "60-drop" (same algorithm as 30-drop, but 4 frames dropped 
> > rather than 2)
> > 60
> > 
> > Your draft gives 30 fps (non-drop) as the default; in 
> practice this is 
> > the least likely frame rate to be encountered.  I believe it is 
> > preferable to require explicit coding of the frame rate, e. g. 
> > "smpte-30-time".  "smpte-time" should be allowed only for 
> those cases 
> > where the user does not know the frame rate; this would 
> serve as a wild 
> > card, with best-effort address resolution (the error would 
> be no more 
> > than one second, typically much less).
> > 
> > 3.  Although not generally understood as such, SMPTE time code is a 
> > label.  Its lowest granularity is the frame for 
> progressive-scan and 
> > film material and the field for interlaced material.  
> Fractional frames 
> > (fields) are meaningless for video, and in the case of the 
> /1.001 rates 
> > are ambiguous for audio.  I urge you to delete "smpte-sf".
> > 
> > 4.  The first frame of video of a program is normally 
> 01:00:00:00, not 
> > 00:00:00:00.  This practice arose from the requirements of program 
> > production and analog videotape recording technology, and it has 
> > subsequently become a uniform, almost ironclad practice worldwide.  
> > Users should be made aware of this in an informative note.
> > 
> > I hope these comments are of help in refining your draft.  I am 
> > attaching a copy of SMPTE 12M for your use.  Please do not 
> redistribute 
> > it except to those involved in the development of this RFC.  Thanks.
> > 
> > If I can be of further help please let me know.
> > 
> > Best regards,
> > Bill Miller
> > 
> > 
> > 
> > William C. Miller
> > ABC-TV
> > 212-456-4448
> > 212-456-2284 fax
> > [email-masked]
> > 
> 
> 

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: [email-masked]
Date: Tue, 06 May 2003 13:54:22 +1000

Dear Mr. Morgan,

Thank you very much for your eamil. I have had several requests from 
other people on exactly that same extension. As there seems to be a need 
for this extension, we can include it into the I-D as an option. The I-D 
is currently getting discussed at [email-masked], but is still in its early 
stages of discussion. I hope to publish an updated version of the I-D soon.

Best Regards,

Silvia Pfeiffer.