Days since last ffmpeg CLI wrapper: 0 It's incredible what lengths people go to to avoid memorizing basic ffmpeg usage. It's really not that hard, and the (F.) manual explains the basic concepts fairly well. Now, granted, ffmpeg's defaults (reencoding by default and only keeping one stream of each type unless otherwise specified) aren't great, which can create some footguns, but as long as you remember to pass `-c co…
Show HN: Ez FFmpeg – Video editing in plain English
71–80 of 210 posts
Re: Show HN: Ez FFmpeg – Video editing in plain English
#72When converting video to gif, I always use palettegen, e.g. ffmpeg -i input.mp4 -filter_complex "fps=15,scale=640:-2:flags=lanczos,split[a][b];[a]palettegen=reserve_transparent=off[p];[b][p]paletteuse=dither=sierra2_4a" -loop 0 output.gif See also: this blog post from 10 years ago [1] [1] https://blog.pkh.me/p/21-high-quality-gif-with-ffmpeg.html
Those command flags just roll off the tongue like two old friends catching up! /s
Re: Show HN: Ez FFmpeg – Video editing in plain English
#73Days since last ffmpeg CLI wrapper: 0 It's incredible what lengths people go to to avoid memorizing basic ffmpeg usage. It's really not that hard, and the (F.) manual explains the basic concepts fairly well. Now, granted, ffmpeg's defaults (reencoding by default and only keeping one stream of each type unless otherwise specified) aren't great, which can create some footguns, but as long as you remember to pass `-c co…
Re: Show HN: Ez FFmpeg – Video editing in plain English
#74Days since last ffmpeg CLI wrapper: 0 It's incredible what lengths people go to to avoid memorizing basic ffmpeg usage. It's really not that hard, and the (F.) manual explains the basic concepts fairly well. Now, granted, ffmpeg's defaults (reencoding by default and only keeping one stream of each type unless otherwise specified) aren't great, which can create some footguns, but as long as you remember to pass `-c co…
Re: Show HN: Ez FFmpeg – Video editing in plain English
#75Earlier quoted context omitted.
Do most devs even look at the source code for packages they install? Or the compiled machine code? I think of this as just a higher level of abstraction. Confirm it works and not worry about the details of how it works
I don’t because I trust the process to get the artifacts. Why? Because it’s easy to replicate and verify. Just like how proof works in math. You can’t verify LLM’s output. And thus, any form of trust is faith, not rational logic.
With an LLM’s output, it is short enough that I can* put in the effort to make sure it's not obliviously malicious. Then I save the output as an artefact.
* and I do put in this effort, unless I'm deliberately experimenting with vibe coding to see what the SOTA is.
Re: Show HN: Ez FFmpeg – Video editing in plain English
#76Days since last ffmpeg CLI wrapper: 0 It's incredible what lengths people go to to avoid memorizing basic ffmpeg usage. It's really not that hard, and the (F.) manual explains the basic concepts fairly well. Now, granted, ffmpeg's defaults (reencoding by default and only keeping one stream of each type unless otherwise specified) aren't great, which can create some footguns, but as long as you remember to pass `-c co…
so you know how to swap audio with -map without having to look it up?
Re: Show HN: Ez FFmpeg – Video editing in plain English
#77Earlier quoted context omitted.
so you know how to swap audio with -map without having to look it up?
I do, yes. Though that's not really the point, it'd already be enough to know where to look it up.
There isn't internal consistency to really hold on to ... it's just a bunch of seemingly independent options.
The biggest problem is open source teams really don't get people on board that focus on customer and product the way commercial software does. This is what we get as a result
Re: Show HN: Ez FFmpeg – Video editing in plain English
#78Earlier quoted context omitted.
I do, yes. Though that's not really the point, it'd already be enough to know where to look it up.
no the point is that there are some things I've done a hundred times and I never remember it because it's designed in a wildly bad way. ffmpeg, gpg, openssl and git has those things all over the place. Is it -c:v or -v:c? I don't know. used to be -vcodec so it's -v:c now? no it's -c:v I think because they swapped it? There isn't internal consistency to really hold on to ... it's just a bunch of seemingly independent…
Sure, I agree with all of this. Like I said above, the syntax (and, even more, the defaults) isn't great. I'm just arguing that "improving the syntax" should not mean "hiding complexity that should not be hidden", as the linked project does. An alternative ffmpeg frontend (i.e. a new CLI frontend using the libav* libraries like ffmpeg is, not a wrapper for the ffmpeg CLI program) with better syntax and defaults but otherwise similar capabilities would be a very interesting project.
(The answer to your question is that both -vcodec and -c:v are valid, but I imagine that's not the point.)
> The biggest problem is open source teams really don't get people on board that focus on customer and product the way commercial software does.
I believe in this case it may be more of a case of backwards compatibility, with options being added incrementally over time to add what was needed at the moment. Though that's just my guess.
Re: Show HN: Ez FFmpeg – Video editing in plain English
#79I like the idea, but a CLI utility dependent on Node.js is not a good thing frankly.
Re: Show HN: Ez FFmpeg – Video editing in plain English
#80Earlier quoted context omitted.
LLMs are an amazing advance in natural language parsing. The problem is someone decided that and the contents of Wikipedia was all something needs to be intelligent haha
The confusion was thinking that language is the same thing as intelligence.