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
with a file: ffmpeg -f concat -i filelist.txt output.webm
if all the input files listed in filelist.txt have the same format, you can add in -c:v copy -c:a copy just before the output file name to make the process much faster, and (afaik) lossless.
(e.g. "ffmpeg -f concat -i filelist.txt -c:v copy -c:a copy output.mkv". but again, all the files must have exactly the same codec/format.)
fixing "Unsafe filename": ffmpeg -safe 0 -f concat -i filelist.txt ...; remember to use single quotes in filelist.txt.
concat demuxer documentation
cutting together pieces of the same video, without creating intermediate files
this isn't a lossless method (it requires re-encoding), and it requires a lot of script to be written (and you need to basically write the same stuff for both audio and video), but it's quite fast and efficient overall, and with many cuts it's in my opinion easier than creating individual clip files and then concatenating them.
An example that combines three segments, that are at positions 0:00–1:29, 1:57–2:03, and 3:40–4:00: ffmpeg -i input.mp4 -filter_complex "[0:v] trim=start=0:end='1\:29', setpts=PTS-STARTPTS [v1];
[0:a] atrim=start=0:end='1\:29', asetpts=PTS-STARTPTS [a1];
[0:v] trim=start='1\:57':end='2\:03', setpts=PTS-STARTPTS [v2];
[0:a] atrim=start='1\:57':end='2\:03', asetpts=PTS-STARTPTS [a2];
[0:v] trim=start='3\:40':end='4\:00', setpts=PTS-STARTPTS [v3];
[0:a] atrim=start='3\:40':end='4\:00', asetpts=PTS-STARTPTS [a3];
[v1][v2][v3] concat=n=3:v=1:a=0 [v];
[a1][a2][a3] concat=n=3:v=0:a=1 [a]"
-map "[v]" -map "[a]" output.mp4
Remember to change the n parameter to concat if you have a different number of clips. About escaping: the start and end parameters given to trim/atrim can take in a few formats, including plain seconds (and milliseconds) or a HH:MM:SS.mmm timestamp. However, the colon : that the timestamp uses is the same symbol that separates options in filters, so if you try writing trim=start=1:57:end=2:03 you will get errors. The only way I found around this is to both quote the timestamp with single quotes and escape the colon with a backslash.
You can technically do this all in one line on the command line. However, the filter gets long and it's easier to edit in a text editor than the command line, so what I like to do is put the filter script (the part in the quotes after the -filter_complex) into a separate file. FFmpeg now has a feature that any option that requires a parameter, such as -filter_complex "filter script here", can load that parameter from a file, and you use a slash between the - and the option's name to indicate this: -/filter_complex "name of a file containing the filter script.txt", like so:
The setpts and asetpts are necessary, because video frames each have their own timestamp of when they are to be shown (even if the framerate is constant; PTS = presentation timestamp), and this timestamp isn't changed by the trim filter, so if the trimmed clips were concatenated without modifying the timestamp then your video player would probably get very confused, especially if the clips were shown out of order. Setting PTS to PTS-STARTPTS changes the timestamps to be relative to the start of the clip, rather than the start of the input file. If you really want to save typing, and your input has a constant framerate, then you can skip this and use the fps filter to recalculate timestamps, but doing this might cause issues like audio being desynchronized.
The examples below of burning in a text field containing a time code are old and quite unwieldy. I've since found a better way: ffmpeg -i infile.mp4 -filter:v "drawtext=font=Mono:box=1:fontsize=36:text='%{pts\:hms}':y=h-th" output.mp4
This draws a reasonably big timecode in the lower left corner, in the default colors of black text and white background, in a HH:MM:SS.mmm format. Use text='%{pts\:flt}' for a seconds.frames format. Change colors with fontcolor and boxcolor parameters.
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.
concatenating images (all of the same size and type) into a video
The way FFmpeg's documentation recommends this is done is by renaming all the images into something like img001.jpg, img002.jpg, ... and then using "-f image2 -i img%03d.jpg". I didn't want to do this, so I figured out a way to make it work with the concat format.
Here, I wanted the images to be played back at a rate of 10 a second, and I put them into a 30 fps mp4, so it's three frames per image:
An important thing was to have the image-filelist text file have duration specifications for each image (concat format documentation). I don't really know what units they are, but "duration 1" ended up working, and when combined with the "-r 10" option I ended up getting ten images a second. The image-filelist file looked something like this:
file 'screenshot_0000.jpg'
duration 1
file 'screenshot_0001.jpg'
duration 1
... and so on
Because the durations are all 1, maybe you can get away with not having them at all, I haven't tried.
I piped ls output into sed -E "s/(.*)/file '\1'\nduration 1/" to add the "file" directive and the "duration" directive on the next file.
viewing file information
ffprobe infile.mp4
framerate acceleration
example: input was recorded at 5 fps. output should be the same frames but at 25 fps, making the output video 5x faster.
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.
the minterpolate filter won't work with high acceleration rates: using "setpts=PTS/20" and the minterpolate works, but "setpts=PTS/60" and then minterpolate will give a floating point error and a crash. just leave out minterpolate and use the -r option to get the right frame rate in the end. frames will be dropped but what can you do, floating point is messy.
The "selective" part is documented as "Timeline editing" in the FFmpeg documentation, but the short version is that many filters (ffmpeg -filters should list which) support the enable option. The enable option takes an expression that may operate on the values t and n, which are a timestamp in seconds and a frame number, and if that expression evaluates to anything non-zero then that filter is enabled. I haven't found a full list of all functions but there's at least between(x, a, b), geq(a, b), and ifnot(expr, val). You'll probably want to wrap the expression in (single) quotes, so that the comma in the expression isn't interpreted as a comma that separates filters.
Here i use the hue filter for saturation and brightness modification, and the gblur filter for a Gaussian blur. By default, the gblur filter has a sigma of 0.5, which is very little blurring and is unsuitable for making text or such unreadable.
I have also used the geq ("generic expression", evaluated per pixel) filter for blurring and dimming, but I haven't yet figured out desaturation (the Cb and Cr plane values are a bit difficult). The expression here makes each output pixel the average luminosity of its neighbors in the input, in a plus shape instead of the more typical nine-pixel square, and it was sort of interesting. (Any references to a pixel out of bounds of the video is clipped to an edge, with no error.)
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
mp4 metadata
Metadata in mp4 files isn't super common but is supposedly supported with these custom tags in iTunes (there's a table of tags here). I tried the ones in this command; VLC ignored them completely but played the file fine, while Celluloid used the title field as the window's title instead of the usual filename. Of course, whatever is entered here can be recovered with ffprobe.
ffmpeg -i file_copy.mp4 -c copy -movflags use_metadata_tags -metadata title="Nice title" -metadata author="Artist or author" -metadata comment="some extra comment" -metadata description="original description or snippets of it" -metadata year="2025" filename.mp4
As for other video file formats: matroska (mkv) supports "title", "language" and "stereo_mode" "by default" but apparently you can just put whatever key-value pairs you want and it'll store them, and VLC will even recognize a title and description (but shows it as "comments"). I haven't experimented with any others yet.
you can set the size, framerate, audio channels (anullsrc documentation), and audio sample rate as required; likewise for whatever codecs you need. (useful to produce a short separator when concatenating videos; the concat format requires all inputs to be the same codec.)
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.
ffplay -i video.mp4 (-an disables audio) (-vn disables video) (-ss pos: seek to approximately that position) -vf video filter graph -af audio filter graph
Left click: play/pause, also from p and space. Right click: seek to a point according to the horizontal position of where you clicked on (i.e., if you click on the right quarter of the screen, you'll seek to around 75% of the file).
s: pause and go to next frame. a: cycle audio channel. v: cycle video channel. t: cycle subtitle channel.
9 or /: decrease volume. 0 or *: increase volume. m: mute.
to play with filters without giving a real input file, try ffplay -f lavfi -i "your filter script"
![[test screen]](img/testfoo.jpg)