Looking at the FFMPEG version in MCEBuddy, it says “N-95085-g525de95679”, which does not reveal much about the dates/versions of FFMPEG. It says built with gcc 20190918, but it is not clear if that’s the date of the GCC compiler used to build this version of FFMPEG or the date the FFMPEG was pulled from the git source repository and built.
We do test newer versions of the various tools. We have to test for stability and performance (and compatibility). Often newer versions have bugs or sometimes have poorer performance; for example, we have different builds of handbrake for Intel QSV conversions and for NVEnc conversions. Each testing cycles takes weeks for 24x7 testing across a lot of machines and 100,000’s of files before they’re certified for general use with MCEBuddy.
But for personal use, absolutely go ahead and do a drop in replacement, test it out and feel free to share your feedback.
Updated FFMPEG is something I am anxiously waiting for as well.
I am no longer using MCEBuddy to reencode my recordings because it does not handle the AC-4 audio used in ATSC 3.0. Instead it just have it copy and rename the files over and have Emby transcode them because Emby does have an updated FFMPEG that handles it. But I would really like to get back to using MCEBuddy since I have so much more configuration and control options with it.
The Emby builds are a FFMPEG 5 tree based build.
In transcode logs I see:
*01:56:01.333 ffmpeg version 5.1-emby_2022_10_11 Copyright (c) 2000-2022 the FFmpeg developers and softworkz for Emby LLC*
*01:56:01.334 built with gcc 10.3.0 (Rev5, Built by MSYS2 project)*
I did try dropping them and replacing the MCEBuddy builds but then the jobs would not execute. It has been a while but as I recall the command line that MCEBuddy was passing to FFMPEG just wasn’t getting it done.
I dropped in Handbrake-CLI v1.5.1 and so far, so good. No issues. Win10x64 22H2 (19045.2364) , i5-4430, RTX-2060.
It does seem like the GPU fans are running lower than full-on. GPU utilization seems to be 60-70%, maybe a tad lower? CPU utilization seems to be the same ~95% during encoding.
I haven’t run the same file through with both versions, but the same show on the same channel processed earlier with MCE Buddy and Handbrake 1.3.1 seems to have a lower chroma than the show processed with 1.5.1 when I played both side-by-side and synced up the video to see how they were different between the two handbrake versions.
I don’t know if the processing time is slower or faster between the versions of Handbrake. I’m transcoding to H.265 and AC3 into a MKV container.
Update on my (limited, 1 data point, Intel i5-Haswell, RTX2060) testing drop-in updates:
Handbrake CLI 1.6.1 - OK, from 1.3.3. Did not touch CLI-qsv (1.0.7), although 1.6.1 claims support, so qsv version not needed anymore?
MKVMerge and MKVExtract 74.0.0 - OK, from 17.0.0 (download portable and extract individual utilities)
AVIdemux 2.8.1 - OK, from 2.7.1 (app restructured, just kept plugins directory)
FFMPEG 6.0 stable released! Used gyan.dev builds.