QT calculation – Converting frames to milliseconds, coding question

[Rafael Amador]

Is not necessary to be Einstein to understand that you can not deliver “899 + 0.1” frames.
Is not necessary to be Einstein to understand that a 900 frames NTSC clip is longer than 30 secs.
[Doug Beal] “There is no real world measure for milliseconds in video it’s frames whether the frame rate is fractional as it is in Japan/North America and MPAL Brazil or integer frame rate for you PAL folks.”
This is absolutely wrong.
Video timing is measured not in milliseconds but in NANOSECONDS.
If you would have learnt NTSC on the school, the first you would have learnt, is the duration of a TV line in NANOSECONDS (64 nanoseconds inPAL. Is burned on my brain).
TC was introduced in video tapes 40 years after those specs were sets and when we are broadcasting there is not any TC involved.

Your maths (NTSC 30fps) are OK when you are buying or selling programs, out of that scenario, you are dead.
I understand that you don’t work in Broadcast, if so, you would be highly concerned for what happens with “that stray milliseconds at the end of the TV day”.
NTSC is 29,97 fps, even if this is too complicate to understand for the marketing guys.
rafael

http://www.nagavideo.com

[Ariane Fisher]

Doug, first of all, I’m female, although do still enjoy a hearty oatmeal stout. 🙂

Second of all, I completely and wholeheartedly, agree: measurement in milliseconds is a Quicktime contrivance. It doesn’t exist anywhere within FCP nor the real world. It does, however, exist in the mediainfo file of uploaded Quicktime files. For whatever reason, Quicktime defaults to measurement in ms, not frames. I need to manipulate this data with java script, which does need frames. Well, actually java can handle ms, but I need frames back out. Now that I know the math behind the conversion factor, I think I’m good. Although that may be a premature assumption. I still need to calculate all this in cases of DF as well. But at least now I know where to find the information. Thanks again.

[Rafael Amador]

[Ariane Fisher] ” measurement in milliseconds is a Quicktime contrivance. It doesn’t exist anywhere within FCP nor the real world.”
Again Ariane, this is fully wrong. What is not the real world at all is QT and FC.
This a portion of the Vertical Blanking on an NTSC signal:

As you can see the time is expressed in milliseconds and nanoseconds.
This was set like that before computers existed.
QT and FC doesn’t needs to shows nowhere milliseconds because they run on video standards which are already based on this time unity.
The precise timing is on the NTSC manual.
rafael

http://www.nagavideo.com

[Ariane Fisher]

Ok, Rafael. You win. Hyperbole always gets me in the end. 🙂

[Doug Beal]

I’m glad to hear you have found a solution. was it the tequila or the oatmeal stout? I think an oatmeal stout sounds great right now.
All the best to you
db

Doug Beal
Editor / Engineer
Rock Creative Images
Nashville TN

[Andreas Kiel]

This is an interesting thread. Her my 2cents.

I think the first question from Ariane was a bit misleading as she mixed up 24 NTSC and 24.
Otherwise it’s very simple.
For NTSC time the calulation has to be ((20*24+5)/24)*(1001/1000) -> 20.22854166666. So the media info from the server is correct.
If there will be true 24, the calculation must be (20*24+5)/24) -> 20.20833333333

I’m not sure what Ariane meaned by “When I open it in QT…”. With QT Player Pro I get displayed 20.22 – which is rounded down, but more or less correct. But also 20.27 is correct it just depends on way how you look at it. This time takes the time of the frame after the last frame, so it includes one frame more to calculate with results in 20.27.

If you do it with QT code it will give you the same results.
To address a frame’s time for example the last (485 * 1000)/23976 -> 20.2285618952 this includes some rounding error as 23976 is rounded.

In this case 1000 is the internal frame duration of this special example QT movie. The values used apply to any QT file created with FCP — except the frame number.
For 29.97 the frame duration will be 100 and timebase is 2997, for PAL and other non NTSC movies frame duration is always 100 and timebase is 100*FPS – with FCP QT movies.

Other apps might use a different timebase. An old fashioned one is 600 as it can be divided by 12 and 15 for stop motion, by 24 for film and 30, 60 for NTSC non drop.
So to calculate time from an unknown movie you have to retrieve and verify timebase and frame duration.

Andreas

Spherico
https://www.spherico.com/filmtools

[Andreas Kiel]

I did hit the post button by chance a bit to early.

