x264 encoder, Resolve 17 Studio for Windows, macOS, Linux

Would be great if someone in the know could compile it for Mac and post it here for all.

I documented how to compile this under windows and shared minor changes to the source and build files.

https://github.com/UDaManFunks/x264_enc ... /README.md

Not a fan of sharing projects that needs to be built via a Visual Studio solution file. I created the files needed to compile the encoder by using "NMake" instead.

Thank you for your guidance. I am really sorry to have more questions...

Sorry about that, "MacOS" needs to be under "Contents".

As for x264 under MacOS and installing all the tools, it's going to be pretty tough for anybody to explain how to compile / build software unless that person has software development background (and know to use those development tools). Best thing you can do is to ask somebody with MacOS to compile it and share the binary.

I've compiled it for Windows and Linux and can share it (along with changes to the source), can't do that for the MAC.

Okay, I think I misunderstood. I already have the compiled PlugIn downloaded from Benjamin McGuire's post from this thread: viewtopic.php?f=21&t=125570&start=50#p908696

I copied that file (x264_encoder_plugin.dvcp.bundle) to the location: /Library/Application Support/Blackmagic Design/DaVinci Resolve/IOPlugins

Then I ran Terminal App and executed:
xattr -rd com.apple.quarantine "/Library/Application Support/Blackmagic Design/DaVinci Resolve/IOPlugins/x264_encoder_plugin.dvcp.bundle"

I can start Resolve without an error message but the option to use x264 does not appear in Deliver Page when I choose MP4...

Anything I am missing?

Thank you for your guidance. I am really sorry to have more questions...

Sorry about that, "MacOS" needs to be under "Contents".

As for x264 under MacOS and installing all the tools, it's going to be pretty tough for anybody to explain how to compile / build software unless that person has software development background (and know to use those development tools). Best thing you can do is to ask somebody with MacOS to compile it and share the binary.

I've compiled it for Windows and Linux and can share it (along with changes to the source), can't do that for the MAC.

Okay, I think I misunderstood. I already have the compiled PlugIn downloaded from Benjamin McGuire's post from this thread: viewtopic.php?f=21&t=125570&start=50#p908696

I copied that file (x264_encoder_plugin.dvcp.bundle) to the location: /Library/Application Support/Blackmagic Design/DaVinci Resolve/IOPlugins

Then I ran Terminal App and executed:
xattr -rd com.apple.quarantine "/Library/Application Support/Blackmagic Design/DaVinci Resolve/IOPlugins/x264_encoder_plugin.dvcp.bundle"

I can start Resolve without an error message but the option to use x264 does not appear in Deliver Page when I choose MP4...

Anything I am missing?

Did anyone manage to get the PlugIn work under macOS with Apple Silicon and Resolve Studio 18?

Thanks in advance.

UDaManFunks - Thanks very much for your efforts!

I followed your detailed instructions, and apparently got all steps completed without errors.

So I have a file: x264_encoder.dvcp of 1.85 MB (1,940,992 bytes).

I have copied it to my:

C:\ProgramData\Blackmagic Design\DaVinci Resolve\Support\IOPlugins\x264_encoder_plugin.dvcp.bundle\Contents\Win64\

folder, but the option to use it in Davinci Resolve does not appear in my Video Export Options Menu. Only Native and Nvidia appear.

The "old" version called x264_encoder_plugin.dvcp works correctly when installed in the same folder.

So, does anyone (especially Udamanfunks, if you have time) have any suggestions? Does my file size look about right?

I am running Resolve Studio V19 Beta 4, but I doubt that is critical.

Thanks in advance for any help!!

IB

UDaManFunks - Thanks very much for your efforts!

Good thing that the instructions work, you might want to clone the x264_encoder again and build it as I made some changes (listed below).

Changes:

UUID so it doesn't conflict with the sample code
x264_encoder_plugin -> x264_encoder
bitrate property should be in Kbps
got rid of constant quality and made it default to constant rate factor instead

Here's what you should do

rename the "x264_encoder_plugin.dvcp.bundle" folder in your IOPlugins to -> "x264_encoder.dvcp.bundle".

Inside that folder, there should be a "Contents\Win64" subfolder, make sure you drop in the x264_encoder.dvcp BINARY there (which you built using NMake).

