Well, sure, and I appreciate your sanguinity haha! I just main support, and felt your question deserves a proper answer.
I am planning on answering when I’m at a computer, as well, because I actually do have a matrix server set up with Synapse and MAS. Quick question though, when you ask how it works, do you mean the actual backend, or are you asking if the performance/user experience is good?
Don’t get me wrong, suggestions are appreciated, but you’re answer is absolutely typical of a Stack overflow “huhuh well don’t do it wrong then” comment. You could have, for example, said you don’t use Synapse but this is why you like Continuwuity. (edit: not prescribing speech, giving an example of how your comment could have read better)
As well, I take issue with the idea that people can only ask for help in sanctioned forums. This is a self-hosting community, after all; I am here not only to learn but to share what I learn, which I thought was the whole point.
What is this, StackOverflow? You didn’t answer their question and instead just told them to use a different solution.
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)
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 😊
Hey, I haven’t made a full post about this yet, but I thought you’d like to know: v2.5.0 is out, and it implements quietvoid’s tools for DoVi support! https://github.com/obelisk-complex/histv-universal/releases
It’ll even handle DV 5 and 7 😊
You totally can though. It’s a common phrase.
Whether it’s an alternative depends on what you use Handbrake for. HISTV can’t convert ISO or rip discs, it only converts video files. If you just use Handbrake to get smaller videos, HISTV will work for you without having to use more controls than it would take to launch the space shuttle 😅
Haha thanks! You mean, support them for output, as well as being able to convert from? Last night I outlined adding an “Auto” option for container, which would keep the source container if possible, but the controls I’ve exposed vs the ones I haven’t are a conscious choice, to maximise player compatibility for the outputs without the user having to know anything about codecs, containers, encoders, their hardware, or quality settings. I’m deliberately keeping the options to a minimum because I didn’t want to make Handbrake 😅
As to why I chose these codecs: h264 works on devices from 15+ years ago, and HEVC is compatible back to 2015-16. AV1 is 2020 onwards and requires GPU decoding; that’s too new and resource-intensive for my goals with HISTV.
I’ll think about how I could pull this off though. Perhaps a “lite” mode that keeps the original codec and container, or an “auto” mode for codec dropdown too. I think I like the second one better: lets you mix and match keeping container or codec or both, without adding any real complexity to the options.
Hahaha baby steps! But I’ll look at it; if nothing else I think it would be very funny to have the dev equivalent of Jar Jar Binks end the format war by accident (which I say as just a joke; I of course have no idea how complex the issue actually is).
Edit: Damn dude, you weren’t kidding about the challenge. You’re right that HISTV won’t work for DoVi 5 in its current state - “Fundamental to FFMPEG” does kinda mean “fundamental to HISTV”, being that it’s basically just a clever wrapper around FFMPEG. That said, if your tooling is ready, I’ve got a plan to integrate it. The philosophy with HISTV is to preserve whatever we can and fall back gracefully as far as we have to if we can’t preserve the current profile, which your tools slot into like they were made for it (Rust Gang represent (👉ﾟヮﾟ)👉).
Ah, then the real slowness is going to come from having them on a spinning disk HDD. For friends, 3Mbps or 4Mbps target bitrate should be plenty, with the 2x multiplier should be enough to preserve detail. No need to touch anything else, you don’t need precision mode for it. Maybe start with 3 and that on just one episode, and see how you go - if you find yourself noticing it looks blocky, bump up to 4Mbps and you’ll be golden.
Fun fact - HISTV actually has two-pass encoding! Though, with enough system RAM you can actually look ahead far enough that you can get the benefits of two-pass in just a single pass. I have a bit about this in the README.md:
Precision mode
One checkbox for the best quality the app can produce. It picks the smartest encoding strategy based on how much RAM your system has:
Your RAM What it does 16GB or more Looks 250 frames ahead to plan bitrate (single pass) 8-16GB Looks 120 frames ahead to plan bitrate (single pass) Under 8GB Scans the whole file first, then encodes (two passes)
Two-pass only happens when precision mode is on AND the system has less than 8GB RAM AND the file would be CRF-encoded. Reason being those lookaheads above. Lookahead buffers live in memory. On low-RAM systems that buffer would be too large, so the app falls back to two-pass instead and stores the analysis run in a tempfile on disk. To break down each one:
The biggest problem with two-pass encoding is the speed. It has to do two passes over the whole file: one analysis, one actually encoding. With a 250-frame lookahead, you’re basically just writing your passlog into RAM - and reading from it - as you go. With 120-frame lookahead your CPU will likely catch up to the passlog at times, but you can still write to and read from it as you go, so you still get similar speed, and still close enough in quality that it doesn’t really make a difference, in a single pass.
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:
There are now!
Sweet as mate, cheers for the kind words! I hope it’s useful - and if you run into any issues, or think of a feature you’d like to see, please do let me know. Bugs get fixed ASAP, and I always promise I’ll at least consider new features because I’m having a lot of fun working on this thing! 😁
Haha yes, I use it regularly! And yes, it’ll be plenty fast on your system. I have very deliberately gone over the code base looking for inefficiencies six times now, so it runs nice and lean - I do an efficiency/hygiene pass every couple of releases to make sure bloat doesn’t creep in.
As ark3@lemmy.dbzer0.com said, CPU encoding is slow but it preserves the most quality. No kidding, it really is night and day compared to GPU encoding - for this, just tick “Precision mode” in HISTV. It’s about 1x speed on most videos, so a 45 minute file will take about 45 minutes.
GPU does go a lot faster, my 7900 XTX rips through 1080p at about 28x speed so a 45 minute file takes about 2 minutes. This is good enough for most content; just untick “precision mode” and set the multiplier to 2x or 3x with a bitrate of 4 if you want better GPU quality in HISTV. The multiplier says how high the peak bitrate can go, so you keep more data for fast-moving scenes, without forcing the encoder to keep useless data for slow scenes.
This is super helpful (and I see that “btw”, you got a smile with that one (☞ﾟヮﾟ)☞). Thank you for the heads up and ask this detailed information! I’m excited to check out Certum.
there seem to be very few people who simultaneously - pathologically dislike using Windows regularly - still want to make it easier for people on Windows to minimize Windows Defender complaints when running software that they build
Describes me to a T 😅 My career is rooted in support, so my pathologies include trying to make things end-user easy.
Thank you! I am obnoxiously proud of myself for that one 😅
That’s actually how this all started for me haha! I was sitting there tweaking the same command as I hit videos with different formats or quality levels, and I thought to myself that it’d be a lot easier with just a few smarts like detecting if a video is already at the target quality level. The first version was actually just a winforms GUI wrapping that very PowerShell command - it’s come a long way in just a few weeks.
Subler is interesting! Hmm. Currently HISTV just copies over ask the subtitle tracks directly. I think I could add a subtitle function like Subler’s to bake in subtitle tracks, if the user has the subtitle file they want to use. Would that be useful? Metadata download from the internet is messy though, I might want to leave that to the existing *arr solutions.
I am not patronising and that was not my intent. Read whatever you want into it of course, I can’t stop you.