It’s no worries mate, as mentioned I have no problem with questions!
So, reasons. Yes, this started as a line in powershell! That was my other post, linked at the top. I wrote the line, and after a few batches I decided to stop and use Claude to build a GUI for it. After I got that working and did a few runs with it, I started thinking about how useful this would be for a handful of other people in my life, and I wanted to package it into a .exe, partly so I could send them something simple to start but also just because I wondered if I could get it working. Never done it before. I still wanted to use it for myself because I have thousands of video files to transcode, and I didn’t want to have to manually tweak the command for every batch. I also didn’t want to have to rebuild it if I have more to do 6 months down the line - I’m lazy.
Then, later that night after I’d done a few batches with the powershell line-now-script, I thought to myself that Claude could probably help me build a frontend for it that didn’t rely on powershell, and then I started thinking about just making it a cross-platform application so my less techie friends can use it if they have big video files and want to save disk space. And then I got the bright idea to post it to the internet in case there are other less-techie users who aren’t my friends but who could still use it.
It’s got some smarts under the hood to detect any hardware encoders you have available, and will present only the encoders that your system can use; the options are INCREDIBLY constrained, because the idea isn’t to expose every option of FFMPEG - this is for quickly shrinking video files without even needing to know the difference between CBR and VBR. That’s because you and I think it’s easy to run an FFMPEG command from the commandline. But there are a lot of people of all different kinds of skill levels who have no idea how any of that works, and they’ll take one look at Handbrake and run screaming. This is for those people, too.
It also auto-downloads the latest FFMPEG and FFProbe from the official source if it doesn’t detect them on your PATH or in the folder with the executable - that saved my buddy who was helping me test it on his 2016 Mac, for example.
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!
I have thousands of video files to transcode, and I didn’t want to have to manually tweak the command for every batch. I also didn’t want to have to rebuild it if I have more to do 6 months down the line - I’m lazy.
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.
Yeah for sharing I get some of the bells and whistles.
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!
obelisk_complex@piefed.ca 1 month ago
It’s no worries mate, as mentioned I have no problem with questions!
So, reasons. Yes, this started as a line in powershell! That was my other post, linked at the top. I wrote the line, and after a few batches I decided to stop and use Claude to build a GUI for it. After I got that working and did a few runs with it, I started thinking about how useful this would be for a handful of other people in my life, and I wanted to package it into a .exe, partly so I could send them something simple to start but also just because I wondered if I could get it working. Never done it before. I still wanted to use it for myself because I have thousands of video files to transcode, and I didn’t want to have to manually tweak the command for every batch. I also didn’t want to have to rebuild it if I have more to do 6 months down the line - I’m lazy.
Then, later that night after I’d done a few batches with the powershell line-now-script, I thought to myself that Claude could probably help me build a frontend for it that didn’t rely on powershell, and then I started thinking about just making it a cross-platform application so my less techie friends can use it if they have big video files and want to save disk space. And then I got the bright idea to post it to the internet in case there are other less-techie users who aren’t my friends but who could still use it.
It’s got some smarts under the hood to detect any hardware encoders you have available, and will present only the encoders that your system can use; the options are INCREDIBLY constrained, because the idea isn’t to expose every option of FFMPEG - this is for quickly shrinking video files without even needing to know the difference between CBR and VBR. That’s because you and I think it’s easy to run an FFMPEG command from the commandline. But there are a lot of people of all different kinds of skill levels who have no idea how any of that works, and they’ll take one look at Handbrake and run screaming. This is for those people, too.
It also auto-downloads the latest FFMPEG and FFProbe from the official source if it doesn’t detect them on your PATH or in the folder with the executable - that saved my buddy who was helping me test it on his 2016 Mac, for example.
NewNewAugustEast@lemmy.zip 1 month ago
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!
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.
Yeah for sharing I get some of the bells and whistles.
obelisk_complex@piefed.ca 1 month ago
All good! I’m actually enjoying talking about this thing with people who want to know more so I don’t mind at all _
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!