I'm a software developer oriented at video programming. I mostly have knowledge about PAL environments where everything is integer accurate and easy to comprehend. However, I'm working on a project where I have to move into the vague world of NTSC video and thus need some advice how things work there
My question is about how the frame rate relates to time.. Here is an example:
As seen, for the 29.97 fps timebase the number of frames is not even.. How does one relate to this if someone specifies exactly 35 s of video? Obviously the exact number of frames does not exist and my guess is that the number of frames has to be rounded to an integer. In my example above, this would result in 35.0016 s if rounding the number of frames upwards to 1049, or 34.9683 s if rounding downwards to 1048 number of frames.
- 35 s of video in 25 fps timebase corresponds to exactly 875 number of frames (35 * 25)
- 35 s of video in 29.97 fps timebase corresponds to the fractional 1048.95 number of frames (35 * 29.97)
Is there any common practice for this? Should one always round in a specific direction (upwards)?
One frame more or less could seem like a small problem, but in some environments (broadcast in this case), it's important to use the exact number of frames.
Also, does anyone know how video duration is commonly specified, preferably in a production enviroment? Should I use the fractional number 29.97 for calculations, or does people calculate using 30 fps timebase? Do people involve timecode to specify the length of video? That seems a bit unnecessary..
Does anyone have any experience from similar problems?
Lot's of question, hope someone can answer them.
+ Reply to Thread
Results 1 to 30 of 31
The solution to this issue is drop-frame timecode.
The basic details are here. It keeps timecode in sync with realtime.
In practice if you type 01;01;00;00 into a proper broadcast editing system (such as Avid) it will take you to 01;00;59;28. The semi-colons are important. If were written as colons we would assume a 30 fps counting base and it will not be accurate to realtime.
Program duration in a professional production environment is specified in hours, minutes, and often seconds. In that environment shows do not end at fractions of seconds, even if that means there is a fraction of a second of black at the beginning or (more likely) end.
Last edited by smrpix; 27th Feb 2013 at 09:14.
Thanks for your answer smrpix.
I have read about SMPTE timecode, drop frame and non-drop frame. But it mostly makes me more confused. From what I read, timecode is not a way of measure time, but merely a way of addressing a frame by an unique identifier. This FCP7 manual explained it quite good.
Also, I read this page too which explains drop frame timecode.
Could you explain why entering 01;01;00;00 into Avid would take me to 01;00;59;28? If both the entered timecode and the returned timecode are drop frame, shouldn't the returned timecode be the one typed in?
Ok, so if program duration is specified in hours, minutes and seconds, how come a show cannot end at fractions of seconds? A show does have to be an integer number of frames (it is the smallest unit in video), that would make a 35 s long show to actually end at 35.0016 or 34.9683 depending on rounding method.
Please explain more
I suspect I am answering your technical questions with answers in-practice.
The 59:58 issue has to do with making machine readable edits that don't choke over "non-existant" frames. It probably has to do with the legacy of timecode giving over to control track at the edit point in the early days of frame-accurate editing. You'll have to explore the SMPTE archives to get an exact answer to that one.
I was careful NOT to say a show CANNOT end at a fraction of a second, but that it DOES not. Broadcast shows are built to end at exact seconds by convention, to circumvent precisely the issues you bring up.
Also, one would never round down, because that would cut off part of a show.
edit: The unit of measure is frames for both the individual program as well as the overall broadcast stream, so counting in ms isn't particularly meaningful. In practice, there are usually at least a few frames of black for a fade-in or fade out at either end of a show so there is some wiggle room.
Hope that helps a little.
Last edited by smrpix; 27th Feb 2013 at 10:29.
But here's a more realistic scenario. Let's say I'm supposed to deliver a :30 commercial with no fades.
In NTSC land that could mean 900 frames, 899 frames or 898 frames.
I would build a 900 frame spot and make damn sure there was no vital information that existed in only those last two frames.
Last edited by smrpix; 27th Feb 2013 at 11:04.
I was pointing out that the problem you refer to isn't limited to NTSC video. Obviously you have to round up or down. I don't know if there is a common practice.
By the way, the NTSC frame rate is 30000/1001, not exactly 29.97.
site I linked earlier explains this very good.
So, if a show is 1050 frames, converted to real time it becomes 35.0350 seconds (1050 / 29.97). But the timecode will show exactly 00;00;35;00 (if my calculations are correct .)
Thank you for the answer!
edit: But, maybe this isn't a problem in NTSC? Thats what my question is all about i think..
An NTSC hour is a "real" hour, just like PAL. Timecode is based on a 24 hour clock.
IF you are looking at the # of frames, in either system PAL or NTSC, you cannot have fractions of a frame. In PAL, those occur at 1/25th of a second or 0.04sec. In NTSC, those occur at ~1/29.97th of a second (more accurately 1/29.97002997002997002997002997003 aka 1 / (30000 / 1001)) or 0.033366666666666666666666666666667 sec. If it's easier for your brain, use 1/30th of a second (0.033333333333 sec) and then understand that since the frames are slightly slower, they will each last slightly longer.
But as smrpix said: PAL has 90,000. exact frames in one hour. NTSC has 107,892. exact frames. Using "drop frame" timecode in NTSC, those 107,892. frames shows 01;00;00;00. Using non-dop, those 107,892. frames shows 3.6 seconds less: it would have to have 108,000. frames to show 01:00:00:00, which would be one hour+3.6 seconds in realtime.
Confusing, yes, but you get used to it. Now add 24FPS, and Fields into the mix!...
xcile, if you're willing to share, what's the nature of the project you're doing that raised these questions?
So can I make the conclusion that in an NTSC production environment (read FCP), when producing a 30 seconds ad, one set up the timeline to match the specification (NDF or DF), edits and expect the resulting number of frames to match up the desired ones?
In a broadcast environment df is the norm.
Also, files don't just start and end with the program. They have bars and tone, identification slates and countdowns at the beginning and extra black at the end. Once the spots are on the broadcaster's server, only the program portion of the file is displayed. Usually there is embedded metadata as well (closed-captioning and timecode, for example.)
A lot of material is still delivered on tape, HDCAM being common, but not universal. File based protocols, formats and requirements still vary widely -- XDCam, P2, and DNxHD again being common but not exclusive.
edit: originally said ndf, I meant, drop-frame is normal!
Last edited by smrpix; 28th Feb 2013 at 10:16.
Yes, I know about slates and black frames etc. But that's not part of the problem. The question is: How does one measure time in an NTSC production enviroment. This question is also independent of if the delivery is file or tape based.
If a delivery specification says 2 min and 30 seconds ( = 150 seconds) and I edit relying on NDF timecode (since it is the norm), then that would mean that I'm actually delivering 4500 frames which equals 150.15 real seconds. Then, how does the broadcaster deal with that 0.15 extra seconds delivered? In 1 hour it becomes approx 3.6 seconds.. In 1 day it sums up to 1 min and 26.4 sec. To me it seems they will have a constant delay of the programs throughout the day (unless they have a heavily modified DeLorean DMC-12 and are called McFly ..)
It is absolutely frame accurate.
That Adobe document is amateur stuff. If you want the real deal,
Start here: http://standards.smpte.org/content/978-1-61482-268-4/st-12-1-2008/SEC1.abstract?sid=b7...b-3e263deea48c
Last edited by smrpix; 28th Feb 2013 at 11:01.
When I say it isn't frame accurate I mean that the frame displayed in the timecode does not exactly correspond to when in real time the frame is displayed on the display device.
That's why broadcasters use genlocks, frame syncs etc.
To minimize the NTSC time error, the first two frame numbers (00 and 01) shall be omitted from the count at the start of each minute except minutes 00, 10, 20, 30, 40, and 50.
So just write your code to SMPTE specs and you're good to go.
Last edited by smrpix; 28th Feb 2013 at 12:06. Reason: too verbose