This is why people hate fractional frame rates

[Phil Rhodes]

A minor example.

 

Here is the computer code required to derive a timecode in hh:mm:ss:ff format from a frame count at 25 frames per second, with no drop frame involved:

 

				frames = FrameCount;
			seconds = (int)Math.Floor((double)(FrameCount / IntRate));
			frames -= (seconds * IntRate);
			minutes = (int)Math.Floor((double)(seconds / 60));
			seconds -= (minutes * 60);
			hours = (int)Math.Floor((double)(minutes / 60));
			minutes -= (hours * 60);

 

And here is the code required to derive that same timecode from a frame count at 29.97fps with drop-frame timecode, using a few tricks to achieve a reasonably efficient algorithm that doesn't have linear complexity with the number of frames in the clip:

 

				int dropInTenMinutes;
			int dropInEachMinute;
			int nonDropInEachMinute;

			if (FrameRate == FrameRates.Rate5994)
			{
				dropInTenMinutes = (int)DropFramesInTenMins.Rate5994;
				nonDropInEachMinute = 60 * 60;
				dropInEachMinute = nonDropInEachMinute - 4;

			}
			else if (FrameRate == FrameRates.Rate2997)
			{
				dropInTenMinutes = (int)DropFramesInTenMins.Rate2997;
				nonDropInEachMinute = 30 * 60;
				dropInEachMinute = nonDropInEachMinute + 2;
			}
			else
			{
				Console.WriteLine("Timecode: SetFramesSinceMidnight: cannot figure drop-frame timecode for frame rate " + FrameRate);
				return;
			};

			hours = minutes = seconds = frames = 0;

			// If we have more than ten minutes worth of frames, keep chopping ten
			// minutes off until we don't and increment the minutes count to suit.
			// We'll deal with turning multiples of 60 minutes into hours later.

			while (FrameCount > dropInTenMinutes)
			{
				minutes += 10;
				FrameCount -= dropInTenMinutes;
			}

			// Now we have less than ten minutes' worth of frames left and these
			// frames are guaranteed to start on a 10 min boundary (including zero).
			// So, snip off a minute's worth of frames (at the first two dropped 
			// rate) up to nine times.

			bool FoundNineMinutes = true;
			for (int i = 0; i < 9; i++)
			{
				if (FrameCount >= nonDropInEachMinute)
				{
					FrameCount += dropInEachMinute;
					minutes--;
				}
				else
				{
					FoundNineMinutes = false;
					break;
				}
			}

			// If we got through all that and still have more than a minute's worth left, 
			// it is a "don't drop any frames" minute.

			bool FoundTenthMinute = false;
			if (FrameCount >= nonDropInEachMinute)
			{
				FrameCount -= nonDropInEachMinute;
				minutes++;
				FoundTenthMinute = true;
			}

			// Figure number of residual seconds

			while (FrameCount >= IntRate)
			{
				FrameCount -= IntRate;
				seconds++;
			}

			// Sort out hours

			while (minutes > 59)
			{
				hours++;
				minutes -= 60;
			}

			// Wrap days

			while (hours > 23)
			{
				hours -= 24;
			}

			frames = FrameCount;

 

This is all the reason I think we need to build time machines, in order to go back and head off the technical decision which caused this.

 

Yours banging his head against the monitor screen;

 

Phil

[Paul Bruening]

LOL

[Michael Collier]

How dare you question the great and all powerful SMPTE engineers of 1953! Blasphamy. Look, if you can't recognize the brilliance of drop-frame time code, then your a lost soul.

 

You can always stick it to them by creating your own drop-base standard, and make it even more goofy and complicated than the original.

 

What is this for by the way?

[John Sprung]

Actually it was the second National Television System Committee -- NTSC-II. What happened is they discovered a herringbone interference pattern due to a beat frequency between the audio and chroma subcarriers. They could have moved either one of them to fix it, and by only a tenth of a percent. Unfortunately they chose to move chroma, which forced them to also shift the line, field, and frame rates. They didn't see any reason not to, while moving the audio carrier was a very slight risk of being out of range for some of the existing B&W TV sets. Nobody at that time could imagine that some day we'd have time code and be able to assign unique numbers to frames of video. Of course, if they had got it right, we wouldn't even be thinking about it today. It always makes me wonder what dumb mistakes we're making now that'll bite the grandkids in the tush.

 

 

 

 

 

 

-- J.S.

[Saul Rodgar]

It always makes me wonder what dumb mistakes we're making now that'll bite the grandkids in the tush.

 

Uh Oh. Lets try and limit that discussion to cinematography-related mistakes. :P

[John Sprung]

Uh Oh. Lets try and limit that discussion to cinematography-related mistakes. :P

 

Yes, of course, I was thinking of the various standards that have recently been carved in stone..... ;-)

 

 

 

 

 

