This is a great idea! Trying to get FFmpeg to do what I want it to do is always daunting. ChatGPT has been helpful, but not perfect. Thanks for this :)
You use "access" several times but I don't know what you mean by it. I'm going to guess that is some non-english usage slipping in. Nothing else to complain about at this time. [EDIT] I should say "is used" and "they mean" because I don't know if the author is also the poster.
'Access' copies are versions of originals intended for viewing, in contrast to the original ('preservation') video which may be impractically large to use, or in an unusual format.
(At least that is how the term is used by collections librarians. Even there terminology may vary)
The second link's clipping command is not ideal in my experience. For some god known reason, ffmpeg behaves differently depending on whether you put the -ss and -t/-to flags before or after the -i flag. And for me, before worked better.
my understanding is options in the cli are tied to either global options, input file options, or output file options; so placing options after -i option(s) would tie it to the output file... i'm definitely not an ffmpeg expert though.
Effectively, placing ss before the input filename seeks the file (the container?) without decoding it. Placing it after will decode the streams while skipping to the point you specify.
Seeking the container is usually much faster than decoding and then throwing away what you don't need, but it has fatal flaw: most videos use p-frames and thus require you to decode the frames before it.
So, say you want to skip to 60 seconds in. The solution is to do "-ss 50 -i input.mkv -ss 10", which is fast and should get the keyframes you need.
Speed was never my concern, judging by what you said I think putting the -as after tried to cut things between p-frames and that often caused probls with the cut, while putting it before started the cut at the last p-frame? Something like that, I don't use ffmpeg enough to remember what problems I was having but I remember what fixed it.
That trick (-ss -i -ss) should not be necessary by default (unless you use -noaccurate_seek) according to current documentation. But I haven't verified it.
-ss position (input/output)
When used as an input option (before -i), seeks in this input file to
position. Note that in most formats it is not possible to seek exactly, so
ffmpeg will seek to the closest seek point before position. When transcoding
and -accurate_seek is enabled (the default), this extra segment between the
seek point and position will be decoded and discarded. When doing stream copy
or when -noaccurate_seek is used, it will be preserved.
When used as an output option (before an output url), decodes but discards
input until the timestamps reach position.
ffmpeg.guide looks amazing, but it feels like ffmpeg should really have something better itself. It's crazy trying to shoehorn a graph (non-linear) into a commandline (flat, linear). Even just a more verbose json config would be great.
The page is a collection of commands to perform specific actions like transcoding, syncing video/audio/subs, etc. Screenshot(s) won't offer any additional information/help.
Conversely, I do not know any developers that use AI instead of google. And considering the horrific garbage it has given me the few times I tried, I’d be worried about what you’re doing with it.
I do use ChatGPT, and while it helped me with things like obscure issues with bash syntax, it hallucinated some CLI tools options often enough that I never trust it with anything important. (And I tried to ask it even fairly easy questions.)
While it works pretty well when I forget some CLI tool option, in cases when some tool does not have an option doing what I want, ChatGPT is worse than useless - instead of telling me that it doesn't know an option doing something exists, it just tries to "think something up".
In the world when the right answer is "no, there is no option doing what you want" even a small amount of time, ChatGPT is actively harmful.
A nice collection. Wish those examples, or part of them, were included in ffmpeg manual. The ImageMagick section can easily be expanded to a site of its own.
There are still plenty of contexts where you can embed images but not videos (or at least not with automatic looping playback) - forums, github README.md, other markdown-based comment/post systems.
Gif compression limitations also encourage you to cut down to the essential parts - too many videos waste the viewers time with delays and irrelevant bits.
Animated webp is commonly supported at least on he web these days.
Of course, it too is a horrible video format, which is impressive considering it is based on a not nearly as horrible video format. If only browsers would support silent looping video in <img> and CSS image contexts...
> Animated webp is commonly supported at least on he web these days.
Sure-- if it's a) a website that b) you're making. Tons of websites that allow user uploads only allow common static image formats-- jpg, gif... maybe png, maybe bmp, etc. I can't imagine anywhere that allows users to upload profile pictures, for example, would allow them to upload a webp, but I could imagine users wanting an animated profile picture. I've done it myself.
The whole point is that there are instances where using an animated gif is the only option if you want an animated image, and people want to convert videos to animated gif because of that. That's why FFmpeg does it. I'm not really sure why people find this so weird.
Probably the biggest barrier to ffmpeg adoption is all the offline 'freemium' and web frontends, the host sites for which have been SEO'd for phrases people commonly put into Google like "avi to mp4", "mp3 to wav", etc..
It took me more time than I wish it did to become open to using CLI apps, the Windows world had taught me to expect a GUI for everything.
They almost certainly are, cli is not always the best interface but ffmpeg covers such a wide swath of video utilities that I’m not sure how you could include all of its functionality in a GUI.
This guide recommends "yadif" as a deinterlacing filter. I find "w3fdif" looks better. Like yadif, it does not do motion tracking, so it's reasonably fast and avoids the distracting artifacts that motion tracking sometimes causes (I'd rather have consistently mediocre results than sometimes great and sometimes bad), but it considers three fields at a time instead of yadif's two, which lets it hide the interlacing artifacts better.
As previously suggested, w3fdif has mostly been supplanted by bwdif. w3fdif can produce shimmering, whereas yadif does not, which is why bwdif operates like yadif but uses the better field matching of w3fdif.
A bit off topic, IMO ffmpeg is one of the best software ever written. Fabian Fabrice (ff) is one talented engineer and people such as him are a gift to the FOSS community.
I used to work in a ~2 bil unicorn in which a big part of the products we worked on relied on ffmpeg.
Absolutely. For the first startup that I worked for, I earned a position with budgeting authority. Once we achieved profitably, I added donations to the open source tools we relied upon. I received some pushback and defended it. Looking back, I am proud of that choice. I encourage you all to do the same.
What likely works better in conservative environments, are not donations, but (generous) support contracts. This is something buisness people can understand.
Oh, this goes w/o question, but not all F/OSS projects are incorporated and/or can provide a contract. Even more trouble if the entities are in yhe different countries.
While I'm sure you are right, I can't help but to be irked by this strange environment we live in where we have to treat business people like infants who need things mashed and mushed into something they can digest and understand.
Nobody had to explain to me the concept of donating to support somebody working on something my business relies on, it's just common sense.
If I was really reliant on books documenting tolls and laws in regards to international trades, and you wanted to give a donation to support this work, I wouldn't be all "me no understand, please explain it in programmer-speak for me".
If you relied on a set of books and found out the author and publisher were head of the 'Defund STEM; Make Everyone Get Lit Degrees (DSMEGLD, prounced De-smegol'd, cause they are LOTR nerds)' lobbying organization and actively spent a good portion of their day convincing education organizations from kindergartens to Universities remove all their math, science, and programming classes and teach crystal healing instead, would you donate to them?
You love programming and wouldn't help a group of people try to destroy it, right>
Well, business people love money and don't want to help people not give it to them or not let them keep it.
Have you spent much time around business people? I’ve spent years around them and open source software truly confuses them. Why would you ever use your time to make something and then give it away? I once suggested we make a donation and they laughed at me. Their response was if people are dumb enough to make something and give it away for free, then they get nothing.
One argument I made was sponsoring a project, especially buys you support / developer relations. For example, we replaced a commercial PKZIP license with 7-zip. Was able to use the fact that one of the project we donated to, 7-zip, implemented a feature request that helped in this transition. That combined with the fact that these donations relative to our proprietary software costs were insignificant, made it an easy sell to my boss.
People like to say that ffmpeg is complicated but when you make it into a nice gui it doesn't get any easier -- it is video compression itself that is complicated. No software could make it easier without making the decisions for you, like handbrake or some other click-through interface.
I'm not certain, but I highly suspect that if I sat down and learned about digital video encoding and compression on a granular enough level then figuring out how to do things in ffmpeg would be rather intuitive. Does anyone have experience doing this?
I've written DirectShow filters around 17 years back for WindowsMobile (not Windows Phone) so I've a decent understanding of codecs and containers.
Formats like mkv or codecs like HEVC didn't exist back then but the concept of manipulating audio/video through a bunch of filters is a wonderful one and most (all?) a/v transforming software does it. When I started looking into FFmpeg's man pages I could connect the dots and start using it after a day of fooling around.
I'm a CLI lover and man page reader so perhaps it worked to my advantage.
Its optimized Pythonic video filtering... But also so much more: https://vsdb.top/
And Staxrip, which makes such good use of ffmpeg, vapoursynth, and dozens of other encoders and tools that I reboot from linux to Windows just to use it: https://github.com/staxrip/staxrip
I would really appreciate just an ffmpeg wrapper with better CLI. It is unnecessarily convoluted, and while I don't know if there's a point of view from which it actually all makes sense, it is just inadequate in performing all sorts of extremely common tasks it is perfectly able to perform, if one knows which magic words it needs to hear. I probably have dozens of bash-aliases, that are nothing more than encoding 150-character ffmpeg commands into 2 simple words.
It is also incredibly stupid how 99% of time ffprobe is used without any arguments to just quickly see something as mundane as duration, resolution, framerate, MAYBE number of audio-tracks, yet 99% of its output is some completely irrelevant bullshit like compiling options.
>> I would really appreciate just an ffmpeg wrapper with better CLI.
There were (are?) tons of them on GitHub. But many are still obscure, or are single dev efforts that fizzled out.
Some focused, purpose built CLI frontends (like Av1an, specifically for transcoding) are excellent at what they do. Perhaps that is the better way than an all encompassing wrapper.
Those anchors don't work on Firefox on Android. The author is losing... I dunno.... 1e-20% or whatever of the browser market share among my fellow Android FF users.
Related: I have a small library of personal videos, including from my wedding, and I'd like to compress it as much as I can to reduce its storage footprint. I don't care much about codec compatibility, as long as I can watch them on my (ARM) MacBook, it's good.
In the past (over 10 years ago), I used to work with H.264, but I remember fiddling with parameters was a pain. I wonder if nowadays there are some promising new codecs based on ML. Again, as long as it works in my machine it's good, so anything from GitHub, HuggingFace and so on is acceptable, as long as it doesn't need too much effort and specialized knowledge to run it.
There are some promising codecs based on neural networks, however they are all very much research projects and have major limitations. Additionally, the compression ratios are only marginally higher than state-of-the-art engineered codecs. I think for your use case a more modern engineered codec such as VVC (H.266) or AV1 is perhaps more suitable.
This depends on how much time you want to spend. If you want the transcode to take less time than the playtime of your videos, it'll probably be best to just use the best hardware encoder you have with high quality settings.
If you have more time, then AV1 is good. Read through the trac page [1] and do test encodes with 5-10 seconds of video to determine what settings give you your desired quality. Note that low `-cpu-used` or `-preset` values will give great quality but take incredibly long. Then, encode a few minutes of video with various settings to determine what settings give you your desired file size.
For human time usage, keep track of the commands and options you use and how those affect the output. If the job will take more than a few hours, write your script to be cancellable and resumable.
In the spirit of making FFmpeg and video processing easier, we open-sourced a chat-based agent to assist video production - https://github.com/remyxai/FFMPerative
I am a bit confused. This seems to be about the command line programme "ffmpeg" that comes with the library, but not the library itself. That programme seems already very well documented, with a help option, a man page and everything. It is usually the library that no one knows how to properly use, due to a lack of documentation :-)
As someone who uses ffmpeg daily (mostly basic functions), I now rely on chatGPT to approximate the command and fine tune from there. Haven't used too many of the advanced features of ffmpeg so glad someone seems to be covering those use cases as most tutorials dont cover them.
I'm compressing everything using, H.265 and videos are shrinking to sometimes 1/10th the size.. Is there who would give me reasons why I would not want to do this? I've read that it takes more processing power to watch these compressed videos, but not sure that will cause much trouble in the future...
I tried this automated across a large video collection and the quality was subpar because my CRV settings were weak despite looking fine on the test videos. Consider that a word of warning, validate many videos before removing the masters.
But with 300gb, storage is cheap enough that you could just keep the masters.
reply