Saturday, September 28th, 2019 05:31 am
handbrake, video and audio encoding, continued
Continuing from sad post about video confusion and Handbrake.
Note: as a QC Analyst/Program Tester, I would like to note this is the worst test planning I have ever done, mostly because a.) I didn't realize I was testing anything, b.) I didn't know what I was doing when I realized I was doing just that, and c.) everyone prioritizes speed and file size over everything to the point no one even bothered posting literal settings, much less actual results other than 'that took too long', which is part of teh reason why b was annoying me. I am seriously tempted--after this batch finishes processing--to start over with a set of custom presets as working constants, pick five 4K rips and three resolutions (4K, 1080p, 720p), queue them up, and spreadsheet my results (in about a month, which is even back to back my best guess on how long it would take to complete that queue) for H.264, H.265, and V9 respectively, just for my own curiosity. And now that I wrote that, there's a fair to good chance I'll do it; it's not like my server has anything else to do atm.
Continuing:
After many (many) hours of testing with Handbrake: V9 encoding of 4K rips has much better compression than H.264 with both same or better quality video and a smaller file size. However, it does take longer: about six to ten hours for a roughly two hour movie downgraded from a 4K rip to a 720p. Between Constant Quality 20, 19, and 18 there's almost no difference in file size, and I'm not sure I see any video difference either. H.265 is logarithmic when reducing the CQ number (which is inverse to quality: smaller number is better) but it's unclear if V9 is doing the same, which may be why CQ20, CQ19, and CQ18 are almost identical.
Or--very possible--there's a big change in video, but when one of your audio tracks is always lossless and is quite large in itself, it really won't matter much.
H.265 should be equal V9, which is the third in the queue. When that on is finished, I can finally do a clean comparison of the same movie encoded with the same number of audio tracks in H.264, H.265, and V9.
So after so much googling, I finally went about it categorically and tracked down the all the about audio pages, created a spreadsheet, made a list of all of their names and encoders and what they mean, matched them to my movies, and now feel I almost could understand this. Strangely, the best help came from looking up the specs on various high-end speakers as they list available audio in descending quality and all audio matching audio codecs and what kind of set up you needed (among their inventory) for surround, 5.1, 6.1, and 7.1 and very convincing reasons as to why. Thank God I still have a couple of days before payday or that could have ended badly.
What I also figured out is that part of my bafflement is that in general, when reading all the Handbrake tutorials, the assumption is you want a small file size encoded as quickly as possible at the best quality possible, pick all three, and most people have worked that out and the settings of each variable to make it happen; the final settings for one's video is basically the equation.
You'd think it'd be obvious--file size is the priority--but yeah, didn't even think about it. Which led to the following obvious realization.
Lossless (non-compressed) audio streams are huge; lossy 7.1 and 5.1 and 2.0's may be compressed but still pretty huge. So the fact no one really had any answers on if I need to create an AAC or Opus encoding for each audio stream for compatibility is because compatibility wasn't actually the reason for creating an AAC or Opus transcode; it's for file size. Selection of audio files was decided by a.) your home audio set up and/or b.) who/what the file is for and if you wanted 7.1 or 5.1 but a small file size, you encoded it with AAC 7.1 or Opus 7.1 to compress the size while keeping the range or just did a plain AAC 2.0 of one (or two) streams to mix everything to stereo. In other words, if I am selecting and passing through all audio anyway, I really really don't need a transcode of each one.
So that helped a lot.
On my end, however, I have no specific concrete goal. I've never bothered with file compression; I just rip my movies whole and increase the number and size of my hard drives as needed and I don't do video editing for the web. I only started making 720p versions when I started using Plex regularly enough for all my movie and vids to be on there, organized, and accessible remotely so I can watch anywhere; I wanted a smaller version for easier streaming to TVs that aren't 4K or even 1080p or for smaller screens like my phone, on all of which high resolution would be wasted anyway.
I want to know a.) all the variables, b.) the weight of each variable, and c.) the reason those variables were assigned that weight. And on a guess, to work that out, I'll probably have to do it myself the old fashioned way; custom presets for my test sets and doing a batch for each one.
So I feel a little less dumb now.
Note: as a QC Analyst/Program Tester, I would like to note this is the worst test planning I have ever done, mostly because a.) I didn't realize I was testing anything, b.) I didn't know what I was doing when I realized I was doing just that, and c.) everyone prioritizes speed and file size over everything to the point no one even bothered posting literal settings, much less actual results other than 'that took too long', which is part of teh reason why b was annoying me. I am seriously tempted--after this batch finishes processing--to start over with a set of custom presets as working constants, pick five 4K rips and three resolutions (4K, 1080p, 720p), queue them up, and spreadsheet my results (in about a month, which is even back to back my best guess on how long it would take to complete that queue) for H.264, H.265, and V9 respectively, just for my own curiosity. And now that I wrote that, there's a fair to good chance I'll do it; it's not like my server has anything else to do atm.
Continuing:
After many (many) hours of testing with Handbrake: V9 encoding of 4K rips has much better compression than H.264 with both same or better quality video and a smaller file size. However, it does take longer: about six to ten hours for a roughly two hour movie downgraded from a 4K rip to a 720p. Between Constant Quality 20, 19, and 18 there's almost no difference in file size, and I'm not sure I see any video difference either. H.265 is logarithmic when reducing the CQ number (which is inverse to quality: smaller number is better) but it's unclear if V9 is doing the same, which may be why CQ20, CQ19, and CQ18 are almost identical.
Or--very possible--there's a big change in video, but when one of your audio tracks is always lossless and is quite large in itself, it really won't matter much.
H.265 should be equal V9, which is the third in the queue. When that on is finished, I can finally do a clean comparison of the same movie encoded with the same number of audio tracks in H.264, H.265, and V9.
So after so much googling, I finally went about it categorically and tracked down the all the about audio pages, created a spreadsheet, made a list of all of their names and encoders and what they mean, matched them to my movies, and now feel I almost could understand this. Strangely, the best help came from looking up the specs on various high-end speakers as they list available audio in descending quality and all audio matching audio codecs and what kind of set up you needed (among their inventory) for surround, 5.1, 6.1, and 7.1 and very convincing reasons as to why. Thank God I still have a couple of days before payday or that could have ended badly.
What I also figured out is that part of my bafflement is that in general, when reading all the Handbrake tutorials, the assumption is you want a small file size encoded as quickly as possible at the best quality possible, pick all three, and most people have worked that out and the settings of each variable to make it happen; the final settings for one's video is basically the equation.
You'd think it'd be obvious--file size is the priority--but yeah, didn't even think about it. Which led to the following obvious realization.
Lossless (non-compressed) audio streams are huge; lossy 7.1 and 5.1 and 2.0's may be compressed but still pretty huge. So the fact no one really had any answers on if I need to create an AAC or Opus encoding for each audio stream for compatibility is because compatibility wasn't actually the reason for creating an AAC or Opus transcode; it's for file size. Selection of audio files was decided by a.) your home audio set up and/or b.) who/what the file is for and if you wanted 7.1 or 5.1 but a small file size, you encoded it with AAC 7.1 or Opus 7.1 to compress the size while keeping the range or just did a plain AAC 2.0 of one (or two) streams to mix everything to stereo. In other words, if I am selecting and passing through all audio anyway, I really really don't need a transcode of each one.
So that helped a lot.
On my end, however, I have no specific concrete goal. I've never bothered with file compression; I just rip my movies whole and increase the number and size of my hard drives as needed and I don't do video editing for the web. I only started making 720p versions when I started using Plex regularly enough for all my movie and vids to be on there, organized, and accessible remotely so I can watch anywhere; I wanted a smaller version for easier streaming to TVs that aren't 4K or even 1080p or for smaller screens like my phone, on all of which high resolution would be wasted anyway.
I want to know a.) all the variables, b.) the weight of each variable, and c.) the reason those variables were assigned that weight. And on a guess, to work that out, I'll probably have to do it myself the old fashioned way; custom presets for my test sets and doing a batch for each one.
So I feel a little less dumb now.