VRD cannot deal with 23.976 time correctly

MrVideo

Active member
Bring up any 23.976 video file and enter time codes to jump to. You will not go where you wanted. Go out to 42 min and you jump to 42:02.15. This problem has been going on for ages.

It becomes an issue when trying to set chapter marks to I/IDR frames. Somewhere past the 7 min mark, the markers are no longer on the I/IDR frames. they are off by 1 or 2 frames before the I/IDR frame.

This means that when the video is imported into a Blu-ray authoring program that uses the chapter marks in the MKV file, they will be wrong.

I know I've brought this up before, but now it has really become an issue.
 

Dan203

Senior Developer
Staff member
Is this an MKV as mentioned in the other thread?

MKV isn't a grwat format for 23.976 video or 44.1kHz audio. The reason being is that MKV uses millisecond timestamps which do not have enough resolution to represent the timecodes needed for those frame/sample rates. We attempt to correct for it internally, but there can be some drift which can cause seeking errors.
 

MrVideo

Active member
I don't do anything but 48kHz audio. MKV shouldn't be any good for 29.97 video either. But, it is the only widely used container that can contain chapter marks. I take 29.97 video and IVTC it all the time, using my own perl script to convert from 29.97 chapter marks (from the VRD frames text file) into the format needed for x264 to insert I frames at the 23.976 location. I also create a chapters file for mkvmerge to use to add the chapter locations when muxing the H.264/AC3 streams. If I read that MKV file into VRD, going to the markers lands exactly where I wanted, right on an I-frame.

With the files I am currently dealing with, since opening this thread, I've determined that I need to run the file thru VRD first. This also allows me to add a couple of seconds of black at the head and tail. I then read in the TS file and search for the locations where chapter markers will be placed. The first few markers land correctly, but the remainder of the markers are 1-2 frames after the I/IDR-frame. I'm not sure what to do about that.,

The main issue is seeking to time locations, the topic of this thread.

While working with the files, it had an issue with four frames. When I look at the log at the location where the problem was, the time is listed as 42:05.00, frame 60537. But, if you go to frame 60537, it is displayed in the thumbnail as 42:04.20. While sitting on that location and hit Ctrl-T, the time placed into the dialog box is 42:05.00. If you go there, you end up at frame 60600.

Doing some math. I determined that the left hand is not knowing what the right hand is doing:
60537 = 42:05.00 = 23.976
60537 = 42:04.20 = 24
60600 = 42:05.00 = 24

In other words, portions of VRD are using 23.976 for the math and other portions are using 24 for the math. That is what is causing the seeking and display issues.
 

Dan203

Senior Developer
Staff member
We use DirectShow units internally. Which are 10ns each or 10,000,000 units per second. We try to recalculate MKV timecodes using the frame number reported by FFmpeg but it’s not always 100% accurate after a seek. That’s what causes these issues. It seems to be worse on 23.976 then 29.97, which is why I said that. I mentioned 44.1kHz audio because it’s so inaccurate with that it can cause sync errors on output.

If you QSF the file instead of opening it in the editor then it forces VRD to recalculate all the time codes, start to finish, so it doesn’t have a problem. But if you just QSF to another MKV file then you’ll have the same issue. You’d have to use another format.

The most annoying thing about MKV is that it doesn’t have to use MS timecodes. Someone early on just settled on that as a standard and everyone keeps using it. I tried setting VRD to use higher resolution units on output but the files had trouble in some players because they assume MS and ignore the actual timecode format in the header.
 

MrVideo

Active member
I ran the files thru VRD to a TS file. I then searched for the chapter locations that I wanted. I then output that to a MKV so that it contained the chapters.

But that is not the issue. Please reread post #3 carefully.

But, I'll try and explain it again. Read in a 23.976 video that is at least 30 min in length. Do a Ctrl-T and enter 30:00:00. You'll end up going to frame 43200. But, the thumbnail will say the time is 30:01.19.

30 min @ 24fps is 43200 frames. That is wrong. The math for seeking to a location should be done at 23.976fps, which equates to 43156.8 frames. Do a Ctrl-T and enter in 43157 frames and you'll get to exactly 30 minutes.

Again... the thumbnail info is being displayed @ 23.976fps, but the seeking to a location via the Ctrl-T entry is being done via 24fps. The time code white box also displays the time code using 23.976fps for the math.

I hope you now understand the issue and will fix the subroutine that does seeking to use 23.976 instead of 24.

A thought came to mind just before I posted this and that is what if someone has video that is 24fps? Hopefully you are detecting that and setting the math value according to the actual frame rate, or at least will once the issue is resolved. I do not have actual 24fps material, so I can't see what currently happens.

