2

I have a video that was rendered as 26.51 fps h.264 into an mkv by my video editor. Calling the file up in ffmpeg it displayed this file as 1k fps, 26.51 tbr.

When I applied an operation to separate a 1 minute segment of this video into its own video I used

ffmpeg -ss 00:00:00 -i input.mkv -to 00:01:00 -c copy output.mkv

Calling the output up in ffmpeg showed this video as 27.4 fps, 26.51 tbr.

I then changed the container of this short 1 minute section in two independent operations:

ffmpeg -i input.mkv output.mkv

Displayed the fps as: 26.51fps, 26.51 tbr

ffmpeg -i input.mkv -c copy output.mkv

Displayed the fps as: 27.4fps, 27.4 tbr

I'm very confused, what exactly is going on here? I wanted all my videos fps to be 26.51fps. What do I go about doing to prevent this from happening in the future?

"tbr = tbr is guessed from the video stream and is the value users want to see when they look for the video frame rate"

So my understanding from that definition is in the first video I "wanted to see" 26.51fps instead of 1k fps. Which is true. So something *first went wrong at this point that I need to fix?

Then from the second video I wanted to see 26.51fps instead of 27.4fps? Which is true.

Then from the third video my tbr and fps matched at 26.51. Wonderful!

The fourth video the fps and tbr matched at 27.4fps but I didn't want 27.4fps

And with the -c copy command above I'm guessing it forced the 27.4 fps value onto the video and that's why it became the new tbr and fps values. But this doesn't explain how in the top command where I yielded out my 1 minute partition of the original video, which also used -c copy, that it created a new fps value rather than use the 1k fps value of the original.

Edit: I see you can force the fps with -r 26.51; but this is requiring a re-encode, which I need to avoid. Is there something else I can do at one of the steps? I already rendered it with 26.51 as my fps to begin with afterall.

2

What the fps and tbr values indicate is the average and peak framerate detected within the file. When the container doesn't have valid metadata, either or both of these values can be wrong.

A tbr like 26.51 indicates a variable frame-rate file. After you extracted a segment with -c copy, ffmpeg will display the rates detected in the new clip. Since the source is VFR, the rate may not match but the individual frame timings won't have changed, and can't, since no frame operations can occur*.

When you transcoded instead, ffmpeg sets the output rate to the detected tbr and drops frames in regions with a greater framerate. (When saving to a constant rate muxer like MP4, it will clone frames if input rate is lower).

*true within this context

  • I don't understand how that explains the first case where it displays an average of 1k and a peak of 26.51. Or in another case I rendered with an fps of 500/21 fps from my vse. It's not supposed to render variable framerates only constant. Checking with ffmpeg showed 1k fps and 23.81 tbr. Checking average fps with ffprobe showed 500/21 tho. From the information I have I am inclined to believe the data is actually the right fps and playing fine but its thinking its not. Is there a way to try and force it to think the data is 500/21 fps so it doesn't change? – kite Dec 19 '18 at 21:27
  • 1
    where it displays an average of 1k --> When the container doesn't have valid metadata, either or both of these values can be wrong. – Gyan Dec 20 '18 at 4:31
  • Okay I see my mistake now. In terms of fixing the metadata, or re-assigning it to the values I had assigned them to be on render from my video editor, is there any fix to that? Of note: I've had many problems with matroska renders in the past in my vse always changing the fps render value to 1000fps, the vse uses ffmpeg to render although its more limited in its options and does not allow access to the commandline. When I updated the vse it started displaying the right fps and worked correct on playback, but...seems something is still bad. I'll file a bug report if there's nothing else to try – kite Dec 20 '18 at 8:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.