Will 30 fps work when specs call for 29.97?

[Danny Winn]

30 fps and 29.97 fps are the same thing, my camera reads 30 fps when shooting but in reality it is shooting 29.97.

I am curious as to what format you are outputting to, because I use 29.97 exclusivly and all the export options in the Media Encoder do have a 29.97 option. Mpeg, Avi, WMV?

[Mike Schmitt]

That’s a relief!

They need 29.97 FLV with a keyframe every 60 frames.

F4V does not work.

[Tim Kolb]

Why is the file returning to 30.00fps? Are you trying to pick a preset after you’ve setup custom parameters?

(29.97 or 30.00 may make a difference in some web deployment situations…but I would think those situations would actually favor the nice round 30 fps as opposed to the analog-television borne 29.97…)

TimK,
Director, Consultant
Kolb Productions,

[Alex Udell]

Technically isn’t the frame rate the same?

Isn’t 29.97 short hand for “drop frame time code?” which is a method of counting frames, not a method of drawing them?

Alex

[Tim Kolb]

[Alex Udell] “Isn’t 29.97 short hand for “drop frame time code?” which is a method of counting frames, not a method of drawing them?”

Drop frame timecode was invented to accurately count elapsed time for 29.97 frames per second…that’s why drop frame timecode exists.

Video frame rates were originally set up to the electrical system the television system was using…The USA (as well as other countries) had a 60 Hz power grid so 30 fps (60 interlaced fields) made a nice synchronization and it just minimized the conflicts between frame refresh and power frequency. PAL is 25p/50i because the electrical system in the countries that adopted it was running at 50 Hz instead of 60 Hz. (PAL also has 100 more lines of resolution…France actually broke away with SECAM and were experimenting with broadcasting 1000 line plus images right after World War II…but that’s a story for another time.)

When it came time to add color to black and white in the NTSC… (PAL standards were established later and therefore were better prepared for color images and until the recent advent of digital television, PAL SD images simply slaughtered NTSC SD for accurate, high quality color rendition…but once again, I digress)…a compromise had to be made if that huge installed base of Black and White televisions were not to be made instantly obsolete. Americans may be the most backwards compatible culture there is in some of these areas (some would say that “compatible” is not a necessary component to that description), and TV was one of the biggest examples.

In order to create color images that color TVs would see, but maintain B&W images that older sets would see, the color would have to be a “layer” that the black and white sets could simply ignore. If you look at your waveform monitor while looking at an analog NTSC signal, you’ll see that small vertical rectangle that straddles the line at 0 which comes in between the frames…that’s the “burst”…which is the modulated color signal. If you look at a waveform and see no burst, the image you are viewing will be black and white as the “color layer” that gets laid on top isn’t there…

Well…this color information was…more information. Since the outgoing signal couldn’t simply be structured as a color signal natively, the color info was added to the information stream…which took some space. Since the FCC wasn’t willing to re-issue broadcast licenses for a “channel and a half” of band-width…the solution had to be something done serially.

Slowing the frame rate by 3/100ths of a second allowed the necessary space to stick in this murky color overlay so that it could be used by color sets, but the framerate was still usable by the existing 30fps black and white sets. It’s why “analog component video” in NTSC terms is still one Y’ channel (the black and white signal) and the metaphorical longitude and latitude color coordinate system “Cb and Cr” (digital) and “Pb and Pr” (analog…Sony also labels them as R-Y and B-Y) to add a given hue and saturation to each luma pixel (SVHS separated composite into “Y” and “C” in the cable, but it was still just a more cleanly handled ‘composite’ signal) as opposed to an RGB additive system, which would store the information with far better quality albeit a higher data load, all things being equal…

The problem with 29.97 frames per second is that you still need 30 frame numbers to account for the images that occur every second, but you end up with an accumulated error…about 3.6 seconds every hour, amounting to well over a minute a day. Mistakes that would happen because of the error could cost lots of money in botched air slots, etc. A minute is two commercials and each commercial is revenue for the TV station and when it comes to money…broadcasters respond.

By removing (“dropping”) the first two frames (XX;XX;XX;00 and XX;XX;XX;01) from every minute EXCEPT each tenth minute, you create an incremental correction that keeps the studio clock and SMPTE timecode on the same page throughout the broadcast day.

When it comes to web-based video, I have no idea why the OP’s client specified 29.97 other than they have some old TV dog like me who has no clue that the web doesn’t use fractional frame rates since there is no “color under” in Flash or H264…therefore I’d think deploying a video on the web would favor 30 fps even…but there may be some reason why the client uses DF timecode internally or something.

If you start the program out as being broadcast on television in a formerly “NTSC” system (there is no NTSC and PAL in HD, only framerates, even though some professional equipment manufacturers still label their stuff that way)…then you have to have 29.97 and DF timecode because even though we no longer have a need for the stupidest video framerate decision ever made (ooops…did I type that out loud?) as digital television no longer needs to allow for this…we have to be the most backwards compatible culture ever…

Therefore the framerate compromise we (NTSC countries) made in 1953…still haunts us today.

Don’t even get me started on why American NTSC black is 7.5 IEEE gray…

It may sound like I’m old and cranky, but really…

oh, excuse me…

I need to get my walker over to the window and yell at some kids on my lawn…

TimK,
Director, Consultant
Kolb Productions,

[Alex Udell]

Tim…we are saying the same thing….you said it much more verbosely.

It takes longer than 1/30th of a second to draw the frame. (due to the technical reasons you cited)

So the method of counting frames to stay accurately within real time hours, minutes, seconds and frames, numbers are periodically skipped (or more precisely dropped) from the tally.

So this works out (when averaged) to 29.97 fps.

but there is NEVER a case where a frame is only .97 drawn.

that’s what I was saying.

so we agree on the question is…why would this have an affect on WEB output?

Alex

[Tim Kolb]

[Alex Udell] “…you said it much more verbosely.”

🙂

I get that a lot…

However, i am never accused of being vague.

My only thought would be if the client is somehow connected to terrestrial broadcasting and they have some desire to have the frame count reflect drop frame timecode…

But, my earlier post asks the same thing…I would think that 30fps would be far simpler.

TimK,
Director, Consultant
Kolb Productions,

[Jeff Brown]

But– to reiterate (and perhaps flog the proverbial horse): 29.97 is not the same as 30. It is running at a different rate. Frustratingly and maddeningly close, but different. Which will be made painfully aware to you (the generic/editorial “you”) should you ever hand an audio post person files that are a mix of 29.97 and (true) 30 FPS. Same thing goes for mixing 24 and 23.976 FPS files: bad idea.

To add to all the confusion, cameras and other devices identify NTSC 29.97 as “30 FPS.” Oy. (damn kids!)

-Jeff

Jeff Brown
Fire Mist Media
http://www.firemist.com

Workstation:
Boxx 8700 dual-quad
4 GB RAM
nVidia Quadro FX 4500
WinXP Pro
AJA Xena 2K
CalDigit HDOne

Main Software:
3ds Max
Combustion
Photoshop
PremierePro

[Stanton Kellam]

This has to be the most comprehensive and thorough answer to any question I have ever seen answered online. Thank you!