At least some of your requirements are directly implemented in Handbrake, e.g., there are different transcoding presets [0] and burning in subs [1]. It uses ffmpeg under the hood as well.

[0] https://handbrake.fr/docs/en/1.5.0/technical/official-preset... [1] https://handbrake.fr/docs/en/1.5.0/advanced/subtitles.html

My problem with Handbrake was that it wasn't correctly copying creation datetime/makernotes/camera info into the new video and I had to manually later on issue bunch of ffmpeg commands for copying stream metadata, at which point I might as well do the whole conversion directly in ffmpeg.

But if you are dealing with repeatable, consistent file format (like files coming from the same camera), you are way better off going the command line route, and chances are the command will be pretty simple.

I could have dived into the log files and looked more closely at what it was doing but, eh, I'm at the level where I just want a batch script where I can see exactly what it's doing upfront. If I want batching/task management that is more advanced than a batchfile can do I'll set up SLURM workload manager.

Then there are those that want a more generic version that allows all the bells & whistles to become available in the GUI. However, now you need to have a much better understanding of FFMPEG which the vast majority of FFMPEG users don't know (I myself learn new things everytime a new task is given).

At the end of the day, give it a go yourself to build a UI on top of FFMPEG to expose all of the things you just requested and see how painful it can be. I've done it multiple times for multiple jobs and not one of them was the same. It gets even more fun when you have sources with a combination of discrete and interleaved audio streams with high channel counts. Now, you have to probe the source and provide that info to the user to allow for output audio considerations. Based on those, you then need to potentially merge/join/split/map the audio. It's maddingly fun to those with those sense of perversions like me.

This isn't THE only issue with FFMPEG. There are many many problems with FFMPEG, but it's the best thing we have in this area. Warts and all, I would probably, no, definitely would not have been able to achieve many of the career accomplishments I have without it.

As you start to reveal the multitude of switches/options/etc available to FFMPEG via GUI, the GUI becomes gnarly and complicated very quickly. This then becomes just as daunting to the avg user as trying to build the command itself. There are many practical uses for a very simplified GUI to achieve a limited set of functionality. There's nothing wrong with it. In fact, I'd be willing to guess that if a UI came along that exposed every single thing that FFMPEG could do, fewer people would use it than a much more simplified version.

There are infamously a lot of tasks that "look easy upfront but have a lot of underlying complexity" and ffmpeg is not one of them. It's a task that looks hard upfront and then when you get down into the weeds it's an eye-bleeding eldritch monstrosity.

The consensus around MP4 and MKV containers and some relatively small number of codecs (H264, H265, VP1, AV1, etc) has substantially eased things but video codecs, audio codecs, and container files are just complicated af.

And believe it or not - this is still way, way better than it used to be! Flaskmpeg was never stable, Virtualdub was nice but development ended with avi container files, there were some forks that added various features, etc, but ffmpeg and OBS Studio both actually just work incredibly well compared to what came before.

except not everyone has decided to use that easing of the things. it seems like they go out of their way to make things difficult

My favorite is in how MP4s are not all the same. A video captured on a DSLR or other acquisition camera source might have +/- in the video/audio sync when imported into an NLE. Yes, the container utilizes PTS syncing to playback the video/audio streams in sync, but this +/- slop in sync is annoying AF to professionals capable of seeing the sync slop. Average consumers probably never notice. I thank all the gawds in all the heavens that I no longer have to edit MP4 source captured content and all of the manual slipping in the NLE.

But...sometimes you want one particular thing, that thing is relatively simple (compared to e.g. H.264 decoding), and you have needs ffmpeg doesn't meet. Then you probably can do better. A couple examples that have come up for me:

* specialized .mp4 muxing. My NVR project does this in a way where it can do HTTP range serving, so put the moov up front, produce the length quickly, and produce a given byte range without iterating through all the bytes before. ffmpeg can't do that, understandably. Hard to do in a general-purpose library; the container muxing input interface doesn't expect all the necessary information is available up front. But it's not that bad as a one-off. As you say, the consensus around a small number of containers really helps.

