My advice would be to try transcoding one or two media files first, and test the transcode on different devices. HISTV gives a lot fewer options than Handbrake, but the idea is minimal effort, maximal compatibility.

Specifically, AV1 is a newer standard, and not supported on devices older than ~2020 I think. HEVC (aka x265) produces slightly larger files but works on devices back to 2016 or so, and MP4/H.264 gives yet bigger files but compatibility goes back even further.

For video file size the main things you want to set are the target bitrate and, secondarily, the QP numbers: https://www.w3tutorials.net/blog/what-s-the-difference-with-crf-and-qp-in-ffmpeg/#quantization-parameter-qp-definition--how-it-works

For good quality at a reasonable size you can use the default values of 20/22 but to save a little more space you can probably bump these to 24/26. I went with QP instead of CRF because it’s better for streaming (while still giving better perceived quality than a constant bit rate).

As I say, Handbrake is great, does all this and more, but that was my problem with it - the controls look like something out of a space shuttle and I just don’t need all that most of the time 😅 I’d love to hear how you find using HISTV vs Handbrake, if you give it a go! 🙌

Yeah, I’m getting that; though this isn’t purely AI-generated. This is a working application that I’ve tested, have improved and plan on continuing to improve, and am currently using to transcode my media. There’s a lot more care and thought put into it than most people would expect on reading that it was created with the help of an AI model.

I put the disclaimer because I respect that serious developers who actually go look at the code would like a heads-up that it’s genAI before they waste their time reading it. But, I would like people to at least have a chance to read why I think my approach is different than most.

And, if you have videos to transcode, I’d love to hear what you think if you give it a go! I do actively fix bugs as well as add new features, so please do let me know if you try it and find an issue - I could use all the help testing it I can get 'cause my hardware to test on is quite limited.

I was hoping to catch this before your replied, as I went and read the readme, then it made more sense. So I deleted my reply. But too late!

All good! I’m actually enjoying talking about this thing with people who want to know more so I don’t mind at all ^_

The cool thing is there isn’t much to put into a command that does stuff like this, unless you changing the FFMPEG parameters every time, but that would seem unlikely.

So actually, that’s exactly the issue I was running into! I’d run a batch command on a whole folder full of videos, but a handful would already be well-encoded or at least they’d have a much MUCH lower bitrate, so I’d end up with mostly well-compressed files and a handful that looked like they went through a woodchipper. I wanted everything to be in the same codecs, in the same containers, at roughly the same quality (and playable on devices from around 2016 and newer) when it came out the other end, so I implemented a three-way decision based around the target bitrate you set and every file gets evaluated independently for which approach to use:

1. Above target → VBR re-encode: If a file’s source bitrate is higher than the target (e.g. source is 8 Mbps and target is 4 Mbps), the video is re-encoded using variable bitrate mode aimed at the target, with a peak cap set to 150% of the target. This is the only case where the file actually gets compressed.

2. At or below target, same codec → stream copy: If the file is already at or below the target bitrate and it’s already in the target codec (e.g. it’s HEVC and you’re encoding to HEVC), the video stream is copied bit-for-bit with -c:v copy. No re-encoding happens at all - the video passes through untouched. This is what prevents overcompression of files that are already well-compressed.

3. At or below target, different codec → quality-mode transcode: If the file is at or below the target but in a different codec (e.g. it’s H.264 and you’re encoding to HEVC), it can’t be copied because the codec needs to change. In this case it’s transcoded using either CQP (constant quantisation parameter) or CRF (constant rate factor) rather than VBR - so the encoder targets a quality level rather than a bitrate. This avoids the situation where VBR would try to force a 2 Mbps file “down” to a 4 Mbps target and potentially bloat it, or where the encoder wastes bits trying to hit a target that’s higher than what the content needs.

There’s also a post-encode size check as a safety net: if the output file ends up larger than the source (which can happen when a quality-mode transcode expands a very efficiently compressed source), HISTV deletes the output, remuxes the original source into the target container instead, and logs a warning. So even in the worst case, you never end up with a file bigger than what you started with which is much harder to claim with a raw CLI input. The audio side has a similar approach; each audio stream is independently compared against the audio cap, and streams already below the cap in the target codec are copied rather than re-encoded.

But yeah everything beyond that was bells and whistles to make it easier for people who aren’t me to use it haha.

I am 100% looking for more stuff I can build - let’s talk about it!