Hacker News Reader

Comment by rosmax_1337 | Hacker News Reader

The greatest addition to FFmpeg in the recent past was the addition of large language models translating my "ffmpeg command to mix audio file onto video file" into actually executable FFmpeg commands.

Being cheeky of course here. FFmpeg is great. An AI assistant was what I needed to execute my ~12 FFmpeg commands per year though, with ease and speed.

View on HN

ChatGPT / LLMs really are great with ffmpeg. Not too long ago I wrote a blog post outlining an ffmpeg command I needed (mostly for my own future reference). It almost feels quaint now, given that you can get the same kind of explanation from GPT. I bet if I pasted the command in my article into ChatGPT I would get an explainer that's basically identical to what I wrote.

https://epiccoleman.com/posts/2023-03-19-ffmpeg-mp4-webm

I did this yesterday and first the command it gave me was wrong.

GPT4?

It’s whatever the free default is. I’m not going to give them money if it can’t get basic things right.

Yea they are limiting their growth by not giving a peek. It's a world of difference. Try it via API for $0.50.

Paste the man page into the prompt

LLMs are the best thing to happen to command line tools. I get so much productivity out of them now.

It's frustrating when they give you a plausible answer that doesn't exist though.

it is, but typing "no, `--do-x` is not a valid option, please only give me real commands" back into a chat window is a hell of a lot less frustrating than sifting through docs that may or may not even exist.

Seems risky to start running commands on your machine that a hallucinating AI spit out at you without understanding them, but I guess they can at least let you know what to look up so you can double check what the command will do.

It really depends on what you're doing right? Any command line work that I use an LLM to help with is non-destructive. I'll use jq, ffmpeg, etc., but I don't update the initial source.

I’m not writing another line of regex lol

I feel the same about sed and awk :)

Oh, you nailed it. I was so excited the moment I realized I didn't have to struggle with that complicated CLI

I mean I've only done it once with ffmpeg but it felt so good

I did it just today to convert a Filipino movie I yt-dlp'd from WebM to MP4. Teen me would be so excited by this excellent new world of ours.

But but, yt-dlp can download it to .MP4 or .mkv already? It invokes ffmpeg during its final steps.

I always do

  yt-dlp -f "bestvideo[ext=mp4]+bestaudio[ext=m4a]/best[ext=mp4]/best"

Not sure if there is a better way, ideally I would just like it to always default to that.

You can put these options in a config file and they will become the default: https://github.com/yt-dlp/yt-dlp?tab=readme-ov-file#configur...

As the sibling poster said, you can and should configure `yt-dlp`. Here are the contents of my config file:

    --restrict-filenames
    --output '%(title)s.%(ext)s'
    --ignore-errors
    --embed-subs
    --all-subs
    --sub-langs all,-live_chat
    --compat-options no-live-chat
    --convert-subs srt
    --format 'vcodec=av01/bestvideo[ext=mp4]+bestaudio[ext=m4a]/best[ext=mp4]/best'
    --convert-thumbnails jpg
    --embed-thumbnail
    --audio-quality 0
    --add-metadata
    --xattrs
    --xattr-set-filesize
    --prefer-free-formats
    --geo-bypass
    --no-mark-watched
    --console-title
    --no-warnings
    --sponsorblock-remove all
    --compat-options embed-thumbnail-atomicparsley

You can look them up on the README. It's quite a bit of work, granted, but to me it was very worth it.

Wow thank you for sharing! I might just use yours, looks almost exactly like what I would want.

yt-dlp really is a great tool too, I do hope it keeps working for a long time

> ext=mp4

> prefer-free-formats

Are you entirely sure you know what you are doing?

Did you miss the "prefer" word? ;)

I'll take that as a no.

I am half-aware of the licensing troubles of various video formats but I wish those companies luck going after each and every home video user. ¯\_(ツ)_/¯

...OK, you made me double-check. Used this instead:

    --format 'vcodec=av01/bestvideo*+bestaudio/best'

And it started downloading `.webm` streams and not `.mp4` (only one video had an AV1 stream). Tested with several videos, quality is the same and some files are actually 40% smaller.

...Whoa. Thanks for making me double-check!

Somebody down-voted you, I seem to recall seeing earlier, sorry about that. Your comment was valuable, though I'd definitely use more productive tone next time.

(Comment 3 / 3)

And finally, after some more tests it turned out that some videos have almost 2x bigger .webm variants than .mp4 so I had to extend my yt-dlp config like so (only showing the prioritization options here, my previous full config is still there upthread):

    --format 'vcodec=av01/bestvideo*+bestaudio/best'
    --format-sort 'quality,res,fps,hdr:12,vcodec:av01,channels,acodec,abr,asr,proto,ext,hasaud,source,id'
    --prefer-free-formats

This:

1. Prioritizes AV1 (because it's gaining more and more hardware support, is very efficient and is not license-encumbered)

2. Prefers the free formats

3. ...but still uses a non-free format if it's smaller.

Or at least that's what I believed in after testing on 7 videos that have obvious winners either way.

Makes you wonder why developers had to invent such shitty CLI UX in the first place instead of natural language syntax, keywords, and arguments.

Probably because:

1. ffmpeg exposes all of its options through the CLI, and there are a lot of options. So it's probably always going to be completely undiscoverable. It really needs a GUI to be usable, but that's a project in itself (I guess the project is Handbrake).

2. They probably didn't put a lot of work into the UX of the CLI since it's an open source project.

3. Backwards compatibility.

>So it's probably always going to be completely undiscoverable. It really needs a GUI to be usable, but that's a project in itself (I guess the project is Handbrake).

I don't buy this. A TUI is completely possible, e.g. LazyGit, Htop, etc, countless tools indicate you can get pane-based UIs going in the terminal; the FFmpeg team has simply never made such a thing a priority.

But even without a TUI, the most basic use-cases are well-known after over 15+ years of existence, simple prompt-based wizards, i.e. "git add -p", should be offered; again, a matter of priority rather than being intractable.

A year ago or so someone posted a subscription service they made for composing the pipeline graph visually

> A TUI is completely possible

Sure. A TUI is basically a poor man's GUI.

> simple prompt-based wizards, i.e. "git add -p", should be offered

I agree. Wouldn't be hard. I think you may as well use Handbrake though.

Natural language syntaxes universally suck. A faux english syntax isn't easier to use if you don't know which english in particular will be accepted. A complex cli interface fundamentally can't be easy to use. A GUI can fix that by making things discoverable and by integrating the documentation into the UI, but the ffmpeg devs presumably see that as someone else job (and there have been people to step up).

Reply on news.ycombinator.com