Subject: [AVT] Re: Comments, draft-pfeiffer-temporal-fragments-00

From: [email-masked]
Date: Mon, 17 Mar 2003 15:15:22 +1100

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