Handbrake advice?

skykiii

kiwifarms.net
Joined
Jun 17, 2018
So usually I just backup DVDs and blurays as ISOs, but a thing forced my hand. Often when I'm on Discord trying to have a watch party, if I screenshare a thing playing a bluray, my friends report that the video "stutters." This seems to only happen with blurays, and even then not all of them (for some reason Astro Boy 1980 was fine, I suspect because that show isn't at true HD). So for several shows I've either had to A) use a DVD source instead or B) find a version on a streaming service (sometimes even a legal one that I'm sure is using the same masters as the bluray, such as Granada's Sherlock Holmes which is on Tubi).

So I've been meaning to test if handbraking a show to an MKV file, and possibly lowering it to 720p, would at all help this issue.

But right away there's so many things I don't know. And a lot of the guides I find seem to assume you're doing a modern Hollywood movie whereas of course I'm doing stuff from the 1980s (in this case, cartoons by Hanna-Barbera or Filmation). And yes, in at least one case I did check a torrent site to see if someone else had done the labor for me, and found nothing.

But basically what I'm looking for is a balance between quality, file size (I would prefer 30-minute episodes not be more than 500mb, and even that feels excessive) and time spent.

About that last point: I had heard choosing "slow encodes" lowers the file size, but in my case it did not--in fact the file wound up larger--and I'm wondering if I fucked it because I chose "constant framerate" paired with "same as source" and if opting to use 24-bit FLAC for the audio tracks (which I've heard is lossless) was the issue?

Which kinda defines the problem: I don't know how much of these settings will make an appreciable difference vs how much is just costing me disc space for no good reason and may be counter-productive since the end result is meant for discord watch parties anyway and its not like you can fullscreen those.

and before I get someone saying "read the effing manual" knowing what something supposedly does is not the same as knowing if its worthwhile. Most programs have things that sound like they matter but they really don't, so I find user experiences more helpful.

TL;DR
share your experiences with a noob please. And yes I am open to alternatives to Handbrake if you think that would help.
 
I have heard doing AV1 encoding with CPU (software) rather than using accelerated options like NVENC will produce smaller file sizes, at the cost of time of course.

To be clear, the source is DVD/Bluray? I did a project digitizing some VHS tapes and had to work on removing interlacing and taking into account sharpening for the shit quality, and found Handbrake to be very good once I finally dialed everything in. I've forgotten everything I set up though.
 
To be clear, the source is DVD/Bluray?
Yes, source is bluray specifically in this case.

To reaffirm, the problem is that for some reason watching blurays on a Discord screenshare introduces stutters to my friends. DVDs don't have this problem and I'm looking into using handbrake to see if making a digital file and just watching that would solve the issue.
 
ALWAYS ALWAYS ALWAYS USE FRAMERATE SAME AS SOURCE, REGARDLESS OF WHETHER OR NOT THE SOURCE IS CONSTANT OR VARIABLE. TO MESS WITH THESE SETTINGS IS TO INVITE THE DEVIL INTO YOUR HOME.

Okay, so there are way, way too many knobs in encoders to tell you what you "need", because it all depends on your tolerance for compression artifacts and encoding time. HandBrake includes SVT-AV1, which, pound for pound, encodes faster and at higher quality w/ lower bitrates than HEVC/x265. You don't need lossless audio either. Transcode it to opus. You will NOT hear the difference.

HandBrake should expose hardware encoding options, if you have any. This could be good or bad depending on what hardware you have. I would never use hardware encoding for archival purposes, but if it's for watch parties, it's perfectly fine. The encode time is an order of magnitude faster than software, but the quality for the bitrate is lower.

If all you changed in your "slow" experiment was the preset, then that explains why it's bigger. Presumably this was x265, since you said "slow", rather than a number, which means you need to raise the CRF setting to actually get a smaller file size. If it's the same CRF, the file gets bigger. It's better, too, but it's also bigger. Raise CRF to get better with smaller file size. It's not magic though.

You should post the specs of the machine you're using to encode.
 
Get an external optical drive an SSD then download Make MKV and VLC player. Burn your DVD's and Blurays using Make MkV and copy them over to the SSD. Just play them from there. It's what I did. Works great. My T480 Thinkpad is my new portable movie player.

No, you don't need Make MKV to have the MKV files play in VLC.
 
Considering you're one-off streaming Blurays to your friend group, isn't re-encoding things a bit overkill? If it's a framerate mismatch between what Discord's screenshare tool is expecting and what you're playing, you could try putting something like OBS in between them to smooth things out.
 
24-bit FLAC lossless is completely irrelevant because if your sources are largely old cartoons, the sound never approached the level of quality that any decent AAC could contain. It's akin to building a rig able to withstand 400 ton weights for a barbell rack used solely by Eugenia Cooney. Anything above 16bit and 48000hz is a meme for end users - sound engineers who are recording very particular sound effects they might fuck around with in post on specialized microphones are the only people who MIGHT need more than 48000 (usually not though) and the range of 24/32 bit.

Most people are incapable of telling the fanciest audio file in the world apart from 320kbps mp3 in blind tests on the same hardware. Encode to AAC 320kbps (unless your source was meh to begin with, you can go down to 128 and usually no one can tell), you'll be fine. H265 for smaller file sizes if your PC can handle decoding and streaming them.

