Why am I ditching MeGUI*?
While MeGUI does do x265, it's not the GPU-accelerated kind, so good quality (i.e. "Slowest" speed and 2000 kbps) on a 24-minute video takes literally about a day. As in 24 hours. Zero complaints on quality, but it's just impractical! And I have other videos to encode that are longer than that. No thank you. NVENC would only take 15 minutes to encode a 24-minute video.
HandBrake does do GPU-accelerated encoding with H.265 NVENC, but it doesn't load AviSynth scripts directly. There's lots of outdated info out there, but I figured it out. Some links:
- The latest AviSynth+. The installer seems to install both 32-bit and 64-bit, and you have the option to install one or the other or both. Choose both anyway; it won't hurt. I ran into "cannot load 32-bit dll in 64-bit AviSynth" errors in my search for a solution but if you're on Windows 11, you're only really using 64-bit. You won't run into any problems with VirtualDub either if you use VirtualDub2 and stick with VirtualDub64.exe in the archive.
- AV FileSystem, aka AVFS. Apparently there are plenty of programs called "AVFS" and many sites refer you to the older version of the program which is no longer updated and will not solve the problem. Requires:
- Python 3.9.x
- VapourSynth Portable zip and drag AVFS.exe out of there.
- No need for some rando Pismo utility that VideoHelp points you to... but their procedure is otherwise correct.
My entire D drive is raw captures and templates. so I put AVFS.exe there. To get started, I open Command Prompt. From here, I type in D: to change directories (learn more here), then avfs "template.avs" and hit Enter. The virtual avi is created almost instantly in C:\Volumes. Windows Explorer says the 24-minute virtual AVI is 336 GB, but it doesn't take up any space. And HandBrake will load it up no problem!
Still, the consensus is GPU encoding isn't as good as CPU encoding, even if the speed is amazing. But my counter to that is, remember what we had to do with the old x264 standard: 2-pass Very Slow encoding and 12000 kbps would be damn near lossless, but would also take forever to encode and they would be huge! So if I have to bump up the bit rate a bit, well then, okay. We're still already at over 50% savings in file reduction anyway. This other guy on reddit, has more faith in the quality of NVENC, and you know what? I'll take his side.
I started encoding just animation at 2500 kbps and it looked good; it's already a higher bit rate than those old One Piece rips with multiple languages, which I consider the gold standard. But then my live action captures looked good too at this setting so I guess I'm staying at 2500 kbps, with Encoder Preset at Slowest and rc-lookahead=32. I think 3000 kbps was the lowest I would go for x264 captures at 720p, so doing 2500 kbps for 1080p is a great savings.
Also learned a neat term from all of this: JND (just-noticeable difference).
Those One Piece settings, by the way, are:
Format version : Version 4
File size : 235 MiB
Duration : 23 min 50 s
Overall bit rate : 1 380 kb/s
Frame rate : 23.976 FPS
Encoded date : 2019-03-06 23:55:59 UTC
Writing application : mkvmerge v9.2.0 ('Photograph') 64bit
Writing library : libebml v1.3.3 + libmatroska v1.4.4
Attachments : OpenSans-Semibold.ttf
Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main@L5.1@Main
Codec ID : V_MPEGH/ISO/HEVC
Duration : 23 min 50 s
Bit rate : 1 278 kb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Bits/(Pixel*Frame) : 0.026
Stream size : 218 MiB (93%)
Default : Yes
Forced : No
Audio
ID : 2
Format : AAC LC
Format/Info : Advanced Audio Codec Low Complexity
Codec ID : A_AAC-2
Duration : 23 min 50 s
Bit rate : 96.0 kb/s
Channel(s) : 2 channels
Channel layout : L R
Sampling rate : 44.1 kHz
Frame rate : 43.066 FPS (1024 SPF)
Compression mode : Lossy
Delay relative to video : 22 ms
Stream size : 16.7 MiB (7%)
Language : Japanese
Default : Yes
Forced : No
Text #1
ID : 3
Format : ASS
Codec ID : S_TEXT/ASS
Codec ID/Info : Advanced Sub Station Alpha
Duration : 23 min 31 s
Bit rate : 103 b/s
Frame rate : 0.209 FPS
Count of elements : 295
Compression mode : Lossless
Stream size : 17.9 KiB (0%)
Title : English
Language : English
Default : Yes
Forced : No
Menu
00:00:10.500 : en:Opening Theme
00:02:40.660 : en:Recap
00:03:11.942 : en:Part A
00:16:17.186 : en:Part B
00:23:15.687 : en:Next Episode Preview
*I'm not completely ditching MeGUI because HandBrake crashes when I try to include chapter data. HandBrake has its own method, completely incompatible with the way I've done it for nearly two decades, which is a text file that MeGUI can accept even before encoding:
CHAPTER01NAME=1 - Cold Open
CHAPTER02=00:01:16.977
CHAPTER02NAME=2 - Title Sequence
CHAPTER03=00:02:47.017
CHAPTER03NAME=3 - Sponsors A
CHAPTER04=00:02:59.429
CHAPTER04NAME=4 - Act 1
CHAPTER05=00:09:29.969
CHAPTER05NAME=5 - Eyecatch A
CHAPTER06=00:09:37.994
CHAPTER06NAME=6 - Eyecatch B
CHAPTER07=00:09:43.900
CHAPTER07NAME=7 - Act 2
CHAPTER08=00:21:27.153
CHAPTER08NAME=8 - Credits
CHAPTER09=00:22:58.377
CHAPTER09NAME=9 - Post-Credits
CHAPTER10=00:23:59.438
CHAPTER10NAME=10 - Preview
CHAPTER11=00:24:14.436
CHAPTER11NAME=11 - Sponsors B
So after I let HandBrake encode, I run it through MeGUI again (One-Click > Advanced Config > Don't encode video) and it'll only take seconds for a lossless copy to be created, this time with chapter selection.
EDIT: Seems you can get away with lower bit rates if you have lower frame rates, according to AI-generated answers searching "does lower frame rate mean lower bit rate" in DuckDuckGo. I thought I heard almost the exact opposite a decade ago, but looking at those One Piece rips, the significant reduction in file size can't all be from CPU encoding, especially when there are so many audio tracks.