Impressed anytime I have to use it (even if I have to study its man page again or use an LLM to construct the right incantation or use a GUI that just builds the incantation based on visual options). Becoming an indispensable transcoding multitool.

I think building some processing off of Vulkan 1.3 was the right move. (Aside, I also just noticed yesterday that Asahi Linux on Mac supports that standard as well.)

> incantation

FFmpeg arguments, the original prompt engineering

OT, but yours has to be the best username on this site. Props.

Culón is Spanish for big-bottomed, for anyone else wondering.

I'd also include Regex in the list of dark arts incantations.

I'm ok with regex, but the ffmpeg manpage, it scares me...

Ffmpeg was designed to be unusable if it falls into enemy hands.

I am perfectly at home with regexp, but ffmpeg, magick, and jq are still on the list to master.

with gemini-cli and claude-cli you can now prompt while it prompts ffmpeg, and it does work.

Yeah, you can give an LLM queries like “make this smaller with libx265 and add the hvc1 tag” or “concatenate these two videos” and it usually crushes it. They have a similar level of mastery over imagemagick, too!

Yeah, LLMs have honestly made ffmpeg usable for me, for the first time. The difficulty in constructing commands is not really ffmpeg's fault—it's just an artifact of the power of the tool and the difficulties in shoehorning that power into flags for a single CLI tool. It's just not the ideal human interface to access ffmpeg's functionality. But keeping it CLI makes it much more useful as part of a larger and often automated workflow.

Just seeking a clarification on how this would be done:

One would use gemini-cli (or claude-cli),

- and give a natural language prompt to gemini (or claude) on what processing needs to be done,

- with the correct paths to FFmpeg and the media file,

- and g-cli (or c-cli) would take it from there.

Is this correct?

Another option is to use a non-cli LLM and ask it to produce a script (bash/ps1) that uses ffmpeg to do X, Y, and Z to your video files. If using a chat LLM it will often provide suggestions or ask questions to improve your processing as well. I do this often and the results are quite good.

Yes. It works amazingly well for ffmpeg.

Thank you.

Curious to see how quickly each LLM picks up the new codecs/options.

I use the Warp terminal and I can ask it to run —-help and it figures it out

