Just upgraded my server from a p2200 to a a2000. With the ffmpeg build in mcebuddy on the a2000 I am encoding at 5.11x. With v6.0, I am greater than twice that at 11.9x. I am reiterating my request to update ffmpeg in mcebuddy.
@techpro2004, while you wait, you can try copying a newer FFMPEG into MCEBuddyâs program folder called âffmpegâ. You will just replace the ffmpeg.exe and ffprobe.exe files from the new version.
I am using the âessentialsâ build of FFMPEG 6.0 for Win10x64 from Builds - CODEX FFMPEG @ gyan.dev
If you build your own, you will want to include your GPU libraries and statically link everything.
I prefer to use the official mcebuddy ffmpeg build as that has been checked inside and out.
Goose, again please update the ffmpeg build in mcebuddy. also please let us know you are working on it.
thanks.
Goose are you there?
Hello Goose.
Looking closer at Handbrake, it seems they donât even use FFMPEG for hardware AV1 encoding. They use SVT-AV1 for that.
- Added SVT-AV1 (software, v1.4.1) and Intel QSV AV1 (hardware) video encoders
So maybe asking for an upgrade of FFMPEG isnât the right ask here. Might have to do with why Goose said earlier that âitâs complicatedâ.
If you need it right away, you have a solution: drop in the new FFMPEG of your choice, even compiled and optimized just for your Platform, OS, CPU, and GPU. (Which you havenât shared, btw).
If you can wait (as you said earlier) for Goose and the MCEBuddy developers to do the testing and regression testing for all the permutations of Platforms, Operating Systems, CPUs and GPUs used by all of the MCEBuddy users, then wait.
If you have an urgent need just for you, you can always ask for pricing on a development contract to do a custom build, just for you. to your specifications and an agreed upon schedule.
no urgent need, just want to know they are working on it.
also said 5 days ago what gpu my server uses and goose knows what my other system uses from the first post in the thread.
Goose??? Any Word???
Weâre seeing stability issues with Intel hardware
I am seeing stability issues with the build in mcebuddy now as well as the current build on nvidia hardware. it is not the ffmpeg build that is causing it. please see my other thread. my guess (just a guess) is it has to do with the hardware decoder. please play around with this. thanks.
Goose, Is there an update on this? thanks.
Just a side note. Looking at the nVidia GPU encode/decode support for the A2000, there is no GPU support for AV1.
Source: Video Encode and Decode GPU Support Matrix | NVIDIA Developer
Also, MCEBuddy using Comskip, will use the embedded FFMPEG linked into the Comskip binary. When MCEBuddy uses Handbrake for transcoding, Handbrake will use the embedded FFMPEG linked into the Handbrake CLI binary.
So dropping in a newer FFMPEG only affects transcoding done with FFMPEG. So depending on your workflow settings in MCEBuddy, several different versions of FFMPEG could be used during the different stages of your workflow.
I have 2 systems one with a 4080 for encoding and another with a a2000 for serving.
I am not worried about comskip just encoding
Goose, did you test it without hardware decoding? Thanks
Also noticed that while I have my transcoding set to use handbrake, the âFast Remuxâ portion of the processing uses ffmpeg, and it does not use hardware decoding. Not sure there is a way to add custom command-line options for MCEBuddy when using ffmpeg or comskip. Although you can use a custom path for comskip, there does not seem to be a way to include command-line only options available in the more recent donator versions (there are no configuration equivalents --cuvid must be passed in on the command line).
My transcoding is configured in MCEBuddy to use HandbrakeCLI, and it is definitely using the nVidia to transcode to x.265 (a 2060).
Mike808, mcebuddy uses hardware decoding for the encode step on ffmpeg only. thank you for confirming handbrake does not use cuvid and it works, next maybe you could test ffmpeg encode with a wide range of materials to confirm my theory, I am using an ota antenna so sometimes reception is not the best. I find handbrake is much more forgiving than ffmpeg. my guess is no cuvid. please test it like this.
Goose, Any word on testing it no cuvid.
I think youâve misinterpreted what Iâve observed.
MCEBuddy processes media in roughly 3 steps.
Step 1 is processed with Comskip. The comskip with MCEBuddy is the donator version, but when Comskip refers to HWAssist, it does not mean GPU. It means the native CPU (integrated GPU) features in Intel CPUs and AMD APUs with on-chip media codecs. So the result is Comskip does not use your GPU and is CPU-bound.
The latest version of Comskip does have GPU decode options, but they are not currently accessible in MCEBuddy. Iâve raised a feature request to add a way to pass in the â-cuvidâ or â-vdpauâ command line only option. Again, Comskip is currently still CPU-bound, even if you use a custom Comskip and it is the newest donator version.
Step 2 is the demux, where the video and audio streams are split, and uses decoding. This is where MCEBuddy seems to be using FFMPEG (regardles of setting handbrake for encoding/conversion), and the version of FFMPEG while it has GPU encoders, it does not have GPU decoders. Only the newest version of FFMPEG does, and MCEBuddy does not invoke the GPU option for decoding since it does not know it will exist in a future version of FFMPEG, even if you drop it in place.
Step 3 is the video conversion where it applies the ad cuts (EDL file) from Comskip to the split video and audio streams (decoding again) and encoding into the combined output format with ads removed.
In Step 3, the decoding of the streams seems to use CPU, and the merge and transcode part does use the GPU. This makes atep 3 both CPU and GPU bound. Handbrake uses its internal statically linked FFMPEG, and it does not use the GPU to decode, but does use the CPU built-in playback and encode features of the integrated GPU on the CPU chip if available, and will use the GPU when envaled in MCEBuddy. The same goes for if you have MCEBuddy configured to use FFMPEG instead of Handbrake.
I donât think the version of FFMPEG baked into the Handbrake CLI (the MCEBuddy version, 1.3.3?) has GPU decoding, and the newest version (1.6.1?) doesnât have MCEBuddy using options that donât exist for the version it uses, even if you do drop it in. So this part of âvideo conversionâ is still CPU-bound.
In summary, itâs quite complicated as to when and if MCEBuddy can or will use newer versions of these sub-application parts of MCEBuddy, and even if it did, there are several places where it needs to be done separately in Comskip, FFMPEG, and the Handbrake CLI. Even then, any options used by Handbrake depend entirely on the statically linked FFMPEG within it, and it is separate from the standalone FFMPEG invoked by MCEBuddy.
Goose, what is going on? have you tried it without hardware decoding. Thanks.
Might I suggest you take the conversion to private message with Goose.
When you have a post on the forum itâs for the community to try and help. What is not helpful is to attack someone who is trying to help or understand what the post is about.
1 Like
Good idea, fyi I did not think I was attacking. I thought I was being quite tolerant for a long time.
1 Like
You said, and I quote:
âwhen using ffmpeg to encode mcebuddy automatically adds the options for gpu decodeâ
I have noted that this simply cannot be true. The version of FFMPEG that comes with MCEBuddy cannot use the GPU for decoding because the capability does not exist in that version of FFMPEG.
I have voluntarily spent my time to research your claims, and posted my testing results because I too was interested in updated binaries (the subject of this thread), and have found your claims of what you think MCEBuddy is doing to be contrary to what the software actually does and does not do.
I have also noted where the newer versions of the software actually are capable of doing what you are asking MCEBuddy to do, but does not and cannot do in the current versions.
Iâve also pointed out for you and Goose and the other MCEBuddy developers where there may be a possibility to add more GPU acceleration. However, not all GPUs are equal, and the number of dedicated encode and decode engines could be a crucial factor in how they tune MCEBuddy for use by the broadest user base. For example, my 2060 only has 1 encode/decode pipeline and it makes complete sense for transcoding (âvideo conversionâ as the MCEBuddy status indicates) for the TS decoding to happen in CPU (with using the CPUâs HW assist) while the encoding happens in parralel in the GPU. Otherwise it would have to be serialized as two separate GPU-only steps and no parallelization benefits.
Iâm sorry if the reality of how MCEBuddy actually works is more complicated than you wish it to be.
If you want a customized version of MCEBuddy optimized just for your hardware and use cases, perhaps you should have a conversation with MCEBuddy about funding that custom development to your specifications. Even then, what you ask may simply not be available if it doesnât exist in the open source (FFMPEG and Handbrake) and proprietary components (donator version of comskip) that MCEBuddy relies upon.
Perhaps MCEBuddy isnât the right tool for your requirements, in the end.
1 Like