stop encoding after reading 1 minute from input: ffmpeg -t 00:01:00 longvid.avi "first minute.mp4"
stop writing output once it is 4 minutes long: ffmpeg -i longvid.avi -t 04:00 out.avi
stop encoding after N frames have been output: ffmpeg -i vid.avi -frames:v N out.mp4
seek past the first ~20.3 seconds of input: ffmpeg -ss 00:00:20.3 -i infile.avi outfile.avi send first 20.4 seconds processed to /dev/null: ffmpeg -i infile.avi -ss 20.4 outfile.avi
combining both: skip 11 seconds of input and stop reading input at position 3:40 (=input duration is 3:29): ffmpeg -ss 11 -to 3:40 -i longvid.mp4 -c:v libx264 -crf 20 out.mp4
and a modification: read and encode those 11 seconds in the beginning but don't include them in the output (this avoids the input being weird because part of it was cut off): ffmpeg -to 3:40 -i longvid.mp4 -c:v libx264 -crf 20 -ss 11 out.mp4
an example with everything: ffmpeg -i cbnxcn.mp4 -filter:v "crop=x=115:y=145:out_w=(in_w-405-115):out_h=(in_h-115-145), scale=w=1280:h=720" -c:v libx264 -crf 24 -preset slow -c:a copy -t 15 -ss 2.3 ekjkbdko.mp4
add padding (in black) to the sides of the video so that the output is 1280x720, and center the video in both directions:
ffmpeg -i oddsize.mov -filter:v "pad=w=1280:h=720:x=-1:y=-1" -c:v libx264 -crf 23 -movflags +faststart youtube_ready.mp4
video quality
specifying bitrate: ffmpeg -i in.avi -b:v 500k out.avi | documentation doesn't like this though
specifying quality, for h.264: ffmpeg -i in.avi -c:v libx264 -crf 23 out.mp4 | crf values of 18-28 are considered "sane" | crf 0 is lossless, 23 default, 51 worst | relevant wiki link
generic quality options: ffmpeg -i in.avi -q:v N out.avi | ffmpeg -i in.avi qscale:v N out.avi | meaning of -q and -qscale is codec-dependent
drawtext
relevant doc section | an example where the video's timecode is burned in in seconds.frame format:
ffmpeg -i infile.avi -filter:v drawtext=" fix_bounds=1: fontfile='//COMPUTER/Users/oatcookies/Desktop/DejaVuSansMono-Bold.ttf': fontcolor=white: fontsize=24: bordercolor=black: borderw=1: textfile=burn-in.txt: x=1: y=main_h-line_h-1:" outfile.avi where burn-in.txt has the following contents: %{expr: (floor(n/30)) + (mod(n, 30)/100)} of course, that specific expression applies to a 30 fps video. the odd fontfile path is because ffmpeg doesn't exactly like windows' drive letters: trying 'C\:\\Windows\\Fonts\\x.ttf' (with varying amounts of (back)slashes) always resulted in an error.
a different burn-in.txt: %{expr_int_format: floor((n/30)/60) : d : 2}:%{eif: mod(floor(n/30), 60) :d:2}.%{eif: mod(n, 30)+1 :d:2} | this shows the timecode in minutes:seconds.frames format.
one could also do atempo=20 instead of the 2,2,2,2,1.25 done here;
the doc on atempo says "note that tempo greater than 2 will skip some samples rather than blend them in";
i didn't really hear a difference but i wanted to "blend it in" anyway.
also, i noticed that if this speedup is done in two separate filters, with -filter:v and -filter:a,
the encoding will kind of like hang on to the last frame and make the entire video as long as
the input even tho it's speeded up in its entirety: it'll be the speeded up video
and then nothing until the file is as long as the input, really weird.
doing video and audio simultaneously in one filtergraph with -filter_complex fixes this.
ffmpeg -i in.mp3 -c:a copy -metadata TSOT="sort by this string" out.mp3
ffmpeg -hide_banner -i "424745724.mp3" -c:a copy -metadata TITLE="The Title" -metadata ARTIST="Whoever" -metadata DATE=2018 -metadata LYRICS="a windows command line cannot include a newline but a unix one can" -metadata TSOT="Title, The" forarchive.mp3
This'll make the video the resolution of the image, and at 30 frames per second (the -r 30 part). For a different size video, use (for example) -s 1080x1080 after the -map 1:a flag but before -c:v.
Note that this will keep adding soundless frames of the picture to the end of the video until you quit the program (by pressing q); it doesn't stop when the input audio stops. I haven't figured out how to stop when the audio stops, but you can get around this by first running ffprobe on the audio, getting its exact length, then adding (for example) -t 03:14.15 right before the output file name to make the video exactly 3 minutes and 14.15 seconds long.
meaning of "fps/tbr/tbn/tbc" in ffmpeg's/ffprobe's output
Short answer: fps is average frames per second, tbr is a different kind of framerate, tbn is the time base that the time stamps of the video's frames are internally represented in, and tbc (when it existed) is the codec's time base. (tbc was removed in April 2021, in a commit called "remove remnants of codec timebase".) For most purposes, "fps" and "tbr" are the same, and "tbn" and "tbc" are irrelevant.
What does this mean? This StackOverflow answer explains it well; here follows my explanation based on that explanation.
(Modern) video codecs don't store the list of frames, then a command of "play these back at (for example) 30 fps".
Variable frame rates are annoying but a useful concept – maybe the camera lags, or maybe it's a stream over an unreliable internet connection where frames are received out of order or some of them are dropped. If each frame itself said what time it's supposed to be shown, they can be buffered out of order, then played in-order, or one frame can be held for enough time to skip over missing frames and the next is shown at the correct time to keep in sync with the separately-transmitted audio. Or maybe you're recording a video game, at exactly one of the game's frames becoming one of the video's frames, but video games (especially 3D ones) rarely run at an exactly constant framerate.
Each frame has a presentation timestamp, PTS, stored with it (this is what the setpts filter does, and why it can be used to slow down or speed up video – if you double the PTS, each frame is shown twice as late as it usually would, hence the video's speed is halved). This PTS value is stored as an integer, as floating-point values are notoriously imprecise. It's typically relative to the start of the video, so the first frame has a PTS of zero. The time base, tbn ("tb" for timebase and "n" for "as a number"), indicates the magnitude of these PTS units; for example, if the tbn is a sixtieth of a second, and the PTS of a frame is 181, then that frame ought to be displayed at 3 seconds + 1/60th of a second. (So, in principle, a video could be sped up or slowed down by changing its time base, instead of all of its frames' timestamps, but it appears to be good practice to not mess with tbc.) What FFmpeg/FFprobe shows is the reciprocal of this time base – it's stored as a fraction of a second, for example 0.01666…, but it's then inverted to turn it into 60 tbn.
A tbn of 60 is rather unlikely, though, because it's so low in precision. I've seen tbn values of "1k", "15360", and "90k"; these are better suited, because they have a lot of factors. (1000 doesn't, but it specifies a millisecond, which is probably good enough; 15360 is 512 (a power of two) times 30, so it can neatly specify multiples and quite a few fractions of 30. 90,000 is divisible by 24, 25, and 30, but its reason for existence is due to some codecs (M2TS on BluRay) specifying it.)
The tbc field has the same idea as tbn, but instead of it being the video file's time base, it's the video codec's. These aren't necessarily the same, as for example the codec might have a default that a file can override. Use of tbc appears to have been phased out.
The tbr field is just the frame rate, but derived from a different source; it is typically but not always the same as the value in the "fps" field.
The code that writes this info in the command-line output is in the FFmpeg code tree's libavformat/dump.c, in the function dump_stream_format, and has been for years. See it on github.
![[test screen]](img/testfoo.jpg)