the canonical (if that's the right word for a 2-year-old technique) solution is to paste the whole manual into the context before asking questions

Gemini can now load context from a URL in the API (https://ai.google.dev/gemini-api/docs/url-context), but I'm not sure if that has made it to the web interfaces yet.

nope, that would be handling tar balls

ffmpeg right after

Tough crowd.

fwiw, `tar xzf foobar.tgz` = "_x_tract _z_e _f_iles!" has been burned into my brain. It's "extract the files" spoken in a Dr. Strangelove German accent

Better still, I recently discovered `dtrx` (https://github.com/dtrx-py/dtrx) and it's great if you have the ability to install it on the host. It calls the right commands and also always extracts into a subdir, so no more tar-bombs.

If you want to create a tar, I'm sorry but you're on your own.

I used tar/unzip for decades I think, before moving to 7z which handles all formats I throw at it, and have the same switch for when you want to decompress into a specific directory, instead of having to remember which one of tar and unzip uses -d, and which one uses -C.

"also always extracts into a subdir" sounds like a nice feature though, thanks for sharing another alternative!

> tar xzf foobar.tgz

You don't need the z, as xf will detect which compression was used, if any.

Creating is no harder, just use c for create instead, and specify z for gzip compression:

  tar czf archive.tar.gz [filename(s)]

Same with listing contents, with t for tell:

  tar tf archive.tar.gz

I have so much of tar memorized. cpio is super funky to me, though.

Personally I never understood the problem with tar balls.

The only options you ever need are tar -x, tar -c (x for extract and c for create). tar -l if you wanna list, l for list.

That's really it, -v for verbose just like every other tool if you wish.

Examples:

  tar -c project | gzip > backup.tar.gz
  cat backup.tar.gz | gunzip | tar -l
  cat backup.tar.gz | gunzip | tar -x

You never need anything else for the 99% case.

For anyone curious, unless you are running a 'tar' binary from the stone ages, just skip the gunzip and cat invocations. Replace .gz with .xz or other well known file ending for different compression.

  Examples:
    tar -cf archive.tar.gz foo bar  # Create archive.tar.gz from files foo and bar.
    tar -tvf archive.tar.gz         # List all files in archive.tar.gz verbosely.
    tar -xf archive.tar.gz          # Extract all files from archive.tar.gz

> tar -cf archive.tar.gz foo bar

This will create an uncompressed .tar with the wrong name. You need a z option to specify gzip.

Apparently this is now automatically determined by the file name, but I still habitually add the flag. 30 years of muscle memory is hard to break!

I tried it to check before making the comment. In Ubuntu 25.04 it does not automatically enable compression based on the filename. The automatic detection when extracting is based on file contents, not name.

> tar -l if you wanna list, l for list.

Surely you mean -t if you wanna list, t for lisT.

l is for check-Links.

     -l, --check-links
             (c and r modes only) Issue a warning message unless all links to each file are archived.

And you don't need to uncompress separately. tar will detect the correct compression algorithm and decompress on its own. No need for that gunzip intermediate step.

> -l

Whoops, lol.

> on its own

Yes.. I'm aware, but that's more options, unnecessary too, just compose tools.

That's the thing. It’s not more options. During extraction it picks the right algorithm automatically, without you needing to pass another option.

Yeah I never really understood why people complain about tar; 99% of what you need from it is just `tar -xvf blah.tar.gz`.

You for got the -z (or -a with a recent gnutar).

It’s no longer needed. You can leave it out and it auto-detects the file format.

A tar of gzip or zip files doesn't make sense. But gzipping or zipping a tar does.

Gzip only compresses a single file, so .tar.gz lets you bundle multiple files. You can do the same thing with zip, of course, but...

Zip compresses individual files separately in the container, ignoring redundancies between files. But .tar.gz (and .tar.zip, though I've rarely seen that combination) bundles the files together and then compresses them, so can get better compression than .zip alone.

The zip directory itself is uncompressed, and if you have lots of small files with similar names, zipping the zip makes a huge difference. IIRC in the HVSC (C64 SID music archive), the outer zip used to save another 30%.

Plain old zip is tricky to parse correctly. If you search for them, you can probably find about a dozen rants about all the problems of working with ZIP files.

zip doesn't retain file ownership or permissions.

Good point. And if I remember right, tar allows longer paths than zip.

Except it's tar -t to list, not -l

Whoops, lol. Well that's unfortunate.

    gzip -dc backup.tar.gz | tar -x

You can skip a step in your pipeline.

It's very similar to every other CLI program, I really don't understand what kind of usability issue you're implying is unique to tar?

And why is -v the short option for --invert-match in grep, when that's usually --verbose or --version in lots of other places. These idiosyncrasies are hardly unique to tar.

nope, it's using `find`.

LLMs and complex command line tools like FFmpeg and ImageMagick are a perfect combination and work like magic…

It’s really the dream UI/UX from sience fiction movies: “take all images from this folder and crop 100px away except on top, saturate a bit and save them as uncompressed tiffs in this new folder, also assemble them in a video loop, encode for web”.

Had to do exactly that with a bunch of screenshots I took but happened to include a bunch of unnecessary parts of the screen.

A prompt to ChatGPT and a command later and all were nicely cropped in a second.

The dread of doing it by hand and having it magically there a minute later is absolutely mind blowing. Even just 5 years ago, I would have just done it manually as it would have definitely taken more to write the code for this task.

it can work but it's far from science fiction. LLMs tend to produce extremely subpar if not buggy ffmpeg code. They'll routinely do things like put the file parameter before the start time which needlessly decodes the entire video, produce wrong bitrates, re-encode audio needlessly, and so on.

If you don't care enough about potential side effects to read the manual it's fine, but a dream UX it is not because I'd argue that includes correctness.

ffmpeg -i in -ss start -to end out is wrong and bad? You can -ss before -i? TIL!

Are you accusing Blade Runner of infringing FFmpeg IP ?

LLMs are a great interface for ffmpeg. There are tons of tools out there that can help you run it with natural language. Here's my personal script: https://github.com/jjcm/llmpeg

i wrote a command “please” that allows me to say “please use ffmpeg to do whatever” and it generates the command with confirmation

This is why [former Codeium] Windsurf's name is so genius.

Windsurfing (the real activity) requires multiple understandings:

1) How to sail in the first place

2) How to balance on the windsurfer while the wind is blowing on you

If you can do both of those things, you can go VERY fast and it is VERY fun.

The analogy to the first thing is "understanding software engineering" (to some extent). The analogy to the second thing is "understanding good prompting while the heat of deadlines is on you". Without both, you are just creating slop (falling in the water repeatedly and NOT going faster than either surfing or sailing alone). Junior devs that are leaning too hard on LLM assistance right off the bat are basically falling in the water repeatedly (and worse, without realizing it).

I would at minimum have a policy of "if you do not completely understand the code written by an LLM, you will not commit it." (This would be right after "you will not commit code without it being tested and the tests all passing.")

Sounds like every product manager I've ever had, lol (sorry PM's!)

I love Elixir but you cannot compile it into a single binary, it is massively concurrent but single-threaded slow, and deployment is still nontrivial.

And lists are slower than arrays, even if they provide functional guarantees (everything is a tradeoff…)

That said, pretty much everything else about it is amazing though IMHO and it has unique features you won’t find almost anywhere else

I `ln -s` mine to CLAUDE.md for convenience

I have an odd obsession with github repos that only have 1 file

Doesnt really sound like an odd obsession - it's an AI workflow thing. Just copy-pasting everything.

> Anything that can be computed inside your physical body, can be calculated in an "artificially" constructed replica.

What's hilarious about this argument (besides the fact that it smacks of the map-territory relation fallacy https://en.wikipedia.org/wiki/Map%E2%80%93territory_relation) is that for most of my life (53 years), we've been trying not just to simulate a nematode or Drosophila (two of the most-studied creatures of all time- note that we COMPLETELY understand their nervous systems) and failed to create anything remotely convincing of "life" (note that WE are the SOLE judgers of what is "alive", there is no 100% foolproof mechanistic algorithm to detect "life" (look up the cryptobiosis of tardigrades or wood frogs for an extra challenge)... therein lies part of the problem), but we cannot even convincingly simulate a single cell's behavior in any generous span of time (so for example, using a month to compute 10 seconds of a cell's "life"). And yes, there have been projects attempting to do those things this entire time. You should look them up. Tons of promise, zero delivery.

> Given enough time, we'll create that replica, there's no reason to think otherwise.

Note how structurally similar this is to a "God of the gaps" argument (just substitute "materialism-given-unlimited-time" for "God").

And yet... I agree that we should continue to try. I just think we will discover something interesting in... never succeeding, ever... while you will continue to refer to the "materialism-given-unlimited-time of the gaps" argument, assuming (key word there) that it must be successful. Because there can't possibly be anything else going on. LOL. Naive.

(Side note, but related: I couldn't help noticing that most of the AI doomers are materialist atheists.)

Yes. See: Steve Jobs, maybe.

> LLMs have a different failure mode than professionals

That actually supports the use-case of collaboration, since the weaknesses of both humans and LLMs would potentially cancel each other out.

Wow. I had never heard this before.