Live data from Hacker News

Show HN: Ez FFmpeg – Video editing in plain English

npmjs.com

101–110 of 210 posts

Re: Show HN: Ez FFmpeg – Video editing in plain English

#101
post #47

I was surprised that macOS (QuickTime/Preview, iMovie) can't read .mp4 files. Not sure if it was due to H.265 or the audio codec. I tried using ffmpeg to convert to .mov but that also failed to open, since I guess MOV is just another container format. Is there an easier way?

Try something like: ffmpeg -i in.mp4 -c:v h264 -c:a aac out.mp4 To re-encode the content into H.264+AAC, rather than simply "muxing" the encoded bitstreams from the MP4 container into a new MOV container.

Thanks, I can even somewhat remember that. AI gave me args like

  -c:v libx264 -pix_fmt yuv420p -preset medium -crf 18 \
  -c:a aac -b:a 192k \

Re: Show HN: Ez FFmpeg – Video editing in plain English

#102

Earlier quoted context omitted.

> 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. Not really sure how else I was supposed to interpret your comment but clarification taken. > But I argue in my comment above that this specific tool does not have better QoL For some folks it may be better/mor…

> Not really sure how else I was supposed to interpret your comment Yes, that was a bit facetious of me, I apologize for that. > What is so bad about the existence of this project? Being very blunt: The fact that it reinforces the extremely common misconception that a) converting between containers like mkv and mp4 will always require reencoding and that b) there is a single way to reencode a video (hence suggesting…

I get what you’re saying but at the end of the day you just need to think about how most people use a tool like this. They’re looking for a simple solution to some specific problem and then they’re likely never using it again. They don’t want to deal with a full-on NLE and iMovie or whatever they have stocked is not cutting it. It’s not worth getting bent out of shape about it ultimately. There are tons of people who use ffmpeg as intended in its original form and more or less understand everything that is going on. The reason we have so many wrappers and variations all centered around ffmpeg is because of how useful it is, so it’s clearly here to stay.

I personally use lossless cut more than ffmpeg in the terminal just because I don’t have to really think about it and it can do most of what I need, which is simply removing or attaching things together without re-encoding. I use it maybe once every month or two, because it’s just not something I need to use a ton, so it doesn’t make sense for me to get down and dirty with the original. Ultimately I get what I need and I’m happy!

Re: Show HN: Ez FFmpeg – Video editing in plain English

#103
post #57

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…

> It's really not that hard,

I've learned not to say this. Different things are easy/hard for each of us.

Reminds me of a discussion where someone argued, "why don't all the poor/homeless people just go get good jobs?"

Edit: I know your comment was meant to inspire/motivate us to try harder. Maybe it's easier than it appears.

Re: Show HN: Ez FFmpeg – Video editing in plain English

#104
post #57

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…

> It's really not that hard,

if you are doing it often that's true. But for people like me who do it once every month or two it really is hard to memorize, especially if it's not exactly the same task.

What I would love would be an interactive script that asked me what I was trying to do and constructed a command line for me while explaining what it would do and the meaning of each argument. And of course it should favour commands that do not re-encode where possible.

Re: Show HN: Ez FFmpeg – Video editing in plain English

#105
post #57

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…

> It's really not that hard, I've learned not to say this. Different things are easy/hard for each of us. Reminds me of a discussion where someone argued, "why don't all the poor/homeless people just go get good jobs?" Edit: I know your comment was meant to inspire/motivate us to try harder. Maybe it's easier than it appears.

Empathy is really not that hard.

Re: Show HN: Ez FFmpeg – Video editing in plain English

#106
I actually just use Claude code. “Stabilize the video x.mp4 and keep my daughter Astra as the subject. Convert it to a GIF that is under a megabyte”. It does a great job.

It will sample images from the video then go crop the video to that, stabilize if required, and then make me an optimized GIF that I can put in my weekly journal.

Re: Show HN: Ez FFmpeg – Video editing in plain English

#107
post #70

Earlier quoted context omitted.

What's the reward for trivializing real issues and coming up with broken "solutions"? > It's very easy to type `apropos ffmpeg` No it's not. First, that's not a Windows command, so right off the bat you've cut off the largest OS. Second, your command is naively empty and it's telling that you've given it instead of an actual search query because you wouldn't be able to come up with a great one right away that would r…

> What's the reward for trivializing real issues and coming up with broken "solutions" Then any solutions is broken in this way. Even my bluetooth speaker comes with a manual. Not reading it and saying the speaker is broken, because you can't figure how to connect is pure delusion. Same as not reading ffmpeg manual and expecting to know how to use it. > First, that's not a Windows command, so right off the bat you've…

> Then any solutions is broken in this way.

Nope, you're just doing the same thing - purposefully ignoring the issue to make your non-solution comparable...

> Even my bluetooth speaker comes with a manual.

... in this case - the length and scope of the manual. First, you can operate the speaker without the manual or with just a single read of the manual- so spend a few seconds to learn how to pair (but you might not even need that as "hold to pair" might be something you remember from other devices), then the power/volume buttons require no manual because you've operated such buttons your whole life.

> Same as not reading ffmpeg manual

Of course it's not the same, the ffmpeg manual isn't a tiny page of 5 items, and no other apps will help you learn the peculiarities of ffmpeg. Also, the whole point of intuitive UI with "typed info" is that you don't need to read that huge manual to do the basics as you can simply follow the structure laid out by someone more knowledgeable

> ffmpeg on Window is so far the beaten path that it may as well be in Mordor. I would gladly bet that someone that knows how to run ffmpeg on windows also knows how to find the documentation for it.

Who would take that irrelevant bet? The issue isn't in finding! the manual!

> Why would I find the perfect query?

To prove that your solution works. I know it doesn't and challenge you to prove otherwise. Your suggestion is worse than asking users to Google, because at least there users will likely get the correct top result in a few tries for common needs

> Do you go in the library and then find the correct line of the correct book in one go?

No, I open an app and pick the correct format from the drop-down menu correctly in one go

> Or do you consult the list of books of books for a theme, select a few candidates, consult their index, and then read the pages?

Oh man, even in your fantasies you can't come up with a good workflow! No wonder you're fine suggesting everyone wastes a lot of time aproposing empty queries

Re: Show HN: Ez FFmpeg – Video editing in plain English

#108
post #9

When 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

It’s a shame this isn’t the default.

Re: Show HN: Ez FFmpeg – Video editing in plain English

#109

The total upheaval of the current computing paradigm that AI will bring, if nothing else, is "Hey computer, can you convert that funny kitchen cooking scene in this movie to a .gif I can share online?" You're wasting your time on a dead man walking paradigm doing anything else. "Plain English" actually means plain English now.

You're not wrong, but also there is value in a tool that will behave the same way consistently and has been vetted. I wouldn't be so down on this work.

Re: Show HN: Ez FFmpeg – Video editing in plain English

#110

The total upheaval of the current computing paradigm that AI will bring, if nothing else, is "Hey computer, can you convert that funny kitchen cooking scene in this movie to a .gif I can share online?" You're wasting your time on a dead man walking paradigm doing anything else. "Plain English" actually means plain English now.

You're not wrong, but also there is value in a tool that will behave the same way consistently and has been vetted. I wouldn't be so down on this work.

It is a bit of a catch-22, a plain english wrapper opens up the tool to be more widely used by novices, but also prevents those novices from actually learning the tool.
Post reply on HN