Here some additions.
To explain the 20.27 a bit more detailed. You got 485 frames (with this example. Frame count starts at 0, so frame time is 0*100, frame 485 is 485*100. If you go to the end of frame 485 the time is 486*100.

Also forgot to mention that 600 can be divided by 25 for PAL.

Andreas

Spherico
https://www.spherico.com/filmtools

[Ariane Fisher]

What? You guys can’t read my mind about the true 24 vs. NTSC thing? I knew what I meant. 🙂

Andreas, thank you so much for explaining the discrepancy in the results between desktop and online.

[Andreas Kiel] “In this case 1000 is the internal frame duration of this special example QT movie. The values used apply to any QT file created with FCP — except the frame number.
For 29.97 the frame duration will be 100 and timebase is 2997, for PAL and other non NTSC movies frame duration is always 100 and timebase is 100*FPS – with FCP QT movies.”

Would it be possible for you to elaborate on this? I’ve never heard the term “internal frame duration”. At a quick glance, it seems that this is a factor used to reconcile the 23.976 vs. 30 math. So, you’re using 1000 to get the 23.976 into an integer. With 29.97, you use 100 to make it an integer. If the media is true 24 or 30, no multiplier would be needed, as it’s already an integer. The discrepancy between desktop and online versions appears because they are not including the factor of 1/1.001, but simply truncating the result to 23.976. Did I summarize this correctly?

I will perform extensive calculations and testing of our online media over the next few days, so If you don’t hear from me, I either figured it out for all the crazy iterations for which I need it OR my brain exploded from overuse of algebra, division, or whatever operations these are.

By the way, I can’t thank you guys enough. Please let me know, if/when you’re ever in Chicago. I owe you all several beers. We can then discuss imaginary numbers, pi, and logarithmic functions in proper fashion.

[Andreas Kiel]

Ariane,

It’s mostly correct what you wrote.
May I’ll try to explain it in a different way:

If you got an integer frame rate, in theory you don’t need this ‘multiply factor’. For NTSC you need it. For example a more close to reality FPS for 30 NTSC is 29.97002997003 (actually the number is much longer and can cover a whole post). So for NTSC you need some thing to address a frame correctly covering the rounding errors.
The reason that there is time scale and frame duration (latter is the multiplyer) is more a playback/handling issue.
If you open a movie in any app you can hit at least play and stop. Play is easy as the will start display the content, Stop is a bit more difficult as there is a delay from hitting a key on the keyboard or pressing a button. Then the command has to be issued in the actual app. This all also depends on the actual used hardware.
So they decided to give an internal length to each frame to make that more save and hardware independent. While playing a movie, computer clock and QT time are compared. This means if you hit Stop the computer clock is at some time and the QT time is as well. Now QT searches in which range of the QT time of the movie the actual computer time is. If you got short QT frame durations the chance that it will stop on a wrong frame is much higher with short frame durations.

That’s why there are frame durations. Result is that you can stop in the middle of a frame in practice – though you obviously see the full frame and not a part of it. Sometimes you may experience that with some players if you hit Stop and go back one frame by keyboard or menu – the frame doesn’t change as it just stepped to the next full frame time which in case is the actual frame.
The logical result is that you should use frame durations above 10 at least, 100 is better, for NTSC 1000 is better, for ease of use the times are a power of 10.

My example again. As said, you have to figure out the frame duration, the timescale of the movie and the integer FPS. With FCP for a 23.976 movie these values are 1000, 23976 and 24.
The calculation for the time will be (0*24+0*24+20*24+5)*1000/23976 -> 20.22856189523
This time is based on the displayed timecode – it might be more complicated if your timecode is DF.
If got the total frames from either FCP or QT Player Pro the calc is easier 485*1000/23976 -> 20.22856189523

You also can go the other way round if you got a QT time. Let’s take 99985. Since you know the the frame duration is 1000 (in my example) you get 99985/1000 -> 99.985. As frames are always integers, you know now that you’re ‘inside’ frame 99 regardless of the timescale or FPS of this movie.
To get the real world time is 99985/23976 -> 4.17021187855

So for your Java app you just have to figure out the internal QT duration of the movie and the QT timescale, divide those, round down to three decimal digits and you’re done.
If you know the frame count of the movie it’s even easier: 485/23.976 -> 20.22856189523
I not really know what the intention of you Java app is, but you might use FCP’s XML export to figure out real world playing time. The frame count, the integer FPS(timebase) and the NTSC flag are given there. You don’t have to dive into the mystery of the QT programming world.

Another note on QT Player Pro.
You got the option to display time, TC or frames.
Depending on what option you have selected the display in the inspector window will change.
Let’s take again Ariane’s example:
With standard time Inspector will display a duration of 20.22 seconds
With TC or Frame display the duration will change to 00:00:20:05, but last frames timecode is 00:00:20:04, so be aware of this 1 frame. FCP behaves the same, though you can’t display time.

Hope that helps

Andreas

Spherico
https://www.spherico.com/filmtools

[Ariane Fisher]

To my surprise, beer really did help. I was still slightly off on some calculations, but figured I’d post my results for your amusement:

Here are my calculations for duration:
Sample 1 is NTSC 24fps (23.976 fps). The clip was 00:00:46:12 seconds duration. Using the formula listed above:
((46*24)+12)*1000/23976=46.547 seconds
mediainfo read 46.549 seconds

sample 2 is NTSC 30fps (29.97). the clip was 00:00:27;11.
((27*30)+11)*100/2997=27.394
mediainfo got 27.413

sample 3 is NTSC 30fps (29.97). the clip was 00:00:33;21.
((33*30)+21)*100/2997=33.734
mediainfo got 27.749

sample 4 is NTSC 30fps (29.97). the clip was 00:00:14:08.
((14*30)+8)*100/2997=14.281
mediainfo got 14.250

sample 5 is NTSC FALSE 30fps, meaning 30 (however you wish me to say it). the clip was 00:00:10:04.
((10*30)+4)/30=10.133
mediainfo got 10.133

Needless to say I liked the last one the best. Samples 1, 4, and 5 are non-drop-frame; although I wouldn’t think that would affect duration calculation. Any thoughts on what could have caused my slight error?