-- J.S.

[Saul Rodgar]

Yes, of course, I was thinking of the various standards that have recently been carved in stone..... ;-)

 

-- J.S.

 

I think that creating digital masters only of many recent digitally acquired movies is something that will bite back hard later. I mean, the ones that are released on film, well those may be fine 75 years from now, if properly kept. But all of the direct to video movies, how long will someone keep migrating those files to newer storage technologies?

 

Today we are able to rescue 8mm and 16 mm home movie footage of 50, 75 years ago (respectively), footage that sometimes has been kept in the worst possible storing conditions, footage that is restored and transferred, unless it is really badly mangled. I suppose the advent of solid state, non-spinning hard drive technology will make that somewhat manageable if stored properly.

 

And then add that to the fact that every few years there are vast improvements in regards to codecs and such. How many "legacy" codecs and formats will be supported in the future. Just try taking once ubiquitous 2 inch Quad video tape to any TV station and see the reaction, etc.

 

Also, a lot of the newer HD and data cameras are utilizing more and more exotic file formats that also will be hard to archive. For example, P2 technology is somewhat established as a production format. But it necesitates to be transferred to at least DVCPRO HD tape to be delivered to a TV station and archived. But for those indies who archive to hard drive only, well, eventually their hard drives will croak and with them perhaps the digital masters of many projects.

[Dominic Case]

This is all the reason I think we need to build time machines, in order to go back and head off the technical decision which caused this.

There's a Catch 22 in your time machine plan, Phil.

 

Going back over 57 years, you will need to set the destination time on your machine quite accurately. You need to arrive at the relevant NTSC meeting promptly. A quick calculation tells me that drop frame vs non-drop frame can account for roughly 20 days and 20 hours difference - that is, possible error in your calculation.

 

Now, you'll need to be sure you've got that right AND allow for 13 or 14 leap years since then. As well as the time difference across the Atlantic.

 

If you can do all that, then you can probably solve the problem today without going back.

 

Where were you during the Y2K scare?

:lol:

 

And by the way, what genius was responsible for setting British mains frequency to 50Hz half way through the last century, thereby setting a natural frame rate of 25fps for PAL TV, when cinema was already by then standardised at 24 fps? Or vice versa? Couldn't they see that the two numbers would eventually need to be the same? :P

[Jim Hyslop]

It always makes me wonder what dumb mistakes we're making now that'll bite the grandkids in the tush.

Don't have to wait for the grandkids for this one: keeping the 29.97 frame rate in HD.

 

They had a perfect opportunity to lose that PITA, but noooooo - they have to pervert the 30fps to 29.97. I really wish some smart engineers had stood their ground and said "No! Lose the fractional frame rate!"

 

--

Jim

[John Sprung]

I really wish some smart engineers had stood their ground and said "No! Lose the fractional frame rate!"

 

We tried, on that and on a lot of more important things. What won out was the need to feed the dual infrastructure during the transition. It's those legacy TV sets yet again.

 

 

 

 

-- J.S.

[John Sprung]

And by the way, what genius was responsible for setting British mains frequency to 50Hz half way through the last century, thereby setting a natural frame rate of 25fps for PAL TV, ...

 

Yes, and how did we end up with 60Hz?

 

One odd little thing: Out here in LA, we had a mix of both 50Hz and 60Hz in different parts of the city up until 1937. That's when DWP changed everything to 60. They had a problem with electric clocks in doing that. The DWP paid to have people's 50Hz clocks modified or replaced.

 

 

 

 

 

-- J.S.

[Hal Smith]

There's a Catch 22 in your time machine plan, Phil.

 

Going back over 57 years, you will need to set the destination time on your machine quite accurately. You need to arrive at the relevant NTSC meeting promptly. A quick calculation tells me that drop frame vs non-drop frame can account for roughly 20 days and 20 hours difference - that is, possible error in your calculation.

 

Now, you'll need to be sure you've got that right AND allow for 13 or 14 leap years since then. As well as the time difference across the Atlantic.

 

If you can do all that, then you can probably solve the problem today without going back.

 

Where were you during the Y2K scare?

:lol:

 

And by the way, what genius was responsible for setting British mains frequency to 50Hz half way through the last century, thereby setting a natural frame rate of 25fps for PAL TV, when cinema was already by then standardised at 24 fps? Or vice versa? Couldn't they see that the two numbers would eventually need to be the same? :P

 

"Back to the Frame Rate Future"?

 

Now I need to find my DVD of BTTF and see if there's a DF setting on the controller in Doc's Delorean.

[Dominic Case]

Yes, and how did we end up with 60Hz?

Probably nothing more than the inherent American need to be different ;)

 

In the UK, I believe that 50Hz was settled when the National Grid was first hooked up when(obviously) there was a need to standardise the frequency. And I believe that was in the 1920s, but I suspect it is probably a more complicated story than that.

 

