Our Solutions Architect, Paulo Costa, shared with us some Q&A about timecode concepts, concepts that are usually misunderstood for newbies (and not so newbies) to this industry.
Here is a short extract of one of his recent “session”.
> Is it possible to have a file that states duration in timecode of 01:00:00:00 and the duration of the file is 1h00m03s600ms?
Yes, that possible and is the case where you’re using non drop frame timecode and frame rate of 29.97.
The concept you have to understand first is that timecode tries to approach but it’s no actually time.
> Now you’ve lost me… what do you mean that timecode is not time?
Timecode is a frame representation. That being said it only has two simple rules:
It counts consecutively until reaching the defined frame count, which is always an integer number.
e.g. If you define the timecode frame base to 30, the first will be 00:00:00:00 until it reaches 00:00:00:29, then it will go to 00:00:01:00 and so on.
It introduces a concept of drop frame that says:
In 30 frames counting the first two frame numbers (00 and 01) shall be omitted from the count at the start of each minute except minutes 00, 10, 20, 30, 40, and 50.
For 60 frames the same mechanism is used, but since you count each frame twice, there’re four frames dropped.
> But that looks really time?
Yes it looks, but timecode is made to represent the frame not the time.
It intends to be the closest to real time that is why there’s the drop frame mechanism to compensate the deviation from counting 30 frames per seconds and the real media rate 29.97.
> That makes sense.. so I don’t need to know the actual media frame rate?
Before going further let’s just clear some concepts:
Frame, is what we call to the set of picture, audio and data that represents a full unit of the video
For interlaced formats this will contain the two fields of the picture
Audio needs to be packed in order to play that amount of video timecode, is a way to represent that frame in a human readable form, the closest possible to actual time. All consecutive frame will have incremental timecode, except the drop frames when applicable.
When storing or presenting that frame to the user you need to say how long that image should be presented.
For that we define the number of frames playable by second (fps) which the inverse represents the time to play a specific frame. e.g. for a fps of 29.97 each frame will play roughly 33ms.
Clear, so why do we need fps when handling timecode?
You don’t. If you’re just handling timecode you just need to use three parameters: rounded frame rate, the number of frames that which the timecode counts 24,25,30,48,50,60, just be aware that in some situation although the timecode counts the frame to a certain value (48, 50, 60) the frame representation is only half and you need to count each frame twice drop frame indication, indicating criteria for drop frames is used frame, the actual frame representing the timecode
In nowhere in the timecode calculation you need to enter the actual video frame rate. Attached is an example of a timecode class that handles timecode without never entering the video frame rate. Also, that why calculating timecode for 29.97 fps and 30 fps without drop frame is exactly the same.
> That’s cool, so I can forget the actual frame rate?
No, you need the frame rate for converting from frames to real video time.
Most players will not return their current position or seek position in frames but in timestamps, which reflect real time.
My suggestion on this is to separate the two concepts:
Frames and timecode calculation
Timestamps and frame calculation
e.g. You need to seek to a specific timecode in a player
Convert the timecode to frame count
Divide the frame by the fps
Use that value to seek
e.g. You need to know timecode a timestamp represents
Multiple to timestamp by the fps to get the frame
Calculate the timecode for that frame
Almost there… but can you give some pratical example
Let’s use a practical example for fps of 29.97 with timecode DF and NDF and fps of 30 (drop frame indication is typically represent as ; between minutes and frames)
All of them count frames to 30.
|timecode | fps | frame | timestamp |
|01:00:00:00 | 29.97 | 108000 | 3603.6 sec (1h00m03s600ms) |
|01:00:00;00 | 29.97 | 107892 | 3600 sec (1h00m00s000ms) |
|01:00:00:00 | 30 | 108000 | 3600 sec (1h00m00s000ms) |
As you can see:
29.97 fps with timecode NDF and 30 fps represent the same frame
29.97 fps with timecode DF and 30 fps are the same as real time
29.97 fps with timecode NDF is different from real time
> So that means that 29.97 and timecode with NDF doesn’t make a lot of sense?
Correct, but there’s nothing we can due regarding that.
This is not used in scenario like a 24/7 recording facility, using that kind of timecode in those situation would create a shift between real time that would make it useless.
Anyway when we talking about file based that doesn’t have a lot of impacts, e.g. timecode duration of 1h and it play for 1h3s it doesn’t affect a lot…
Just be aware that saying file-based doesn’t mean this doesn’t impacts SDI devices, your device may be receiving timecode from a video player that typically can have media with DF and NDF indication.