It should work if you select "MP4" or "QUICKTIME" export format - you should see a "Codec" setting for "X264 (8-bit)"

UDaManFunks:

Yahoo! I repeated the process from [Complile X264] and this time I eventually produced a x264_encoder.dvcp file sized 2.19MB (bigger than my 1st Attempt).

This now works correctly in Resolve Studio Beta4 in:

C:\ProgramData\Blackmagic Design\DaVinci Resolve\Support\IOPlugins\x264_encoder.dvcp.bundle\Contents\Win64\x264_encoder.dvcp

I swear that I got zero error messages the first time through.

Thanks for all your help.

But I think I should mention, in a Non-Critical way, that there are a couple of typos in your Readme.md as I hilite below. I just do this to maybe help someone else:

plugin x264-5.jpg (132.23 KiB) Viewed 6734 times

Best Regards

IB

UDaManFunks:
But I think I should mention, in a Non-Critical way, that there are a couple of typos in your Readme.md as I hilite below. I just do this to maybe help someone else:

Fixed the README.md per your comments. Would be nice to drop in binaries in there as well but not sure what the legality is, at least some can build it from source now.

Looking at the code that does FRAME conversion from UYVY (4:2:2) -> PACKED Y+UV conversion takes a bit of time (as much as the time call to encode the frame with x264), parts of this is not really well documented but it looks like the DoInit function

Code: Select all

   // fill average frame size if have byte rate
   uint32_t val = clrUYVY;
   p_pProps->SetProperty(pIOPropColorModel, propTypeUInt32, &val, 1);

   uint8_t hSampling = 2;
   uint8_t vSampling = 1;
   p_pProps->SetProperty(pIOPropHSubsampling, propTypeUInt8, &hSampling, 1);
   p_pProps->SetProperty(pIOPropVSubsampling, propTypeUInt8, &vSampling, 1);


I'm trying to take a whack at creating an x265_encoder, the main (8-bit) profile only works with the YUV 4:2:0 colorspace (X265_CSP_I420) and maybe YUV 4:4:4 colorspace (X265_CSP_I444) per x265 header file (x265.h).

I don't really do this type of software development. I'll check in the code and will share.

UDaManFunks

Thanks for your work. An X265 compressor would br very nice.

I noticed that the "Old" encoder seemed to refer to libx264-161.dll, whereas I see libx264-164.dll in your x264 Download Folder, so I assume you are using to an updated version of X265, which is good. (the old version seems to date from 2021).

Also, can I assume that you are not implementing any X264 Filters, such as Detelecine, Deblock, Sharpen, etc, etc ??

Best Regards


IB

UDaManFunks
I noticed that the "Old" encoder seemed to refer to libx264-161.dll, whereas I see libx264-164.dll in your x264 Download Folder, so I assume you are using to an updated version of X265, which is good. (the old version seems to date from 2021).

Yes, I based it off the latest version of x264 (which seems to be v164 at this time) when I cloned it from the git repo. As for the filters, ala handbrake - I'm pretty sure those are implemented in Handbrake itself, or through FFMPEG exposed to HandBrake as they are not explicitly tied to the video encoder exposed in the "Video" tab in handbrake.

As for the x265_encoder, I've done some work on it and the source is available at

https://github.com/UDaManFunks/x265_encoder

