[opendtv] Re: Half Truths - Was More 1080p@60

  • From: Tom Barry <trbarry@xxxxxxxxxxx>
  • To: opendtv@xxxxxxxxxxxxx
  • Date: Fri, 07 Dec 2007 19:23:19 -0500

Actually I work on commercial broadcast automation software, including a couple of applications that do that cutting you mention. But I've never had to go into that part of the code to see how it does it. Maybe I will when I get the chance. 


- Tom

John Willkie wrote:

Tom;

I told you before -- it's not the "long run" that counts, it's EACH FRAME.
If you are simply cutting a program at the end of 30 minutes, your approach
would work.

Ever watch TV?  You'll note that there are many cuts within a minute.  Each
one of those is matched up with time code.  (This is without worrying about
the 1 in 4 four limitation on a cutting -- with some editors -- only at the
boundary of a color sequence in NTSC.)

Your approach would mean that after assembling a program using many short
cuts, the editor would have to go back and possibly trim the assemblage to
fit the allotted time.  And, they'd be s-o-l, since they might have to
assemble the whole piece again.

John Willkie

-----Mensaje original-----
De: opendtv-bounce@xxxxxxxxxxxxx [mailto:opendtv-bounce@xxxxxxxxxxxxx] En
nombre de Tom Barry
Enviado el: Friday, December 07, 2007 3:36 PM
Para: opendtv@xxxxxxxxxxxxx
Asunto: [opendtv] Re: Half Truths - Was More 1080p@60
This all seems more confusing then it should have to be, so maybe I'm missing something here.
First, 30/1.001 is not an irrational number since it is exactly equal to 30000/1001 and an irrational number is a real number that cannot be expressed exactly as a fraction n/m of two integers.
But more practically if you started with 24fps video and just regularly counted frames, always dropping the last one out of every 1001 then it seems that, at least in the long run you would be exactly correct, with no cumulative errors. And it would also be exactly correct every 41.8 (1001/24) seconds or so. Wouldn't that be better than every 2 minutes?
So I don't understand the fancier stuff, unless you just want to force it into a repeating exact pattern of minutes for some reason. 

- Tom

John Shutt wrote:
----- Original Message ----- From: "Manfredi, Albert E" <albert.e.manfredi@xxxxxxxxxx> 


Yes, but I didn't get why 23.976 is not the way this is always done.

Drop either 1 frame on 1001, or 1 frame in 1000, in a 24 fps stream, and
the resulting frame rate will be  either
23.976023976023976023976023976024 or 23.976000000, respectively. So why
is this 23.976 frame rate a surprise?



We're not dropping frames, Bert, we're dropping frame counts.

Color NTSC is not really 29.97.  It has a framerate of 30/1.001 which is


an
irrational number. "NTSC friendly" 24p has a framerate of 24/1.001, also an 
irrational number.  Both are shortened to "29.97" and 23.976" because for
most cases it's close enough, conveys the true meaning behind it, and is
easier to say and write than "30/1.001" or "24/1.001" all the time.

For frame accurate editing, the only criteria is that each and every frame
have a unique and predictable number associated with it. You can (and early 
editing systems did) just number the frames from 1 to n.  If you are at
frame number 2,405, you know that the next frame will be 2,406.  Or you


can


count by using HH:MM:SS:FF.  If the current frame is 12:14:06:28, you know
the next frame will be 12:14:06:29.

30/1.001 (29.970029970029 as you say) can also use the same HH:MM:SS:FF
frame counting, and often does.  This is non-dropframe timecode.

The only problem with non-dropframe timecode is that although the timecode
numbers uniquely and predictably identify each and every frame of video, the hours minutes seconds scheme no longer reflects the actual time it will take 
to play back in real time.
This is not a problem with :30 spots, but a 30 minute program will be off by 
a few frames.  In 30 minutes, there are precisely 54,000 30 fps frames.


In


the same 30 minutes, there are only 53946.05395 29.97 fps frames.  So, if
you just used the normal non-dropframe timecode scheme to assign a value


to


every frame in that "30 minute" program, the timecode of the last frame of
the 30 minute 29.97 fps video would be "00:29:58:06", even though it took
exactly 00:30:00:00 to play the video back.

Therefore, if you want the timecode values to correctly reflect the amount
of time it would take to play the video, you need to adjust the timecode
numbers so that the 29.97 fps video keeps relative lock with real time. If
you do, then when the first frame count is "00:00:00:00" and the last


frame


count says "00:30:00:00," you know it will take exactly 30 minutes to play
it back.

There are approximately 1.7982 fewer 29.97 frames per minute than there


are


30 fps frames. (1800 vs. approximately 1798.2018.)  Therefore, in order


for


the timecode count of 29.97 fps frames to line up with the real time it
would take to play back those frames, you need to skip some numbers.  The
easy way is to see that there are 17.982018 fewer 29.97 frames every 10
minutes than 30 fps frames.  Therefore, in a ten minute period you need to
skip counting 18 frames (nearest whole number, since you cannot count a
fraction of a frame in timecode) every ten minutes.

