In doing more work with this, I have the following observations:
- As mentioned earlier, a sports event video as a test file produced a compressed file about 40% of the size of the non-compressed file. I tried a couple of videos (1080p) which had less action with decent video production values (not a big-budget movie) and I got compression to 18% (test video 1) and 9% (test video 2) using the H.265 VideoToolbox option. There was a wider range of file sizes between H.264 and H.265 with and without VideoToolbox as well than was the case of the sports video.
- I found an online conversation between one of the Handbrake developers and some Handbrake users. The developer mentioned that Apple does not provide much in the way of tuning options for the VideoToolbox. From what I saw the only real option to control quality vs. file size was the "Average Bitrate" option (in the Video tab). Increase the bitrate and the quality and file size goes up. The Handbrake developer bemoaned the fact that a Quality setting (will appear just above the "Average Bitrate setting) is not available when using the VideoToolbox (as it is for the x264 and x265 encoders). This allows the bitrate to fluctuate so that more compression is done in the more static scenes, less in more active scenes.
- In taking the time to do a side-by-side, frame comparison (selected frames) on one of my 1080p test videos (not the sports video), there were obvious quality differences between the VideoToolbox H.265 and the uncompressed video where there is a lot of detail and then action around that detail. Now, if that detail is not important contextually to the content of the video, one may not notice the difference if one is asked to compare the videos in their entirety in real-time (not frame-by-frame or side-by-side). The default H.264 fast setting produced (in my opinion) better quality with a 24% larger file size.
- It is clear that the CPU plays a big role in the H.265 VideoToolbox encoding because I see high (90%+) CPU utilization over all cores on a consistent basis. Because we can't see what the T2 utilization is (if I'm wrong, please let me know), we don't know what role it plays - can it actually do a full encode or does it just do specialized tasks? I suspect it can do a full encode and so at this point, I also suspect the T2 and the CPU encode different portions of the video.
- In my opinion, the Handbrake default of x264 (fast) does a good job of balancing quality, processing time and file size. Because of the lack of flexibility in setting the quality, I don't see using the H.265 VideoToolbox as my default encoder. If there's more flexibility in using the T2/CPU hardware (either through VideoToolbox or other means), that may change. I probably will use it when file size/processing time considerations outweigh quality considerations but at this point, I'm not going out and re-encoding my Blu-ray-derived videos.
- Although the H.265 VideoToolbox is not yet part of the public release, and because it appears that Handbrake just hands off the encoding to the VideoToolbox, I would suspect that there won't be much difference in what is there now in the nightly build and what will be in the public release. More important is any new release of the VideoToolbox by Apple. So if you need the smaller file size/faster processing time now that H.265 VideoToolbox affords, then just use the latest nightly build for H.265 VideoToolbox encodes (but keep the public release as well).
UPDATE (after 4 days): In doing actual files (not 2-minute clips) - 1080p commercially-produced downloaded files, 15-30 minutes in length and comparing it with using the software x265 encoder, the VideoToolbox produces significantly larger files. For files that have been more compressed (looking at bytes per frame), I find it's non uncommon for files to be larger than the original. Also, doing files with lower resolution than 1980x1080 produced much larger files than the original (only tested 3 files but the files were at least 60% larger) - I don't know changing the settings will fix that. With my two 2-minute test files, the CPU utilization was close 90%+ but - in looking at the Activity Monitor during the processing on one file, the utilization didn't go over 300% (1200% is the max for my MBP). I haven't done enough testing to be able to make a good characterization of T2 vs CPU use for the files I'm working on.