It's based off the x264_encoder from BM but modified to call the x265 API functions, it just supports the "main" profile for now (8-bit) as implementing the "main10" profile is a bit tricky as the x265 library neds to be "recompiled" to support 10 bit explicitly (so you'll have 2 dlls if you want to add support - 1 for 8-bit, and the other for 10-bit version) - similar to how handbrake does it (there's an option for "H265 (x265)" 8-bit, and "H265 10-bit (x265)" for 10-bit).

There's not a lot of documentation on the plugin development / properties like how to support 4:2:0 chroma sub sampling, and can one dynamically change the bit depth (in DoOpen, SetupContext) even though in s_RegisterCodecs - it's set to 8?

Anyways, the 8-bit version I compiled produces output out so it's somewhat working.

Added instructions on how to build the "x265_encoder"

UDaManFunks,

Thanks for all your efforts.

So I followed your instructions and they all seemed to work correctly. I ended up with a x265_encoder.dvcp of 5.28 MB.

After restarting Resolve I am able to select X265 (8Bit) in the Export Options Window.

And it runs, and compresses my videos.

But I find it to be unusably slow with framerates of 2-3 per sec.

I guess this is what you mean by "it's somewhat working." !!??

I wonder if other users find the same result??

Anyway please keep up the good work, and I will definitely try any updates you may produce.

Thanks again,

IB

After restarting Resolve I am able to select X265 (8Bit) in the Export Options Window.

And it runs, and compresses my videos.

But I find it to be unusably slow with framerates of 2-3 per sec.

Can you git clone the x265_encoder and see if it's faster now for you. I removed alot of the internal debug logging I was doing. Additionally, i'm now using Resolve's clrNV12 (as the source layout) and converting it to X265_CSP_I420. Both have a chroma sub sampling of 4:2:0, and code wise - there's less looping (and accumulating y data) going on compared to the original AYUV -> X265_CSP_1420.

Encoding via resolve for me using X265 (2560x1440@30 fps) using the same profile and settings as handbrake "H265 (x265)" - it's fairly close. X265 is slower than the H265 software encoder built into resolve but I'm assuming it produces better output.

I'm thinking about building a 10-bit version to support main10, but that's gonna be even slower than this one..

x265_encoder_10b

supports the "main10" profile.

https://github.com/UDaManFunks/x265_encoder_10b

UDaManFunks,

Again thanks for this.

x265_encoder_10b compiled apparently correctly, and it appears correctly in Davince Resolve Delivery Page. And it Compresses video.

But it runs at 3-4 fps which is unfeasible. It starts momentarily at 24fps (which is roughly what I would expect, but drops within 2 seconds to 10 then 5 then 3.


The only output messages that look perhaps questionable are in the execution of "./make-Makefiles-64-bit.sh". This step takes 5 minutes to run and outputs hundreds of text line, and at numerous locations I see:

warning: dropping trailing empty parameter in call to multi-line macro `DEFINE_ARGS_INTERNAL' [-w+pp-macro-params-legacy]

but the process continues to 100%.

I don't know nearly enough to suggest a solution.

I will be interested to hear from anyone else who tries this encoder.

Best Regards

IB

I should have mentioned that the files I am working with are 1080p being upscaled in Resolve to UHD (2160x3840).

So I did some more testing with smaller resolution files, and got better results but still not great.

So if I take 720p to 720p with x265-10bit I get 50fps.

With the old x264 plugin 720p to 720p I get 80fps.

So if I take 720p to 1080p with x265-10bit I get 20fps.

With the old x264 plugin 720p to 1080p I get 80fps again.

So if I take 720p to 2160p with x265-10bit I get 5fps.

With the old x264 plugin 720p to 2160p I get 28fps.

And with Nvidia H265 720p to 2160p I get 45fps.

So It seems that high resolution, or big upscaling ratios, give very low fps.

I will try to do some more testing soon.

Best Regards

IB

I should have mentioned that the files I am working with are 1080p being upscaled in Resolve to UHD (2160x3840).

There's not really much we can do to speed up the encodes up from a software perspective. The plugin is just a glue to the x265 encoder api. When you upscaled from (1080p -> 4K) - it means the source buffer presented by the plugin to the encoding function is four times larger (just at 8 bit). When it's more than 8 bits (e.q 10, 12, or 16) - it's literaly doing (four times more * 2) due to it using two bytes each component to represent YUV data.

Encoding in hardware (NVidia, AMD, Intel QuickSync) will always be faster compared to software encoding, specially if the upscaling is being performed in hardware as well (otherwise, that upscaling processing tax via the CPU will be added latency regardless of what encoder is used).

My opionion is that the only time you should be using x265 is if your desired target bit rate is producing encodes that's visibly lower quality (e.q NVIDIA H265 encoder) than what software encoders like X265 can produce at the same bit rate.

I'm trying to build one more encoder, and that's the "prores_encoder" plugin using FFMPEG's LIBAVCODEC library. It should support the following profiles

* Apple ProRes 422 (Proxy)
* Apple ProRes 422 (LT)
* Apple ProRes 422
* Apple ProRes 422 (HQ)

this is only applicable to people running Resolve in Windows and wants to export a quicktime .mov file using prores.

I should have mentioned that the files I am working with are 1080p being upscaled in Resolve to UHD (2160x3840).

Instead of using RF (Constant Quality), try using Average Bit Rate and set it to your desired average bit rate. It's usually faster than using RF

OK, thanks.

I will continue trying to understand video compression!


IB

Hi,

I have compiled all the latest software MP4 Compressor Plug-ins for DaVinci Resolve, kindly provided by Sergey Mirontsev and UDaManFunks.

So Now my export screen looks like this:

compressors.jpg (31.16 KiB) Viewed 5990 times

AVC is Sergey's original x264 compressor from 2020.

So I decided to conduct some speed tests, and I report the results here. I am not a professional, and I realise that one would have to do hundreds of tests to really understand the various Plugins performance. I completed 23 test runs with Resolve, and 4 tests with Handbrake as a kind of comparison.


I made two test samples, both Mp4, one 720p at 50 fps with a data rate of 6000 kbs, and one 2160p (UHD) at 50fps at 8000kbs. Both are very similar in content, mostly just actors moving around, without any very high speed movement, like cars etc.

I performed three series of tests in Resolve with various Plugins and Hardware compressors, as follows:

Series 1: 720p compressed to 720p.

Series 2: 2160p compressed to 2160p.

Series 3: 720p compressed to 2160p

There was no color correction involved, and I tried Series 3 both without Superscaling, and with Superscaling, Medium Sharpness and Noise Reduction.


Where appropriate the X264 and x265 compressors were set to speed medium, and hardware compressors to Balanced.

In most cases I used the Average Bit Rate setting, but I tried Auto Low Quality for the Hardware compressors, but this produced some absurd bitrates, as reported!

I did not attempt to seriously assess visual quality. This would be too time consuming and very subjective. I did look carefully at all output files and I would say that quality was always good. I did not see any blockiness, etc. I could see some differences between the files, but it is very difficult to say which is best. Sharpness, for example, is easily exaggerated.

So here are my results, with datarates and finally FPS, which is what I was looking for.

Series 1: 720p compressed to 720p.

1. x264-8bit medium 3000kbs 115fps

2. x264 AVC medium 3000kbs 160fps

3. x265-8bit medium 8000kbs 22fps

4, x265-8bit medium crf25 (813 kbs) 45fps

5. x265 8bit medium crf18 (2550 kbs) 34fps

6. x265 10bit medium 3000kbs 25 fps

7. h265 nvidia medium auto low hq (2740 kbs) 760fps

8. h265 native medium auto low hq (2150 kbs) 620fps


Series 2: 2160p compressed to 2160p.


1. x264 AVC medium 12000kbps hq 28fps

2. x265-10bit medium 12000kbps hq 3fps

3. x265-8bit medium 12000kbps hq 5fps

4. h265 medium 12000kbps hq 95fps




Series 3: 720p compressed to 2160p


1. no ss x264 AVC medium 3000kbps hq 40fps

2. no ss x265 10bit medium 3000kbps hq 5fps

3. no ss h265 nvidia medium 3000kbps hq 95fps

4. no ss h265 nvidia medium auto low (20,000kbs !!) hq 103fps

5. no ss h265 native medium auto low (10,000kbs) hq 95fps

6. ss med med x264 AVC medium 3000kbps hq 38fps

7. ss med med x264 AVC medium 9000kbps hq 28fps

8. ss med med x265-10bit medium 12000kbps hq 4fps

9. ss med med h265 native medium 12000kbps hq 95fps

10. ss med med h265 Nvidia medium 3000kbps hq 102fps

11. ss med med h265 Nvidia medium auto low (21,000kbs !!) hq 102fps



Handbrake Runs:


1. 720p x265-10bit (Encoded) 66fps

2. 720p X264 (Encoded) 150fps

3. 2160p x265-10bit (Encoded) 10fps

4. 2160p h264 nvidia (Encoded) 100fps


To seriously explore this subject you would have to take weeks, and do hundreds of tests.

So I do not propose to draw any Conclusions.

But I think I can see some General Trends, as follows:

1. The hardware compressors are much faster that the software ones, by factors of 4 to 5. Hooray! Everyone knew that any way.

2. X264 compressors are faster than x265 by factors of 3 to 5. Again, I think this was well known.

3. The X265 compressors struggle with 2160p material. Even in Handbrake, with their X265 Compressor, I only got 10fps with 2160p material. This was a bit faster than with the Resolve Plugin, but still very slow. 5 hours to compress 1 hour of video is really not useable.

4. On my machine, SuperScaling generally causes very little speed loss when upscaling.


I hope somebody else find this information useful,

IB

I created the PRORES export plugin, made a thread about it here. Only relevant to Windows and Linux Davinci resolve users though.

viewtopic.php?f=21&t=204743

I have compiled all the latest software MP4 Compressor Plug-ins for DaVinci Resolve, kindly provided by Sergey Mirontsev and UDaManFunks.

Hi there, for which operating systems did you do that and where can I find/download it. Thanks in advance!

I made some minor fixes to the following plugins

x264_encoder (https://github.com/UDaManFunks/x264_encoder)
x265_encoder (https://github.com/UDaManFunks/x265_encoder)
x264_encoder_10b (https://github.com/UDaManFunks/x265_encoder_10b)
prores_plugin (https://github.com/UDaManFunks/prores_encoder)

For Windows, here are the latest binaries

https://drive.google.com/file/d/14WMO_7 ... drive_link

Any chance for macOS?

George, if you're looking for other plugin ideas I think something that would be really useful is an ffmpeg plugin. Something that serves frames to ffmpeg and just takes a textbox as input parameters. That way we can use all the standard ffmpeg parameters without creating a GUI for it. It would also need a way to point out a path to ffmpeg (the user supplies the ffmpeg executable).

I might take a stab at it myself but I'm swamped with work for the time being.

Any chance for macOS?

Sorry but I don't have a MAC - I do have a Linux box though (Ubuntu) so I can probably create binaries for that platform, albeit - not sure if it's worth it.

It shouldn't be too hard for a mac owner to compile these plugins, they just need to fix the makefiles (which is fairly straight forward).

Any chance for macOS?

Sorry but I don't have a MAC - I do have a Linux box though (Ubuntu) so I can probably create binaries for that platform, albeit - not sure if it's worth it.

It shouldn't be too hard for a mac owner to compile these plugins, they just need to fix the makefiles (which is fairly straight forward).

Alright, thanks for the reply.

Does anyone here has the skill and time and motivation to do that? I would appreciate that a lot.

Some people have started using the plugins on Linux as well so I made sure build instructions were available for both Windows and Linux.

https://github.com/UDaManFunks/x264_encoder
https://github.com/UDaManFunks/x265_encoder
https://github.com/UDaManFunks/x265_encoder_10b
https://github.com/UDaManFunks/prores_encoder

Binary for Windows and Linux

https://drive.google.com/file/d/1-vH607733Og5uQsQ6fcEeUqSsDN44KAg/view?usp=drive_link

Thanks for the Linux instructions, I have to give it a go. As a matter of interest does the x264/5 plugins have an option where we can specify extra params? I export as PNG and then use ffmpeg with my own tuned params and was hoping to skip the png step.

Thanks for the Linux instructions, I have to give it a go. As a matter of interest does the x264/5 plugins have an option where we can specify extra params? I export as PNG and then use ffmpeg with my own tuned params and was hoping to skip the png step.

The X264 PLUGIN only supports the following profiles

baseline
main
high
high422

Note: encoder preset, encoder tune, CRF or Variable (and if Variable, 2 pass and desired average bitratre) settings are exposed.

The X265 PLUGIN only supports (standard 8-bit)

main

Note: encoder preset, encoder tune, CRF or Variable (and if Variable, 2 pass and desired average bitratre) settings are exposed.

The X265 10B PLUGIN only supports (10-bit)

main10

Note: encoder preset, encoder tune, CRF or Variable (and if Variable, 2 pass and desired average bitratre) settings are exposed.

The PRORES plugin supports

422 PROXY
422 LT
422
422 HQ

Note: no settings here as bitrate and etc are implied based on the profile

As for extra params, I didn't implement that as I personally don't want to deal with tech support - lol. People setting their own parameters will message me asking why it's core-dumping, or the video the plugin outputs doesn't playback. Pretty sure I'll be getting a message one of these days asking why X264 HIGH 422 export doesn't play back on their Windows PC.

The good news is that the source is available, along with PROPER build instructions (which will already get you 95% there). People that want to customize it further can create their own plugins using these as a base. Additionally, certain profiles require specific input formats - for example, the X264 HIGH 422 profile requires an input format of 'UYVY', while the X264 baseline, main, and high requires 'NV12' (these are set during plugin registration and can't be changed dynamicallly). I actually enhanced that piece of code on my copy of the x264_encoder to remove that inefficiency (the original x264 encoder sample from BM was performing UYVY -> NV12 conversion (on the plugin) when using the baseline, main, and high profiles which are the profiles most people use, not high422 (performance tax on the general use case).

I'd really like to compile these plugins for the MAC as well (although PRORES won't be needed on the MAC) but don't have access to one. I believe MACOSX uses CLANG for it's C++ compiler so finding the right CLAGS and LDFLAGS for it shouldn't be too hard as long as one can compile X264, and the X265 static libs under MACOSX.

Hello again,

in the Lift Gamma Gain Forum we narrowed the error source down. I assume that the x264 plugin for Resolve Studio only works up to the Apple Silicon M1 Pro. So M1 Max and M2/M3 are not working. Anybody here who can confirm that?

Link to LGG forum discussion: https://www.liftgammagain.com/forum/index.php?threads/any-experience-building-x264-for-the-new-encoder-io.15176/page-2#post-180218

As for the x265_encoder, I've done some work on it and the source is available at

https://github.com/UDaManFunks/x265_encoder

Thanks a lot for the job well done UDaManFunks!
If you have a moment, I have a few questions I'd like to ask:

- I understand that you did not change the OFX plugin wrapper, correct?

- on the git readme you suggest to clone from https://github.com/videolan/x265, while Videolan suggests https://bitbucket.org/multicoreware/x265_git. Is this a mirror or alternative branch?

- How did you debug the code? By attaching Davinci Resolve process?

in the Lift Gamma Gain Forum we narrowed the error source down. I assume that the x264 plugin for Resolve Studio only works up to the Apple Silicon M1 Pro. So M1 Max and M2/M3 are not working. Anybody here who can confirm that?

I compiled x264 sample plugin on my M2 MacBook Air and I was able to encode test video using the plugin

- I understand that you did not change the OFX plugin wrapper, correct?

- on the git readme you suggest to clone from https://github.com/videolan/x265, while Videolan suggests https://bitbucket.org/multicoreware/x265_git. Is this a mirror or alternative branch?

- How did you debug the code? By attaching Davinci Resolve process?

1) The plugin base code (interface definitions) comes from Black Magic. It's part of the Resolve Installation - run Resolve, click on the "Help" menu item -> "Documentation" -> "Developer" -> "Codec Plugin"

2) https://www.videolan.org/developers/x265.html says the source repository is now "git clone https://bitbucket.org/multicoreware/x265_git.git". They might have moved it from github -> bitbucket. I'll update the docs.

3) Good ole logging statements - lol. The plugin API exposes a logger function that outputs automatically to the davinci resolve log. The code is fairly straight forward so it's not too hard to eyeball / debug.

Did anybody try adding custom plugin to MKV?

Code: Select all

std::vector<std::string> containerVec;
containerVec.push_back("mp4");
containerVec.push_back("mkv");
containerVec.push_back("mov");
containerVec.push_back("MKV");


Whatever I do, I do not see my plugin under MKV selection, however I can see it under MP4 and QuickTime.
in IOPluginProps.h they have a comment
// string list with UUIDs or mov/mp4 strings

But I cannot find what GUID should be for MKV container.

Thank you UDaManFunks and Sergey for this! Is there an updated Windows binary link? All of the links I've clicked on are dead. Thank you!

Thank you UDaManFunks and Sergey for this! Is there an updated Windows binary link? All of the links I've clicked on are dead. Thank you!

https://drive.google.com/file/d/14WMO_7 ... drive_link