Remember, earlier I said one of the criteria of drop-frame timecode is


that
it has to be predictable. This is so editing controllers can calculate time and find the proper frame for in and out points. So the drop frame rule is: 

"Drop two frames every minute except every ten minutes."

So, if you start at zero, when you get to a timecode count of 00:00:59:29
(HH:MM:SS:FF), the very next frame of video will have the count 00:01:00:02. 
You skipped the counts of 00:01:00:00 ad 00:01:00:01.  You skipped two
frames.
The same thing happens at 00:01:59:29, 00:02:59:29, 00:03:59:29, etc. Until 
you get to 00:09:59:29.  At that time code, the very next frame of video
will have the count 00:10:00:00, because you do not skip any counts every
ten minutes.  Therefore, in ten minutes you've skipped 18 frame counts,


and


the drop frame timecode lines up with the real time it takes to play back
the video.
Last, if you are using non-dropframe timecode, it is customary to denote all colons in the timecode. If you are using drop frame, a semicolon is used to 
separate the seconds and frames:

HH:MM:SS;FF

Sometimes all of the punctuation is replace with semicolons:

HH;MM;SS;FF

With 24/1.001 fps video, the concept of drop-frame timecode is the same:
You want the timecode numbers on the video to match the real time it would
take to play back that video.  I presume that Russ' customers want the
running timecode numbers to match the actual running time of the material,
but as far as I am able to tell there are no hard and fast (therefore
predictible) rules for calculating drop frame timecode for 24.976 fps video. 

So let's try to make one.

There are 1440 24 fps frames per minute, there are only approximately
1438.561439 23.976 fps (or more accurately 24/1.001 or 23.97602398)


frames.


Therefore, in order to keep the timecode count in alignment with real


time,


you need to drop 1.438561 frames per minute, or 14.38561 frames every ten
minutes.  Not as simple and elegant a problem as we had with 29.97 fps
video.

What Russ came up with, and what I independently came up with, was to drop
one frame in the first minute, two frames in the second minute, one frame in 
the third minute, two frames in the fourth minute, etc.  In this way, you
will drop 14 frames in the first ten minutes, 15 frames in the second ten
minutes, 14 in the third ten minutes, 15 in the fourth ten minutes, etc.
Your desired number of frames to drop every ten minutes is 14.386 frame,


so


you are "bracketing" the target number.
However, after a certain time, you drift away from real time because you are 
dropping an average of 14.5 frames per ten minutes, when you really want


to


drop only 14.386 frames every ten minutes.

Russ came up with a list of exception minutes and hours that when taken
together would have corrected to within one frame per 24 hour period, but


I


thought the list of exceptions was unwieldy and hard to memorize.

I came up with a simpler rule that said to drop only one frame instead of
two frames every odd tens place of minutes (1x, 3x, 5x, etc.), and to drop
only one frame instead of two frames every odd hour. This scheme is easy to 
remember, easy to calculate or predict what the next timecode count should
be, and keeps you within 4 frames in a 24 hour period.  My rule:

"Drop one frame every even minute, drop two frames every odd minute,


except


drop one frame every odd tenth minute, except drop one frame every odd
hour."

Therefore, at count 00:00:59:23, the next count would be 00:01:00:01,
skipping one frame (frame number 00:01:00:00.) because the minute was odd
(at 01 minute.) At count 00:01:59:23, the next count would be 00:02:00:02,
dropping two frames, because the minute was even.

At count 00:09:59:23, you might think you need to drop two frames because
the next minute mark would be "10" which is even, but the tens digit of


the
minute count is odd, so you would drop only one frame. The next count would 
be "00:10:00:01."

Ditto at count "00:59:59:23."  You might think you need to drop two


frames,


because the tens column of the minutes is even (0 is treated as even), but
because the hour count is odd (01) you drop only one frame.  The next


count


would be "01:00:00:01."
However, at "01:59:59:23", the next count would be "02:00:00:02" because the 
ones of minutes column is even, the tens of minutes column is even, and


the


hours column is even.

Confusing, but predictable and I think workable if you use it daily.  With
this scheme, you're off by 4.472 frames at the end of a 24 hour day.

As I said, with 23.976 HD video being shot daily, a formal SMPTE/EBU


scheme


for drop frame timecode is sorely needed, and would make an excellent


paper


for the SMPTE.




----------------------------------------------------------------------
You can UNSUBSCRIBE from the OpenDTV list in two ways:
- Using the UNSUBSCRIBE command in your user configuration settings at FreeLists.org - By sending a message to: opendtv-request@xxxxxxxxxxxxx with the word unsubscribe in the subject line. 







--
Tom Barry                  trbarry@xxxxxxxxxxx  



----------------------------------------------------------------------
You can UNSUBSCRIBE from the OpenDTV list in two ways:
- Using the UNSUBSCRIBE command in your user configuration settings at FreeLists.org 
- By sending a message to: opendtv-request@xxxxxxxxxxxxx with the word 
unsubscribe in the subject line.

Other related posts:

  1. Home
  2. opendtv
  3. Archive
  4. 12-2007