Varying timebase

[Budman1]

I have what is probably a quick question for the edperts here but i cannot find an answer on the internet or here.

I thought videos had different timebases but they were constant throughout the video. I have a video that has varying time base that is 1502, 1500, 1501 insterspersed frames.

Does any one know what causes this or how it can be fixed? Changing the timebase does not cure the varying.

Thanks

[Selur]

For cfr content, timebase should be 1/framerate and timestamp increments should be identically 1, but if your input is vfr the time base could vary,...
For cfr content the time base should be fixed in normal containers, iirc. in transportstream it is allowed to change.

No clue what your problem is, what you are trying to do.
To be frank I can't make heads or tails of your post.

I thought videos had different timebases but they were constant throughout the video. I have a video that has varying time base

Can't be contanstant and varying at the same time,...

Changing the timebase does not cure the varying.

The varying of what? What did you do? What are you trying to archive.

Sounds to me like you got a file with broken headers.
Assuming your want cfr content, have you tried demuxing into raw streams and remuxing while generating time stamps? (like '-fflags +genpts -r X' where X is the frame rate you want)

Cu Selur

[Budman1]

Most of the videos i have have constant (the same) timebase for each frame. I am using that dtermine the frame number at a particular cut point. If the timebase varies then that is no longer possible to use for obtaing frame number. Ffprobe nor any other program shows frame number to pts time relation.

Basically i need to obtain a frame number for a given pts time without reading an entire file.

[jagabo]

Basically i need to obtain a frame number for a given pts time without reading an entire file.

You can't do that with VFR. For example, smartphones often double the exposure time and halve the frame rate during dark sequences. So during a panning shot a well lit sequence may be stored at 25 fps (time codes incrementing by 40 ms per frame), but during a dark sequence it may drop to 12.5 fps (time codes incrementing at 80 ms per frame). With that type of VFR you must sum the time code of each frame from the start to get the frame number from a frames time code (or just count frames from the start).

That said, many VFR videos are essentially CFR but the time code delta from frame to frame (i.e. the duration of each frame) alternates between two different values. For example, MP4 usually uses a time base of 90000 (display time = N/90000). But a CFR frame rate like 60000/1001 requires a duration of 1501.5/90000 per frame. The time code numerator must be a whole number so the frame durations alternate between 1501 and 1502. With that type of VFR you can probably assume CFR to get the frame number.

[Budman1]

Thank you jagabo and selur. That was a wealth of information i didnt seem to be able to find, at least not in one place. Thank you for the great replies, as always from both of you.

[hello_hello]

I don't know how ffprobe does it exactly, but if it's anything like ffdshow, it counts at a constant frame rate even for variable frame rate video. The timebase seems to determine the frame rate at which it counts (in a way I'm yet to fully understand). For VFR, when the frame rate is higher than the rate at which it's counting, sometimes more than one frame has the same frame number. When it's lower, frame numbers are sometimes skipped.

MKVToolNix has an option to cut based on timestamps, which I think is effectively the same as cutting after a particular duration, except the former only cuts once. The video in the screenshot below is variable frame rate. When I asked MKVToolNic to cut on frame number 2565, it cut about 300 frames early, but when I asked it to cut at 03:34.000, it cut where I wanted it to (I'd already determined the next frame would be a keyframe). The tool you're using for cutting doesn't have a similar option?


[Attachment 61954 - Click to enlarge]

[Budman1]

Almost all editors,players and cut/merge programs can accss an MP4 H.264 video by time because it is encoded into the actual atoms data. Record numbers are not. This is the reason programs like FFMpeg will search for the preceding or next Key Frame (Depending how you search, before input or after) .

it counts at a constant frame rate even for variable frame rate video. The timebase seems to determine the frame rate at which it counts

This very fact is why players and displays like ffplay show constant frame rate in a variable frame rate video. Calculating the record number for instance a 59.94 FPS video with a time base of 90000 yields a pkt_pts of 90000/59.94=1501.501501501501... Some programs round this to 1501/1502 or 1501.5 or 1501.501 or 1501.501501. This makes it extremely hard to accurately obtain the record number and without it, it is difficult to be frame accurate.

The program I usae (My own) accurately cut at frme accurate points, encoding only what is neceesary for between Key Frame cuts. It worked great up until My recent attemt to cut a video as mentioned above, 59.94 FPS with TimeBase of 90000 and with a strting pkt_pts of 2970 caused validation problems.

if I select a segment in the middle of a video, Decoded record number and pts time all reset to 0. pkt_pts is the only constant that does not change and constantly increments. Since my program is still beta and showed a sudden glitch, I needed more information about Timebase. The information I

Thanks again!received here has helped tremendously.