This is the real reason I do so much DIY. I don’t save a lot of money, at least on the initial outlay, but I learn.

Ah, I’ll put in a zoom feature, that’s a good idea!

Remind me of the hardware you’re running on? 22 hours for a 4k HDR movie sounds about in the ballpark for converting on CPU. I’ve just switched to Linux (Mint, not Cachy) and I think there’s an issue with detecting GPU on Linux, so this’d track (or you have Precision Mode enabled) - if you see “libx265” or “libx264” in the top right, you’re on CPU. I’m looking into this one.

Can I ask which version you downloaded? I’ll look into the DVTools/MP4box issue.

Also, yes, I removed the codec and container selection boxes - it’s HEVC/MKV by default unless you go for “Compatibility Mode” in which case you get H.264/MP4. “Preserve AV1” of course preserves AV1 which is incompatible with MP4 so they’re mutually exclusive.

So… How’s it working? 😅 (Just realised it’s been a while since I’ve touched HISTV and this came to mind, I’ve been working on my business and day job)

LLMs will never be people

Boy oh boy, you’re not gonna like this one bit: https://www.npr.org/2014/07/28/335288388/when-did-companies-become-people-excavating-the-legal-evolution

(To be clear, I understand you think you covered this with “computers may be” but my point is different: the law is often dumb and you would be amazed at what politicians who don’t understand tech - or get paid not to understand it - will pull off)

Edit: Downvotes from people who missed the point. You can’t say “LLMs will never be people” because you simply can’t guarantee your/our lawmakers won’t be that stupid.

I watched Quantum Leap with my dad when I was a kid. You’re gonna try and tell me I’m not writing this reply on Ziggy?

Ah, what version did you try? This is due to issues with the renderer, but I just got this fixed by disabling GPU drawing for the form last night. Give 2.5.9 a go 😊

You know what? I think I can figure out a way to estimate final file size and display it to the user. It’ll only work if “Precision Mode” is off though - that uses “CRF” or “Constant Rate Factor” which basically tells the encoder “be efficient, but make the file as big as it needs to be to look good”. As a result there’s no way to tell how big the file will end up being - the encoder makes the decision on the fly.

With “Precision Mode” off, HISTV has two gears:

1. If your file is already small enough (at or below the target bitrate), it uses “CQP” or “Constant Quantisation Parameter” (the QP I/P numbers), which tells the encoder “Use this quality level for every frame, I don’t care how big the file ends up”. It’s fast and consistent - every frame gets the same treatment.
2. If your file is too big, it switches to VBR (Variable Bit Rate), which tells the encoder “Stay around this target bitrate, spike up to the peak ceiling on complex scenes, but don’t go over”. It’s how the app actually shrinks files. You can estimate the output size with target mbps * seconds / 8 - so a 60-second clip at 4Mbps lands around 30MB. <- This is the maths I’m thinking about doing to display the estimate to the user.

Hey bud, this is a neat project! I ran your codebase through my own Claude Opus 4.6 instance with extended thinking on, against a “code quality” skill I worked up with the bot the other day. The skill prioritises security, code efficiency, and enforcing end-user usability over taking shortcuts. It found a lot more than the 8 security issues I opened, but I didn’t wanna flood your issues section until I’m sure you’re happy for me to contribute like this.

Anyway, cheers, and good luck!