@cayars said:
Something to check if you are worried about file size over viewable quality is to change the CRF setting. I use 18 by default and you could go as high as 22 (default of ffmpeg) and be “normal”. There is a good chance you are using a setting of 22 in Handbrake anyway.
So if you want to compare apples to apples instead of apples to oranges try changing the CRF to 22 and then run another file through the script. 
If DTS is set then that will allow DTS to be copied over to the new file it produces. The only “audio conversion” per say that is done is the creation of the two channel AAC audio channel (first track) and this can be done from multiple different sources.
Thanks, Carlo. I’ll be a guinea pig and run some more tests.
I -believe- the default CRF setting for ffmpeg is actually 23, but that might just be the particular flavor / version.
I’ve re-configured the INI file to use 22 and ran a file through again. I ended up reducing a file of size 29,210,551,473 bytes to 5,413,933,570 bytes using only your scripts in 2 hours 31 minutes. Using my HandBrakeCLI transcode coupled with your scripts to relocate the MOOV atom, I have previously reduced this same file to 6,431,698,226 bytes in what I believe was a similar amount of time.
As before, I’m using the same VM to do all of the testing, so the only thing that I’m changing is the set of programs / scripts that do the actual work. Source and destination files are on the same servers, on the same disks for all tests with drives nfs-mounted. Watching the network load via the virtual server management program shows me that the network is not factoring in (not even close) to performing the conversions. In fact, the only time I see the conversions slow down is if I’m doing a large file transfer across the network involving the server that stores the source and destination files. The high network load from the large file transfer slows down the communications for this process during the period of the transfer. So, I’ve restricted any large transfers to be done outside of my testing windows.
Since the long-term goal is to get to a point where I can set up a “large conversion job” to sweep through my entire library unattended, I’m going to look at creating an out-of-band network specifically for the VM to access the two file servers so that no data transfers or access on the front-end network will be able to slow things down for the transcoding / conversion.
Also, I looked at the preset I’m using in HandBrake, and it -appears- to be using an RF of 18 (that’s their CRF variable). Seems odd to have such a stark difference in final size if the RF/CRF and max video settings of 4 were both the same.