* RTSP. Consistent with your "modules that mostly work, usually, mostly", ffmpeg has various long-standing bugs in its RTSP handling (e.g. https://trac.ffmpeg.org/ticket/5018), has the risk associated with protocol handling in a non-memory-safe language, doesn't have much of a test framework for this, etc. This problem is relatively approachable (though hardly trivial), so I had success making my own library.

http://bropages.org/ffmpeg

The antidote to ffmpeg's arcane command-line has always been finding someone else who already did it and seeing what they did differently. There are, of course, many ways to skin the cat in ffmpeg, but you often just need to see some finished, working commands and start from there.

You could of course build that on a wiki somewhere, ffmpeg does have various examples in their docs, but bropages is a place to curate that sort of stuff.

You'll need a client for it (tldr itself is just the database). I recommend tealdeer [2].

Example:

    $ tldr tar

      Archiving utility.
      Often combined with a compression method, such as gzip or bzip2.
      More information: <https://www.gnu.org/software/tar>.

      [c]reate an archive and write it to a [f]ile:

          tar cf target.tar file1 file2 file3

      [c]reate a g[z]ipped archive and write it to a [f]ile:

          tar czf target.tar.gz file1 file2 file3

[2]: https://github.com/dbrgn/tealdeer

    Often combined with a compression method, such as gzip or bzip2.

    [...]

    [c]reate a g[z]ipped archive and write it to a [f]ile:

       tar czf target.tar.gz file1 file2 file3

There's no real problem, but I never like it when I'm given an example that seems to be going out of its way to suggest something untrue.

One thing I hate about CLI tool though, is that it's very hard to edit long commands in terminal.

For example, to replace the input filename from the previous command. I can do it in one second with my keyboard + mouse (use the mouse to select the old one, and type in the new one which would replace) in editor but you can't do so in terminal.

Another example is to change the order of some switches. Again very easy in text editor, not so much in terminal.

So, everytime I use FFMPEG for some complex one (especially when I need to go through trial and error, I have to write the thing in a text editor and them paste them into terminal.

> It's a small key sequence: ctrl-x e . What's this do? It takes the existing command that you currently have on your command line and opens it in your shell's editor

Apart from the "wrap it in a shell script" advice, I would also note that in a bash-like terminal, home and end will jump to the start or the end of the current command buffer, and ctrl-del (or alt-del maybe?) or ctrl-arrow keys usually delete or move the cursor a whole word at a time, which makes it somewhat quicker to work rather than sitting there holding an arrow key or backspce.

Many here probably already know this, some may not!

Now this got me thinking: the main problem with terminal is that it doesn't seem to support "cut" (and consequently, "paste to replace selection"). So re-arranging a command string is always gonna be a pain regardless the complexity.

I can see why it was this way historically, but not exactly sure why no modern terminal emulator gives this feature, even as optional.

Only a madman would do this. I don't know anyone that's in the middle of R&D that builds directly in the CLI that's sane. Everyone tries it, and just at the point of losing sanity, does the rational thing of building the command in a text editor for a simple copy&paste into the CLI later.

But yeah you're right, it's all a question of how much capability you want to surface, because the more you surface the more quickly it gets complex and inscrutable to anyone not in the know.

I made a script that converts all the videos in a directory above a certain bitrate to H.265 to save space and found that just using the flags `-map 0` to grab every stream, and `-c:s copy` was enough to avoid having to probe the source for every stream since subtitles were the most problematic if any streams were bitmaps. It then checks if there were any errors before replacing the original video. I still get the occasional outlier that I either fix by hand or just leave as is.

Also the script was written with python and argparse, so it would be relatively easy for me to create a GUI with Gooey[1] if there was interest.

[1] https://github.com/chriskiehl/Gooey

https://github.com/kkroening/ffmpeg-python

Once I have identified a target CRF then I just apply that value to all similar files. I'm personally not concerned about exact size, I'm not squeezing them onto discs or anything, so having one file be 690mb and the next one be 695 mb is fine.

Contrary to the name, and contrary to popular belief: yes, placebo does still improve quality noticeably even over veryslow, when you are squeezing bitrate very hard. Actually typically you will get a noticeably smaller file than medium/slow (10% reduction is not atypical) and the quality will be better than veryslow. This applies less when you are giving adequate levels of bandwidth but when you are really squeezing the bitrate to the absolute limit (I've been known to use values in the CRF 31-37 range at some times to really go hard), going deeper into motion search yields more benefits. Like, you probably could still benefit from going even farther (placebo is just a preset tuning some motion-search parameters and you could tune them even higher).

At a minimum, veryslow does produce very significant quality gains over medium even if you don't want to go all the way to placebo though. Worth it for archival for sure.

And typically, the situation where I'm hand-tuning a file to hit an exact file limit... are ones where I'm seriously pushing the limits in terms of what I can fit into a given attachment-uploader file size limit or something. So when I am targeting a fixed file size I am almost always squeezing hard.

There's no perfect solution to avoid the trial-and-error process though, imo. Automated solutions can produce something reasonable but not optimal in terms of exactly hitting your filesize limit at the maximum possible quality. Tuning it down to the last MB, or deciding to resize a video to give a bit more motion bandwidth, isn't something that they can generally do.

Personally I don't worry about audio too much - 160kbps AAC or MP3 is fine and anything too far below that starts to get potentially noticeably poor. If something has DTS or AC3 yeah, I'm transcoding because nothing will play that on the internet, but if it's reasonably close I'll just copy source to avoid generational losses fromt anscoding. Yeah, sometimes a reduction in resolution can produce big gains with little noticeable quality gain... and sometimes (especially with anime/cartoons) a high-res file has so little high-frequency data that going big barely affects file size at all. Tune mode can also help a little bit at the edges.

I never mess with framerate or bit depth/color space unless I absolutely have to, though. Too many pitfalls there.

Not associated, just find it easier to link to something useful.

If ya can maybe help em out and send a pull request? I think it's a neat little app and will take a look at it myself.

A trivial example is to try to convert the subtitles rather than defaulting to no subtitles (Handbrake). Another trivial improvement would be warning that the subtitles can’t be brought over to the container format before the 20 hour transcode rather than letting users find out after that their subtitles weren’t converted.

This isn’t rocket science.

This is what gets me every time. I'm relatively proficient with ffmpeg (relatively!) but for the life of me I can never remember how to switch audio sub streams or drop some of them, etc.

And yes, one first needs to find out what's where, but there are many UI tools that can do this (in addition to ffprobe).

What's the joke? I thought using VFW in 2022 was pretty hillarious of a suggestion. Maybe you got the punchline confused? ;P

AVISynth died to me long long ago as it was just no longer pratical. The work arounds to get 10bit video was never stable by the time I dropped it.

I did enjoy the scripting aspect of things like you suggest, but that's meh at this point. Now that my brain has been rewired to think FFMPEG like, the frustration goes away. It's a steep hill to climb without question, but eventually, it just goes "click".

2. The closest equivalent to VFW in linux is not ffmpeg but gstreamer. My experience with the latter is ... not good.

3. ffmpeg is great when it does what you need but VFW lets you draw from a vast ocean of third party plugins that do all sorts of niche things.

1)yes, if you're not needing 10bit, then AVISynth is fun and does some amazing things. Even it's features of doing technical restoration were useful, but once you step into professional, the 8bit only really holds things back and it was time to move on. FYI, a lot of the AVISynth filters are now available in FFMPEG!

2)gstreamer compared to ffmpeg to me personally is like comparing GIMP to Photoshop (dropping commercial vs FOSS). Yes, GIMP can do nice things, but Photoshop does what I need and I know how to make it do it. No questions asked. Muscle memory. I'm at that point with FFMPEG.

3)I'm long past trying to do creative things CLI that those 3rd party plugins allowed. I'm utilitarian with workflows and need to churn it out, so ffmpeg plugs in the holes as if it were designed for it ;-) If I'm going creative, I'm in a nice UI and doing things. However, I'm not afraid to use CLI to generate some content to messing with later in a more interactive environment.