It's actually a testament to SMPTE that the 24fps cinema frame rate (and other standards) remained universal for so long. If it was the Society for Mains Power Transmission of Electricity, things could have been more uniform.

[Brian Drysdale]

Probably nothing more than the inherent American need to be different ;)

 

I'd heard that 60 HZ was supposed to be a "safer" frequency, but this could be just another urban legend.

 

I did a quick google and came up with this thread that has loads of theories.

 

http://www.physicsforums.com/archive/index.php/t-53692.html

[Jim Hyslop]

A minor example.

 

Here is the computer code required to derive a timecode in hh:mm:ss:ff format from a frame count at 25 frames per second, with no drop frame involved:

[...]

 

And here is the code required to derive that same timecode from a frame count at 29.97fps with drop-frame timecode, using a few tricks to achieve a reasonably efficient algorithm that doesn't have linear complexity with the number of frames in the clip:

 

[...]

Yours banging his head against the monitor screen;

 

OK, I finally had some time to sit down and work through the code. Your code actually does have linear complexity - the more frames there are, the more iterations your loops need to make. Here's the equivalent functionality from a C++ class I wrote. This function has constant complexity. I've added a couple of extra notes since this function is not in full context with the class declaration.

 

void SMPTETimeCode::GetTimeValues( unsigned & hours, unsigned & minutes, unsigned & seconds, unsigned & frames ) const
{
unsigned int fps, framesAdjust=1;
switch (mode_)
{
case FM_HD60: // 60i or 60p
	fps=60;
	framesAdjust=4;
	break;
case FM_30nom: // nominal 30fps; NTSC (29.97) will set fractional_ to true.
	fps=30;
	framesAdjust=2;
	break;
case FM_PAL:
	fps=25;
	break;
case FM_Film: // Film, or HD 24i/p.
	fps=24;
	break;
}

// NOTE: frames_ is a member variable containing the number of frames elapsed since midnight.
unsigned frameCount=frames_;

// NOTE: fractional_ is a boolean member variable indicating if the frame rate is whole  (false -> 24, 30, 60fps)
// or fractional (true -> 23.976, 29.97, 59.94 fps)
if ( fractional_ )
{
	unsigned wholeTens, partTens, wholeMins;
	//TODO: Determine the constants and drop pattern needed for 23.976 fps

	// Convert the frame count to the equivalent frame count for non-drop frame.
	// That way, we can just use the code at the end to calculate the time values.
	// To convert to the equivalent frame count in non-drop code, we have to add
	// 18 frames for every 10 minutes, plus 2 frames for every minute beyond a full
	// 10-minute mark (e.g. hh:32:ss;ff has 2 minutes beyond the ten-minute mark).

	// Find out how many full multiples of 10 minutes there are in this timecode.
	wholeTens= frameCount/17982;

	// partTens holds the number of frames left in the ten-minute block. The
	// maximum it can hold will be 9:59;29, since 17982 frames is 10:00;00.
	partTens = frameCount % 17982;

	// Each minute in a 10-minute block has 1798 frames, except the first
	// minute, which has 1800 frames. So, if we have more than two frames,
	// reduce the frame count by two so that we can simply divide by 1798
	// to get the number of minutes in the block.
	if ( partTens > 2 ) partTens -= 2;

	wholeMins= partTens/1798;

	frameCount += ( wholeMins*2 + wholeTens * 18 ) * framesAdjust;
}
frames = frameCount % fps;
frameCount /= fps;
seconds = frameCount % 60;
frameCount /= 60;
minutes = frameCount %60;
hours = frameCount / 60;
}

 

HTH (and apologies for taking this discussion into software development, not cinematography). Feel free to adapt and use this function if you want (that goes for anybody reading this message).

 

--

Jim

[Paul Bruening]

This is cool, Jim. I came up with the exact same numbers trying to solve the problem through hardware with a Mitchell, variable speed, camera motor. I failed the approach because I couldn't find a way to read rotations at 23.976 resolution.

 

I've copy and pasted your code for safe keeping. Thank you for permission to use it.

[Hal Smith]

............... It always makes me wonder what dumb mistakes we're making now that'll bite the grandkids in the tush.

 

Oh maybe a digital television standard that uses a modulation scheme that is absolutely incompatible with anything mobile? After all, who could possibly want to view over the air television in a moving camper, back seat of an SUV hauling kids, a hand held TV, etc.?

 

And...We're back to the 1948 future where even if the darn thing isn't moving reliable reception requires a rooftop antenna.

 

ATSC.....One letter different than NTSC and about ten new problems.

[John Sprung]

Actually they have mobile ATSC. It wasn't easy, but they're starting to deploy it.

 

 

 

-- J.S.