[opendtv] Re: Half Truths - Was More 1080p@60
- From: "John Willkie" <johnwillkie@xxxxxxxxxxxxx>
- To: <opendtv@xxxxxxxxxxxxx>
- Date: Fri, 7 Dec 2007 15:56:11 -0800
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.
----------------------------------------------------------------------
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:
