FFmpeg by Example

Plus you need to know the format of your source file to design the command correctly. How many audio tracks, is the first video track a thumbnail or the video, are the subtitles tracks forced, etc.

And in some situations ffmpeg has some warts you have to go around. Like they introduced recently a moronic change of behaviour where the first sub tracks becomes forced/default irrespective of the original forced/default flag of the source. You need to add "-default_mode infer_no_subs" to counter that.

My feelings exactly, but I think that's OK!

It's another tool and one that might actually improve with time. I don't see GNU's man pages getting any better spontaneously.

Whoa, what if they started to use AI to auto-generate man pages...

Reading this feels like seing a guy getting his first car in 1920 and complaining he still has to drive it himself.

My experience exactly.

I no longer check with these AI tools after a number of attempts. Unrelated, a friend thought there was a NFL football game last Saturday at noon. Checking with Google's Gemini, it said "no", but there was one between two teams whose season had ended two weeks before at 1:00 Eastern Time and 2:00 Central. (The times are backwards.)

> "convert this mov to mp4"

Did any of the commands look like the ones in the left window:

https://beta.gitsense.com/?chats=12850fe4-ffb1-4618-9215-c13...

The left window contains a summary of all the LLMs asked, including all commands. The right window contains the individual LLM responses.

I asked about gotchas with missing libraries as well, and Sonnet 3.5 said there were. Were these the same libraries that were missing for you?

what exactly do you want the llm to do here? if the ask was so unambiguous and simple that it could be reliably generated, then the interface wouldn't be so complicated to use in the first place! LLMs are not in any way best suited for one-shot prompt => perfect output, and expectations to that effect are extremely unreasonable. the reason why LLMs are still hard for beginners to use is because the software is hard to use correctly. as with LLM output goes life itself: the results you get from using a tool can only ever be as good as the (mental) model used to choose that tool & the inputs to begin with. if all the information required to generate the output were contained by the initial prompt, then there would be absolutely no need to use the LLM at all in the first place.

Hate to be that guy, but which LLM was doing the generation? GPT-4 Turbo / Claude 3.x have not really let me down in generating ffmpeg commands - especially for basic requests - with most of their failures resulting from domain-specific vagaries that an expert would need to weigh in on m

[dead]

please is such an appropriate name. Will rename my ChatGPT alias to please.

It displays the generated command to you, there's an additional step to confirm.

> Did you just invent the LLM-equivalent of curl-piping unread shell scripts into sh?

Many such cases.

Just like all other code. There will be user-respecting open source code and tools, and there's user-disrespecting profitable closed code that makes too many decisions for you.

like pip but written in rust

I use regexes a lot. The main thing that always trips me up is dealing with escaping, because different tools I use – vim, sed, rg, and so on – sometimes have different meanings for when to escape or not.

In one tool you’ll use + to match one or more times, and \+ to mean literal plus sign.

In another tool you’ll use \+ to match one or more time, and + to mean literal plus sign.

In one tool you’ll use ( and ) to create a match group, and \( and \) to mean literal open and close parentheses.

In another tool you’ll use \( and \) to create a match group, and ( and ) to mean literal open and close parentheses.

This is basically the only problem I have when writing regexes, for the kinds of regexes I write.

Also, one thing that’s not a problem per se but something that leads me to write my regexes with more characters than strictly necessary is that I rarely use shorthand for groups of characters. For example the tool might have a shorthand for digit but I always write [0-9] when I need to match a digit. Also probably because the shorthand might or might not be different for different tools.

Regexes are also known to be “write once read never”, in that writing a regex is relatively easy, but revisiting a semi-complicated regex you or someone else wrote in the past takes a little bit of extra effort to figure out what it’s matching and what edits one should make to it. In this case, tools like https://regex101.com/ or https://www.debuggex.com/ help a lot.

No one doubts the power or utility of regexes or ffmpeg, but they are both complicated beasts that really take a lot of skill.

They're both tools where if they're part of your daily workflow you'll get immense value out of learning them thoroughly. If instead you need a regex once or twice a week, the benefit is not greater than the cost of learning to do it myself. I have a hundred other equally complicated things to learn and remember, half the job of the computer is to know things I can't put in my brain. If it can do the regex for me, I suddenly get 70% of the value at no cost.

