8 ms·
> * A replacement front-end for "ffmpeg", see above I have one of these too... It's kind of frightening how hard ffmpeg is to use without some kind of custom f
by lq0000 4y ago
> * A replacement front-end for "ffmpeg", see above
I have one of these too... It's kind of frightening how hard ffmpeg is to use without some kind of custom frontend. I have probably dozens of bash/python scripts to invoke ffmpeg for different common tasks.
- One to extract audio
- One to extract all the individual streams from a container
- A couple different transcoding scripts
- One specifically for gifs
- One to crop video
- A few that I can't remember the purpose of... and can't tell from reading the source
- physicles 4y agoI wrote one of those last week as a sort of poor man’s video editor. Besides aliases for common commands (like extracting a time range without re-encoding), it also takes the tedium out of repeatedly typing file names. Output file names are generated based on the input file name, with a prefix that auto-increments like sql. Input files can be referenced by prefix. It makes a huge difference.
- blunte 4y agoPerhaps because ffmpeg and other swiss army knife tools can do so many useful things.
- LeoPanthera 4y agoPeople always say this but... I'm not sure I agree. I think people confuse "hard" with "powerful". With the exception of cropping I can do all of the above from memory. Maybe I just use ffmpeg a lot.
- remram 4y agoA useful distinction is "complex" versus "difficult".
- anamexis 4y agoWhen it comes to UI, powerful often implies hard.
- tharkun__ 4y agoI think this is it. Repetition. You could threaten to kill me and I wouldn't be able to user ffmpeg from memory. I just don't have to use it often enough. So I created a script w/ the settings I usually want to encode certain things that I need to encode semi-often. It definitely doesn't make it easier to remember ffmpeg command line options because I don't have to use them. kubectl and our home grown command line tools to interact with our build and deployment? I know most of it by heart of course because I use it daily. I really don't like some of the scripts that we have and do it "by hand" instead because I have to use it all often enough that I want to know what is really going on underneath in case things don't go the way they should (and there's always something). I am able to diagnose and fix or work around all these issues with ease because of it, while lots of other people just run the wrapper scripts and if something doesn't work they very often aren't able to even troubleshoot the simplest problems. I'm that guy w/ ffmpeg ;)
- danbmil99 4y agoI thought everyone just searches for their exact needed pattern on SO
- Ruthalas 4y agoI just keep a "cook book" of common commands I've gathered from SO so I don't need to search each time to refresh my memory.
- tharkun__ 4y agoI'm pretty sure you meant this in a different way but it reminded me of another thing I see a lot with people. They have these huge lists (written down in some tool or another) of commands to do specific things and they copy and paste them. It's heart wrenching to see them search for these sometimes (even if they find them) and then they copy and paste them. But they sometimes (many times) don't work or are super simple things. Like the `kubectl get pod` thing I mentioned, they might have that in one of those lists under some heading like "dev environment commands" or somesuch together with 10 or 15 others. Because they never actually tried to understand the simple logic and meaning behind these command line tools and only ever copy and pasted, they get very easily tripped up by even the simplest things, such as replacing the parts that need to be adjusted for their specific situation, even if clearly marked, such as `kubectl -n <yournamespace> get pod` (or one that comes up even more often in troubleshooting sessions 'The command from the docs does not work and I made sure I copy and paste so I don't mistype it' and if you ask what they did it was `kubectl -n examplenamespace get pod`). Or they might have written down a command from the onboarding docs that combined multiple things into one command line. To fix issues with their environment, they have to basically nuke everything and start from scratch, because only then will their copy and pasted command actually work. They haven't learned to decompose these and use the parts individually or recompose them.
- deleted 4y ago[deleted]
- prox 4y agoIt’s the ‘wrong’ way to think about it in the sense of subjectivity : powerful in this context means lots of arguments and config settings you have to learn, memorize or look-up. That means you have to become an expert level user to become fluent (where the user would call it “easy”) It’s an UX that would exclude entry level computer user (since entry level here means not even knowing where the shell is for ffmpeg) and would perhaps be a barrier intermediate computer users.
- bscphil 4y agoffmpeg arguments generally compose pretty well, although it's powerful enough that (as other comments have mentioned) for special use cases you do often have to look things up. If you can remember 3 or 4 things you can do most stuff without looking anything up, however: -i -> input file -vcodec / -acodec -> video and audio codec; "copy" specifies copying the input stream -vn / -an / -sn -> disable the video / audio / subtitles in the output file -ss / -t -> specify the start time and length of the conversion from the input file So, just by looking at the above, you can easily see how to extract audio (or any individual stream). For gifs specifically I would recommend using gifski which has much better results anyway. For cropping, I don't find the `-vf crop` syntax too bad.
- nebster 4y agoBut when you have differing behaviour based on argument position like putting -ss / -t before the -i or after (fast seek vs accurate seek), it gets confusing pretty fast.
- jakeogh 4y agohaha me three mpv https://github.com/jakeogh/mpvpy https://github.com/jakeogh/mpvpy