Change framerate in ffmpeg without reencoding

Question

I have a mkv (h264) video that is 23.976 fps (24000/1001) but I want to convert it to 25fps without reencoding and loosing quality. I know mkvmerge can do it ( with option --default-duration '0:25fps') but I'd like to do it directly from ffmpeg if possible According to the docs this should work:

ffmpeg -i input.mkv -r 25 -vcodec copy output.mkv

but when I execute it I only get the same video fps. What is the correct method to do it (if exists) in ffmpeg?

Solution 1

Here's the method using current versions of FFmpeg. It relies on the concat demuxer not rescaling the PTS of inputs after the first file, but simply applying a fixed offset. Let's say you have a 30 fps stream with a timescale of 15360 (typical of FFmpeg output). That means frame 0 has PTS 0 and frame 30 has PTS 15360. This would become a 45 fps stream if we could change the timescale to 23040 without affecting the PTS values.

Essentially, that's what the method below does.

1. Identify the source properties.

Video: h264 (Main) (avc1 / 0x31637661), yuv420p, 1280x720 [SAR 1:1 DAR 16:9], 1171 kb/s,
       30 fps, 30 tbr, 15360 tbn (default)

You want to note the source properties, especially resolution and tbn.

---

2a. (Optional) Change the timescale to something convenient, to make calculations simpler.

ffmpeg -i in.mp4 -c copy -an -video_track_timescale 30 in-v30.mp4

This gets us

Video: h264 (Main) (avc1 / 0x31637661), yuv420p, 1280x720 [SAR 1:1 DAR 16:9], 1171 kb/s, \
       30 fps, 30 tbr, 30 tbn (default

If you do this step, the new timescale should be equal or an integral multiple of the original framerate.

2b. Calculate the timescale needed, so that for target framerate x, PTS of frame # x in the source should have the same value as the new tbn. If you carried out step 2a, this is very easy and it's simply the new framerate. So, for target fps 45, new tbn should be 45.

---

3. Generate dummy video.

ffmpeg -f lavfi -i color=s=1280x720:r=45:d=1 -profile:v main -video_track_timescale 45 0.mp4

All properties should be same like resolution, H.264 profile, pixel format, refs count..etc for best results.

---

4 Concat the videos.

First make a text file

file '0.mp4'
file 'in-v30.mp4'

Then, the concat

ffmpeg -f concat -i list.txt -c copy -video_track_timescale 45 45fps.mp4

The output file will have the 2nd video playing at 45 fps.

5. Now, cleave off the dummy preroll

ffmpeg -ss 1.1 -i 45fps.mp4 -c copy -avoid_negative_ts make_zero in45.mp4

and you have

Video: h264 (Main) (avc1 / 0x31637661), yuv420p, 1280x720 [SAR 1:1 DAR 16:9], 1757 kb/s, \
       45 fps, 45 tbr, 11520 tbn (default)

---

I did say this was convoluted!

Solution 2

Use -itsscale on the input video to achieve an effective framerate change. It works fine with -vcodec copy.

Solution 3

ffmpeg -itsscale 1.0427083 -i input.mp4 -codec copy output.mp4

This correctly slows down a 25 fps mp4 created by Handbrake from a PAL DVD source to 23.974 fps. The original show is NTSC. The audio stays in sync all the way through the now 47 minutes running time. It is very fast as no decoding/encoding is being done. However, there are audio glitches (dropouts) at roughly 3-second intervals throughout. Same result with vcodec substituted for codec, except that while video is not re-encoded, the audio is re-encoded at half the original bitrate and still has the dropout glitches.

ffmpeg -itsscale 1.0427083 -i input.mp4 -vcodec copy -filter:a "atempo=0.959041" output.mp4

This eliminates the audio dropouts, but does re-encode audio. That's much faster than re-encoding video. The remaining drawback is that it defaults to half the original audio bit rate. Need to figure out how to set the audio bit rate for the re-encode.

Solution 4

Building on @Eric's answer:

If you aren't doing these frame rates, the itsscale value might not be the same for you. To figure out your values, some simple math is needed.

In my case, my desired frame rate was 23.98, just slightly different than theirs. If your input frame rate is different than ffmpeg's default of 25, use that input frame rate instead of 25.

input frame rate / desired frame rate

In my case, the input frame rate was the default frame rate of ffmpeg (25 fps), so my calculation looked like this:

25 / 23.98 = ~ 1.0425354462051709758131.

I was using my desktop's calculator, and since this is likely a repeating number, some precision will be lost. It likely won't matter for most normal lengths of video files, but if you have some piece of video that's SUPER long, you might lose sync further into the video

Then you need to do the same for your atempo filter (using your values, of course).

desired frame rate / input frame rate

In my case: 23.98 / 25 = .9592

View more solutions

Comments

[Rowe Morehouse]

very clever, good answer.

[Freedo]

What about the audio?

[Camille Goudeseune]

ulatekh's more recent answer is simpler, and also handles audio.

[Ed999]

Extensive testing with this, a completely effective solution, has convinced me that as a method it is misconceived. It can be adapted very easily to be a far better solution to the problem of changing video from 25fps PAL to 24fps Film, or vice versa. But to use this approach with a 30fps video is a bad idea: conversion between 30fps NTSC and either 25fps PAL or 24fps Film rates definitely needs a different approach. To convert NTSC to PAL you must delete 5 frames a second, by dumping every 6th frame, to retain the video stream's original duration, without which you quickly lose audio sync.

[Gyan]

The goal was/is to re-time frames without re-encoding. Considerations of sync or maintaining original duration are beyond the remit.

[Minty]

This only changes timestamps, not fps, so to achieve the same fps, frames may be dropped.

[ulatekh]

@Barbara: No, it'll be fine. The stored FPS value is mostly informational; the presentation-time-stamps are what's really important.

[Minty]

This depends on the player, apparently. I've accelerated a sample in several different ways, and this one caused frames to be dropped upon playback, very visibly at 24000/1001–60 acceleration.

[Chris]

Thank you for this amazing answer! It's exactly what I needed to fix some PAL video that's really from an NTSC source.