Regex is not a tool I need often enough to justify the hours and brain space. But it is still an indespensible tool. So when I need a regex, I either ask a human wizard I know, or now I ask my computer directly.

in 15 years it never sticks and by the time i need it again i've forgotten it! :D

Almost no one cares to understand the domain of the tool anymore, they only want result and expect a simplified interface that already does the unique thing they want to do, but can’t accept that a power tool can only be used with training.

My rule for using LLMs is that anything that's one off is okay. Anything that's more permanent and committed to a repo needs a human review. I strongly suggest you have an understanding of the basics (at least the box model) so that you are competent at reviewing CSS code before using LLM for that.

I've been looking for a good guide on prompting LLMs for CSS.

does anyone know of any?

It's hard for a number to be even without first being an integer, no? ;-)

But thanks for '-2', didn't know about that! It's the exact default option I needed! Will be using that always from now on.

https://stackoverflow.com/questions/71092347/ffmeg-option-sc...

They still suck compared to software encoders. This is true for both H.264 and H.265 on AMD, Nvidia, and Intel GPUs. They’re “good enough” for live streaming, or for things like Plex transcoding, or where you care only about encoding speed and have a large bandwidth budget. They’re better than they used to be, but not worth using for anything you really care about.

That's my experience too. I transcode a lot of video for a personal project and hardware acceleration isn't much faster. I figure that's because on CPU I can max out my 12 cores.

The file size is also problematic I've had hardware encodes twice as large as the same video encoded with CPU.

I know they used to be worse, haven't tested the newest ones

Interesting. Yes, I assume that's possible although I'm not sure how you handle the background- I guess you find an empty frame, and subtract that from every image with a plane.

One of the advantages of working with image data is that movies are really just 3d data and as long as all the movies you work with are the same size, if you have enough ram, or use dask, you could basically do this in a couple lines of numpy.

Why's that counterintuitive? It makes intuitive sense to me that an approach optimized for throughput would make trade-offs that are less optimized for quality.

Fascinating, it didn't occur to me quality could take a hit, I thought the flag merely meant "perform h264 encoding over here"

Edit: relevant docs from ffmpeg, they back up your perception, and now I'm left to wonder how much I want to learn about profiles in order to cut up these videos. I suppose I'll run an overnight job to reencode them from Avi to h264 at high quality, and make sure the scene detect script is only doing copys, not reencoding, since that's the part I'm doing interactively, there's no real reason I should be sitting at the computer while its transcoding.

Hardware encoders typically generate output of significantly lower quality than good software encoders like x264, but are generally faster and do not use much CPU resource. (That is, they require a higher bitrate to make output with the same perceptual quality, or they make output with a lower perceptual quality at the same bitrate.)

[0] https://trac.ffmpeg.org/wiki/HWAccelIntro

I get that. My critique is for the library authors, not you.

>> I'm still looking for better/faster lossless YUV encoding.

> I wasn't able to produce results that were convincingly better than libx264

With "-qp 0"? Otherwise, it's not a valid comparison... "-crf 13" is nowhere near lossless (though it might appear so visually).

FFV1 is much better than H264 at lossless compression in my experience. Here's a random sample of a ten second 4K input I had handy (5.5G uncompressed):

    h264-ultrafast    1.951s   850M
    h264-veryslow    46.528s   715M
    ffv1              8.883s   637M

Not forgotten at all -- in fact, if your system has has a /tmp directory, it is almost certainly a RAMdisk.

Warp terminal does that. It's cool.

That would be an amazingly useful feature of ffmpeg, and considering how large its dependencies are (390MB of packages for `apt install ffmpeg` on a fresh Raspberry Pi OS install), it would be reasonable to have an optional model package.

I was kind of curious about that one too. It is encoding the SRT into the MP4/MOV subtitle format. I use it all the time when muxing subs into MP4s, but I haven't seen what happens with an MKV like that. It is very well supported in MP4s.

see lavfi-preview on github. Its GUI app for libavfilter/FFmpeg filters