Here's a basic x265 1080p 320AAC preset (download, save as .json and import in handbrake's preset menu) try it. I tried it on a 3gb high quality file of the tv show "shogun" which I compressed down to about 1gb with this while retaining 5.1 sound - I put up frames from the old, three times bigger file and the new encode on a color calibrated high quality monitor and I could tell fuckall apart. I tried it on a cartoon with Stereo320 and the file turned out to be 250mb per half hour and again, I could not tell the original apart from the encoded one. On my mid-tier machine it takes about the same time to encode as to watch (fx. 20 minutes of encoding for a 20 minute show).

I suggest you push this preset around a bit, pushing Quality to 30 RF and Encoder Preset to faster to see if it makes an appreciable difference for you in both time spent and output quality. Also check subtitle settings if you use them.

Side note: Granada's Sherlock Holmes is fucking amazing, good taste OP.
 
Last edited:
Handbrake has quality presets and you can further tune them to certain kinds of video, one of them being animation. If you are concerned about file size you can determine almost the exact size of the output by setting an average bitrate for the video track. 2000-2500 should be okay for old cartoons. If you have a modern 6 or 8+ core processor, x265 encoder at medium preset offers a good ratio of encode time to quality. If not, x264 is fine. Make sure you're cropping out any black bars (use the preview button) because they will increase file size for no benefit.
 
  • Like
Reactions: NoReturn
Re-Encoding a video on veryslow/placebo is NOT worth it!
 
  • Like
Reactions: Vecr
Does not work, I'm on the latest version 1.9.0 and it seems to be incompatible with it due to being made on an older version.
Thank you for bringing it to my attention, I've updated to the current version and the link now leads to a current version of the preset. Looking at the default presets that current-year Handbrake comes with, I find mine is near identical to their Matroska1080H265 except that I let the source file determine framerate. Note that discord might do better with MP4 + Web Optimized than MKV. I do not know, but worth investigating. Results are identical for me on this version (260mb for 30 minutes 1080p aac320)
 
Last edited:
  • Informative
Reactions: Vecr
Considering you're one-off streaming Blurays to your friend group, isn't re-encoding things a bit overkill? If it's a framerate mismatch between what Discord's screenshare tool is expecting and what you're playing, you could try putting something like OBS in between them to smooth things out.
Honestly this question has been bugging me too--it would suck if I do all this work only to find it doesn't help a damn thing. One of my friends says he always sees stuttering no matter what, another reported he only saw it when I used a bluray but it went away (or else became a lesser issue--I forget what he actually said) when I used Tubi. And same deal as with handbrake settings, I'm not sure if the various Discord screenshare options make a difference--like if screensharing a web browser or my desktop is better than screensharing a VLC or MPC instance.

I'm half-tempted to try out Discord Nitro to see if that fixes anything.

@Jeff Q. Anime I'm using the same machine I described in this post, though I have a laptop that might be slightly stronger, I just have nowhere to hook it up (cramped space).

And yes, money permitting I would get a better machine. This one seems surprisingly capable though.
 
I'm using the same machine I described in this post
SHEESH

That being said, you should be able to HW decode bluray rips either from the iGPU or the NVIDIA GPU. If only some of your friends are reporting stuttering, I'd suspect the rest of them are experiencing it too, but just don't notice it or care.

If you're doing screen sharing, the source material shouldn't really make a difference... Even with your bonkers sad CPU. HW decode MPC and VLC are basically free, for CPU load. Maybe HW decode capabilities aren't getting detected by your player automatically? But I find that hard to believe. I don't know if discord streaming natively uses hardware acceleration.

How is your eGPU connected? It's possible that there's a bandwidth bottleneck being created if, incidentally, the eGPU is being used to decode the video and encode a stream...? Maybe? I doubt it, though... Is your monitor connected directly to the eGPU?

Have you monitored system resources while doing such a stream to see if the CPU is getting pegged, or if the HW encoders/decoders are doing any work? You can do so in task manager.

1739153621549.png
 
How is your eGPU connected?
Thunderbolt cable.

Is your monitor connected directly to the eGPU?
Yes.

Have you monitored system resources while doing such a stream to see if the CPU is getting pegged, or if the HW encoders/decoders are doing any work?
How do I do this?

EDIT: A friend elsewhere suggested I monitor Task Manager while streaming something on Discord. I did that with a Granada Holmes bluray. The only thing that ever seemed to get stressed was "power usage" sometimes went to "high." Everything else stayed in moderate to low range.

It's starting to feel like this may not necessarily be a source material problem, more like possibly a Discord problem.
 
Last edited:
Thunderbolt cable.


Yes.


How do I do this?

EDIT: A friend elsewhere suggested I monitor Task Manager while streaming something on Discord. I did that with a Granada Holmes bluray. The only thing that ever seemed to get stressed was "power usage" sometimes went to "high." Everything else stayed in moderate to low range.

It's starting to feel like this may not necessarily be a source material problem, more like possibly a Discord problem.
You need to go to the performance tab, not look at the main processes tab.

Alternatively, (and possibly recommended-ly) download hwinfo64: https://www.hwinfo.com/download/

This will (hopefully) give additional information, like the bus load (which would let us know if that's an issue) among other things. For example, if the video is being decoded on the iGPU and encoded on the eGPU, or vice versa, that might saturate the bus. Or, if it's encoding your stream on the nvidia gpu without zero-copy, that might also clog up the pipes. Lots of options available.

1739156500910.png
 
Okay, I tried subscribing to Discord Nitro but that didn't fix the issue. Then I didn't have time to test other solutions since my friends were all busy.

I'll look into the thing @Jeff Q. Anime suggested next.
 
Back