As a side note, I even have video that is 24.975fps (25/1.001). That is a result of IVTCing 29.97i video after 25fps video was slowed to 24.975 for telecining to 29.97. I didn't try going to true 25fps as it would mean trying to get the audio sped up. While there are AVISynth filters to do that, I didn't feel that it was worth the effort.
 

Dan203

Senior Developer
Staff member
The error isn't in the seek it's in the timecode display. For 29.97 we support something called drop frame timecodes, which prevent the timecodes from drifting over time due to the fractional frames. DanR just informed me that we do not support drop frame timecodes for 23.976. So that explains the difference between the frame number and the displayed timecode. He said he would add 23.976 drop frame support to v6, but he's not going to back port it to v5.
 

Dan203

Senior Developer
Staff member
Hmmmm... been doing some research on this and apparently there is no standard for drop frame at 23.976. So I'm not sure how we're going to handle this. We may not be able to.
 

MrVideo

Active member
Correct, no industry drop-frame timecode for 23.976.

Sigh! The displaying of the time value vs the frame number is correct for 23.976 videos. The problem is with the entering of a time value to seek to. Instead of taking the time value and figuring out the frame to go to by using 23.976 for the math, the subroutine is using 24 for the math. Just fix the subroutine that does the math to use 23.976 instead. Problem solved.
 

Dan203

Senior Developer
Staff member
That's not how it works. We don't calculate a frame number. We calculate a timestamp based on frame duration. It's jumping to roughly the right frame, the problem is the time code shown in the thumbnail is wrong becuase there is no drop frame being applied to those time stamps.
 

MrVideo

Active member
The time code in the thumbnail is correct because there isn't any drop frame with 23.976. As explained above, for example, 30 min @ 23.976 is frame 43156.8, rounded to 43157 frames. That is what is seen in the thumbnail. Obviously it really isn't 30 min because of the frame rate error (just like 29.97 without drop frame).

A frame duration for 23.976 is .041708375. But, when you enter a time value to jump to, .041666666 is used, which is not the frame rate of the video.

No matter how you want to look at it, computing the time stamp for an entered time value is computed incorrectly.

Out of curiosity I turned off drop frame and loaded a 29.97 video. I wanted to see how VRD reacts to entering time values without drop frame, but I discovered that drop frame can't be turned off. It stays on, even when value 26 is set to false.

Frankly I do not care if you compute time based on 23.976 or 24. Both have their accuracy issues. Just make it the same for all computations. I have no idea how the industry deals with 23.976 time code. When the network wants the final product to be 43 minutes long, they expect 43 minutes, in real time.
 
Last edited:

MrVideo

Active member
I did some math just to see what it would take to do DF time code for 24/23.976.

It turns out that the first time that there is an integer frame count is at 25 min (35964). At 24fps, there would be 36000 frames, a difference of 36 frames. So, for the first 24 min, 3 frames would have to be dropped every 2 min., or 1 frame every odd minute and 2 frames every even minute.

No wonder SMPTE decided never to do 23.976 DF time code.
 

Dan203

Senior Developer
Staff member
We removed non-drop frame from consumer. You have to upgrade to Pro to get NDF timecodes.

DanR said he's looking into adding drop frame for 23.976 to v6. Even though there is no standard doesn't mean we can't work out a system that produces the same results. But regardless there will be no changes to this in v5. We're currently trying to finish up a few bugs in v5 so we can release one final official build and then all future work from that point forward will be on v6 only.
 

MrVideo

Active member
We removed non-drop frame from consumer. You have to upgrade to Pro to get NDF timecodes.
I must have missed that in a change log. Then the option should be greyed out for the non-pro version.
DanR said he's looking into adding drop frame for 23.976 to v6. Even though there is no standard doesn't mean we can't work out a system that produces the same results. But regardless there will be no changes to this in v5. We're currently trying to finish up a few bugs in v5 so we can release one final official build and then all future work from that point forward will be on v6 only.
I'd leave all the math at 23.976 NDF. Why? Because no one else does it. I do not use it when I determine the frames to use for x264 to a I-frames and the file I create for mkvmerge's chapter index file. It would mean that the timestamps that VRD would use when reading in a MKV with chapters would result in VRD marking the wrong location.

From what I can tell, because there is no SMPTE approved 23.976 DFTC, everyone in the industry has to use a cheatsheet, or a built-in caluculator in the editing program. Don't waste your time trying to do DFTC.

Waiting to get this issue fixed in V6 is just fine.
 
Top Bottom