FFmpeg Cheat Sheet(gist.github.com)
gist.github.com
FFmpeg Cheat Sheet
https://gist.github.com/steven2358/ba153c642fe2bb1e47485962df07c730
27 comments
It's not nearly that bad once you realise that the order of arguments matters. You specify options before the file you wish to apply them to, either "-i" inputs or the final output.
I would find ffmpeg much easier to work with if it would take in a file with spelled-out, nested instructions (say JSON or YAML, like a CI tool) instead of a long list of order-sensitive, cryptic arguments.
I know there are wrapper libraries around it, but none of them seem to have the community support needed to make sense of non-trivial workflows.
I know there are wrapper libraries around it, but none of them seem to have the community support needed to make sense of non-trivial workflows.
no
The one thing that always catches me is that, when transcoding, by default, it only includes the first video track and the first audio track. If you have a file that contains multiple (multiple audio tracks are the most common example), you can add "-map 0" which means "include all tracks".
It's not the first tracks. Read http://ffmpeg.org/ffmpeg.html#Stream-selection
Many target formats do not support data sit subtitle streams, should de original contain then. So when using map 0, best then explicitly exclude those if you don’t care for them via -0:d? and -0:s? as we found out the hard way at Transloadit
In this situation, probably simpler and clearer to just do -map 0:v -map 0:a to just select the video and audio tracks in the first place.
Can someone explain to me like a i'm 5 year old what now is considered the best compression codec and most widely used one too? I remember H264 being popular, is it still the same? What happened to HVEC? Also what is better as a container, mp4, mkv or avi?
If by best you mean "most efficient space/quality ratio while maintaining correct performance and compatibility", then I'd argue HEVC/H.265 for video and Opus for audio are strong contenders for the current "best". They provide nice upgrades in efficiency compared with their predecessors, are still generally compatible (while nowhere near AVC/H.264 and MP3/AAC, their decoding is available on major platforms with increasing hardware support for HEVC), and their most used encoders (x265 and opusenc) have sane defaults and CLI.
However, that strongly depends on your use case: where are the files going to be played (which hardware/software, how old, which OS, what battery requirements...)? What are the media to be encoded/decoded like (screencapture, Blu-Ray, voice or acoustic concert...)?
AVC/H.264 is still the king of compatibility and speed/performance, albeit at a lower quality or higher file size. MP3/AAC, depending on the encoder and parameters used, still do a good job and are faster (better optimized) than Opus.
VP9 (video) is kind of niche and complex to use properly, although it is well supported due to its use YouTube. AV1 and its proprietary counterpart are not there yet, although I have a few files encoded (by others) with it and they play mostly fine, but it's on recent hardware/software and it can still be pretty iffy (like e.g. fast forwarding). But the promise is huge!
Re: containers, don't bother with AVI unless on a veeery old stack; go with MKV whenever you can (most flexible) or MP4 when you cannot (most compatible? Especially with proprietary vendors à la Apple).
So you know, like with cipher suites and other things I'd say you have two sets, the "modern" one with HEVC+Opus encapsulated in MKV, or the "compatible" one with AVC+AAC in MP4. I always go with the first one because my requirements allow it and I prefer the space/quality efficiency over anything else, but depending on the use case you may have to resort to the compatible set.
However, that strongly depends on your use case: where are the files going to be played (which hardware/software, how old, which OS, what battery requirements...)? What are the media to be encoded/decoded like (screencapture, Blu-Ray, voice or acoustic concert...)?
AVC/H.264 is still the king of compatibility and speed/performance, albeit at a lower quality or higher file size. MP3/AAC, depending on the encoder and parameters used, still do a good job and are faster (better optimized) than Opus.
VP9 (video) is kind of niche and complex to use properly, although it is well supported due to its use YouTube. AV1 and its proprietary counterpart are not there yet, although I have a few files encoded (by others) with it and they play mostly fine, but it's on recent hardware/software and it can still be pretty iffy (like e.g. fast forwarding). But the promise is huge!
Re: containers, don't bother with AVI unless on a veeery old stack; go with MKV whenever you can (most flexible) or MP4 when you cannot (most compatible? Especially with proprietary vendors à la Apple).
So you know, like with cipher suites and other things I'd say you have two sets, the "modern" one with HEVC+Opus encapsulated in MKV, or the "compatible" one with AVC+AAC in MP4. I always go with the first one because my requirements allow it and I prefer the space/quality efficiency over anything else, but depending on the use case you may have to resort to the compatible set.
h264 is still dominant by a long shot and the most widely used today. I can't speak for server/streaming services but on the ground where video editing takes place, it's the winner.
h265 was supposed to replaced it but things leapfrogged and hardware acceleration didn't come fast enough. At this point I think most of the industry is looking at what is next. About a year ago I started seeing more h265 support in cameras, but it's rare I get an h265 file from editors/productions, ever.
I'm reading more and more about AV1 and MPEG-5 being next in line.
mp4, but there isn't really a "best" container. AVI isn't very common though.
h265 was supposed to replaced it but things leapfrogged and hardware acceleration didn't come fast enough. At this point I think most of the industry is looking at what is next. About a year ago I started seeing more h265 support in cameras, but it's rare I get an h265 file from editors/productions, ever.
I'm reading more and more about AV1 and MPEG-5 being next in line.
mp4, but there isn't really a "best" container. AVI isn't very common though.
My favorite part of FFmpeg is playing around with the "complex" filters. It works like a pipeline format, applying filters to different streams and merging them together.
For example, in a previous hackaton I used it to combine randomly-generated TTS, music, and video with varying filters: https://github.com/aramperes/code-jam-2/blob/a00e73ec7a912f6...
For example, in a previous hackaton I used it to combine randomly-generated TTS, music, and video with varying filters: https://github.com/aramperes/code-jam-2/blob/a00e73ec7a912f6...
You should take a look at Gstreamer, it has all the bells, whistles and codecs of ffmpeg (it integrates ffmpeg directly as a plugin). It's designed around the concept of graph pipelines and command line interface it's a little more verbose that ffmpeg's but more easy to understand.
https://gstreamer.freedesktop.org/documentation/tools/gst-la...
https://gstreamer.freedesktop.org/documentation/tools/gst-la...
I wish this kind of stuff was built into either the —help or -recipes or something. It’s hard to find a good top-down overview… the official website loses the forrest for the trees IMHO.
Agree the built-in 'documentation' and website are not very useful for showing the best way to do things. I find their wiki[1] to be a good source of practical information about using ffmpeg. It tends to expand on detail in just the right places and gives good examples. I find myself referring to it when I am tweaking command line arguments. My DDG searches often ends up at this wiki too.
[1]: https://trac.ffmpeg.org/wiki
[1]: https://trac.ffmpeg.org/wiki
It would be useful to know if it's possible to use ffmpeg various options to re-compress, re-encode, transcode, and remove all metadata from a video to mitigate/remove some embedded steganographic watermarkings within the videos. If anyone has any idea :)
I recently had to use ffmpeg to extract audio from a mp4 at a very high quality for use in audacity. Amazing program
You can even just point Audacity at ffmpeg and it will use it to allow you to directly open .mp4 files and similar.
What is the difference between these:
ffmpeg -i in.mkv out.mp4
ffmpeg -i in.mkv -c:v copy -c:a copy out.mp4
ffmpeg -i in.mkv out.mp4
ffmpeg -i in.mkv -c:v copy -c:a copy out.mp4
The first one might re-encode, the second one explicitly doesn't, the streams are just copied as is.
The first one will re-encode.
Right but it's conceivable the default behaviour might change, the explicit one is quite unlikely to.
It hasn't, since ffmpeg's inception. It's very unlikely - it would require that ffmpeg verify codec compatibility with the output muxer. Not all muxers have registered a codec tags list , so that can't happen.
[deleted]
This is nice! Thanks for sharing
Awesome set of tips!
nice one, cheers
But gosh it's cli arguments are really Google dependent