16

I'm trying to double the speed of a video.

I use the commands:

ffmpeg -i output.mp4 -filter:v "setpts=0.5*PTS" output2.mp4

and

ffmpeg -i output.mp4 -vf "setpts=0.5*PTS" output3.mp4

which I find all over the internet as being the standard method.

However, all my files are the same length:

joe@joe-Amd-Am4-Home-Office:~$ for file in *.mp4; do duration=$(ffprobe -v error -show_entries format=duration -of default=noprint_wrappers=1:nokey=1 "$file"); echo "$file: $duration seconds"; done
output2.mp4: 373.014000 seconds
output3.mp4: 373.014000 seconds
output.mp4: 373.014000 seconds

What's going on and how do I properly speed up the video? I'm using ubuntu.

Joe
  • 3,460

1 Answers1

27

My first guess would be that the PTS approach, documented here, works "by changing the presentation timestamp (PTS) of each video frame," which players would respect and speed up. But perhaps that does not change the reported length of the video as ffprobe sees it.

But fiddling with a random test mp4 I have shows that, while the video is sped up, the audio is not. Which would explain why I too see the same timestamp for each video via ffprobe. This lines up with a note from the documentation linked above:

Note that in the following examples, the audio stream is not changed, so it should ideally be disabled with -an.

Another answer on superuser offers the following complex filter to speed up both the video and audio:

ffmpeg -i input.mkv -filter_complex "[0:v]setpts=0.5*PTS[v];[0:a]atempo=2.0[a]" -map "[v]" -map "[a]" output.mkv

And that one works for me, showing half of the length via ffprobe.

Preston Maness
  • 1,462
  • 11
  • 16
  • 4
    Perfect - the -an fixed it. Also wonderfully well explained and tested. – Joe Jul 11 '23 at 11:04
  • 1
    Weird that PTS is inverse rated to atempo. This means you have to use a formula to reach the correct numbers programmatically. I love ffmpeg, but the filtergraph scheme needs a rewrite. – user287352 Jul 12 '23 at 03:58
  • 2
    Note that setpts could be described as non-destructive, while atempo definitely transcodes the audio (stretch/pitch-shift). They are very different operations, which also explains why they take "inverse" numbers. They just happen to be used simultaneously in this case... so I'd say the filtergraph doesn't need a rewrite ;) – kubi Jul 12 '23 at 09:05