Confusion about H.264 – BM, please clarify

We are seeing more and more questions recently about performance (or the lack thereof) with H.264 footage on different hardware. While 'transcode!" used to be the usual mantra, some are reporting excellent performance with version 14 even in 4K. But the picture is blurred and the configuration guide doesn't deliver a clear answer.

So, I'd like to ask the knowledgeable folks at BM to give us some guidelines, in particular for those who'd like to assemble their own configuration for Windows or Linux. My questions would be:

– Is it correct that there is no acceleration by dedicated hardware in the free version?
(Please, no bashing here, dear colleagues, this might be a licensing issue which BM doesn't want to pay for)

– Is it correct that an up-to-date, CUDA capable Nvidia card will always take over if present?

– Which unit is taking over if there is an AMD GPU only, specific CPUs or no acceleration at all?

– Which CPUs are taken advantage of for hardware acceleration?

– What's the situation with Apple's turnkey systems, given that they all have GPUs by AMD?

– What are the limits of H.264 formats supported in hardware, given the wide range of possible features?
(I know we could look up the latter, but maybe it's easy to tell for BM's engineers)

I'm sure not to be the only one who'd be grateful for a complete answer and it can only serve decisions of others to go for the Studio version, so TIA, Blackmagic.

+++1 Uli - Thank you.
I would like to see what the BM advertised 10X performance improvement was based on.
Time for some "Truth in Advertising"??

I can't see how using a GPU encoder/decoder has anything to do with licenses. I bought the GPU so BM does not supply the encoder/decoder and any codec license issues would be Nvidia's problem. It's the same as CPU decoding - BM is just making use of my available hardware.
Magix, who also own Sony Vegas software, state clearly how they saved codec license costs by using Intel's IGPU encoder/decoder. They also make some amazing performance claims using the Intel IGPU only for 4K (no Nvidia/AMD card needed).
https://software.intel.com/en-us/videos/how-magix-made-4k-360-video-editing-swift-and-easy

Personally, I thinks it's wrong to remove hardware support from the free version thus crippling it's claimed performance and usefulness to many of us after downloading and testing nine beta releases. I would not have wasted my time if they had made it clear from the outset that we would not see the claimed performance improvement without buying Studio. Performance was the only reason I wanted to try ver 14. BM kept quiet as users questioned performance throughout beta testing.

Add to that, the fact that we cannot even download and test the Studio version on a 30 day trial as we can with all other major competitors which prevents me from taking a $300 risk on Studio.
I also want an NLE purchased from and supported by the software developer - I seriously doubt phoning/emailing B&H in New York will solve my problems. All revenue should go back to the developer to improve and support their products and it also inflates the consumer price.

Lack of promised performance, limited codec/format input and delivery support means I may use Resolve as a color corrector but not yet as a turnkey NLE solution.

sure -- i would also appreciate a more open and detailed form of information and communication by BMD. some manufactures and service providers try to communicate this kind of more advanced topics and development progress in tech blogs, to inform the user community in more detail about advanced topics and keep interested users current.

regarding hardware [de-]compression acceleration, it's really useful to have a little bit more insight, to understand the actual processing and it's technical requirements and limitations a little bit better. for example: h.264 acceleration support on nvidia cards varies a lot between different generations of graphic cards. if you know, that this particular kind of acceleration will be used by your software, you are able to prevent shortcomings or not satisfaying supported aspects of of compression handling in advance. simple boundary conditions, like missing acceleration for 4:2:2 footage, could be bypassed and handled in a much more rational way.

Personally, I thinks it's wrong to remove hardware support from the free version thus crippling it's claimed performance

The fact that the free version of Resolve is so capable is honestly suprising, especially in comparison to other developer's crippled free software.

It's also surprising that some continue to complain about software that has been provided for free, especially with free software this capable.

Give Media Composer First or LightWorks Free a spin to appreciate the incredible deal BlackMagic has provided at no charge.

Add to that, the fact that we cannot even download and test the Studio version on a 30 day trial as we can with all other major competitors which prevents me from taking a $300 risk on Studio.

The free version is fully functional software for 95% of work (unless one requires 4K, support for 120fps, more extensive processing options, and filters, and so on), a fully capable non-expiring demo of Resolve Studio if you will.

Resolve Studio is much more affordable than almost any other comparable software, especially when one considers upgrade costs over time (compare 5 years of Creative Cloud subscription or Media Composer or even Edius update fees over the same period). This is especially true when purchasing with a currency exchange of 14:1 to the US dollar.

Give Media Composer First or LightWorks Free a spin to appreciate the incredible deal BlackMagic has provided at no charge.

+1

Reynaud - Hi at least we can agree on the exchange rate
Valid comments but I'm looking for a 4K edit solution so performance is an issue and have a limited budget for planned PC upgrade so don't want to throw a ton of hardware at the problem if I can avoid it - nor am I looking for a free solution.
Used Resolve since ver 12 and thought 14 was the solution but won't buy until performance claims and hardware needs can be verified. My feeling is that Resolve has been free since BM started changing it into an NLE so it could be introduced into a new larger market and get feedback from NLE users to assist development. I wouldn't bank on a free version as a long term strategy.

Regarding price here's a quote from forum member Marc Wielage who has a long history with Resolve:
"Going back, it's interesting to see what Grant Petty said right around the time Blackmagic bought daVinci Systems and announced the new version of Resolve back in 2009. It was interesting that back then, he said he could imagine cutting the price of Resolve from $850,000 down to $500,000:"

Thank you for that, it's interesting looking back.

Give Media Composer First or LightWorks Free a spin to appreciate the incredible deal BlackMagic has provided at no charge.

+1

it depends a lot, where users are coming from, what they are accustomed to, and what experiences the have gathered over time. this all shapes their expectations...

most windows and mac end users have never seen and experienced the actual impact and benefit of more open software development policies and the importance of access to technical information. but if you come from a linux background, it's looking very disappointing, what you have to accept in this respect as the status quo in the world of commercial closed source solutions and how users accept all this obvious lack of deeper insight and freedom to get to the bottom of things themselves -- yes, even fix annoying issues sometimes themselves, if needed.

but there is an interesting third realm between this confirmed open source scene and a strict profit oriented traditional software business on the other side: especially in more advanced production facilities and high end project realization you will always find computer experts, technicians and developers, which have to solve difficile system integration tasks, finding solutions to optimize the actual workflow and develop very specialized in-house software to solve requiremenets, where no ready made solution is available on the market. that's a very interesting field somewhere in between those other more familiar opposite camps. their work has a lot in common with free software development resp. are often build upon developer tools and approaches derived from this field, but it also shows significant similarities to commercial software development, because it's costly part of production and the archived results often have to be kept secret as competitive edge over the competition.

when i have to judge about the openness and suitability of products for more advanced work, i usually examine to which degree they fit into this framework of requirements -- i.e. how much customized adaptation and workflow optimizations based on technical experts insight they allow. applications, which only try to satisfy typical end user demands, often turn out as very unsatisfactory in respect to this kind of indispensable requirements with regard to more advanced professional use.

While 'transcode!" used to be the usual mantra

I'm new to Resolve, but I can say that I still recommend that option for editing all H.264 media in Adobe Premiere Pro. Their native proxy process combined with the included Cineform presets is a vast improvement in the editing experience.

Given the nature of H.264, I wouldn't hesitate to recommend the same for any NLE.

+1 Jim

Given the nature of H.264, I wouldn't hesitate to recommend the same for any NLE.

+1 as the walker bros sang, 'make it easy on yourself...'

Given the nature of H.264, I wouldn't hesitate to recommend the same for any NLE.

but that's definitely no answer to the reasonable questions of the TO, nor does it touch technical improvements concerning [any] actual software.

+++1 Uli - Thank you.
I would like to see what the BM advertised 10X performance improvement was based on.
Time for some "Truth in Advertising"??

I can't see how using a GPU encoder/decoder has anything to do with licenses. I bought the GPU so BM does not supply the encoder/decoder and any codec license issues would be Nvidia's problem. It's the same as CPU decoding - BM is just making use of my available hardware.
Magix, who also own Sony Vegas software, state clearly how they saved codec license costs by using Intel's IGPU encoder/decoder. They also make some amazing performance claims using the Intel IGPU only for 4K (no Nvidia/AMD card needed).
https://software.intel.com/en-us/videos/how-magix-made-4k-360-video-editing-swift-and-easy

Personally, I thinks it's wrong to remove hardware support from the free version thus crippling it's claimed performance and usefulness to many of us after downloading and testing nine beta releases. I would not have wasted my time if they had made it clear from the outset that we would not see the claimed performance improvement without buying Studio. Performance was the only reason I wanted to try ver 14. BM kept quiet as users questioned performance throughout beta testing.

Add to that, the fact that we cannot even download and test the Studio version on a 30 day trial as we can with all other major competitors which prevents me from taking a $300 risk on Studio.
I also want an NLE purchased from and supported by the software developer - I seriously doubt phoning/emailing B&H in New York will solve my problems. All revenue should go back to the developer to improve and support their products and it also inflates the consumer price.

Lack of promised performance, limited codec/format input and delivery support means I may use Resolve as a color corrector but not yet as a turnkey NLE solution.

+1

With the added note that I am very grateful for the free features BM put in Da Vinci Resolve, and upgraded to Studio to support them. Though I do wish I could have bought it directly from BM rather than through a middleman.

And, also, that v14 Beta 1 massively improved performance over 12.5, however, that performance declined a lot over the various betas. Now I find clicking around the UI and shots quite sluggish.

most windows and mac end users have never seen and experienced the actual impact and benefit of more open software development policies and the importance of access to technical information. but if you come from a linux background, it's looking very disappointing, what you have to accept in this respect as the status quo in the world of commercial closed source solutions and how users accept all this obvious lack of deeper insight and freedom to get to the bottom of things themselves -- yes, even fix annoying issues sometimes themselves, if needed.

Having developed in a both "closed" hardware and software environments (UNIX variants, "Classic" Mac OS and OS X, and FPGAs with VHDL), as well as completely "open" environments (Linux variants), I don't regard completely "closed" environments disappointing at all. They are simply just another thing, a tool to satisfy and solve a problem.

I also do not view "open" environments necessarily as flower, rainbows and unicorns, now that I can dive in to the source, and fix the world's software problems. From experience (and the experience of others within the open source community), I can safely state that the majority of users lack the required skill set, to firstly determine the root of a bug, and secondly fix the associated bugs, but also do so without breaking something else completely. Or, have the required time to even begin learning how to begin to do so.

Less than 1% of users have ever taken the source, fixed bugs discovered in software, committed those changes to be rolled back to the community in subsequent releases. And, I would venture than even less than that can honestly confirm that they have. The ones that have, though, tend to also be the least vocal about open environments (having dealt with teams within Canonical and those that developed Amazon's EC2, and several current teams within Amazon locally).

Any engineer worth their salt shouldn't have a "lack of deeper insight" and should be able to "get to the bottom of things themselves" even in a completely closed environment. It's called performing ones accepted duties, and delivering the end product or service without excuse.

but there is an interesting third realm between this confirmed open source scene and a strict profit oriented traditional software business on the other side

If a developer or engineer designs a piece of software or hardware, and decides to charge for their time and efforts, then they deserve to be compensated for their efforts. Every single time. No different to us providing a service, and expecting to be paid for our time and efforts. Why should the two be different?

The wonderful thing about freedom of choice, is that the user decides which software to install and then purchase, or which hardware to integrate in to the system. The developer has no control over that decision. This is basically a contract, the same as any, and as users we decide whether to enter in to that contract. People often forget that they have hit the continue button in the software installer past a page with a bunch of text (which few ever bother to read - read the iTunes license recently?) called the "Software License Agreement" which even states "Read this before installing this software".

especially in more advanced production facilities and high end project realization you will always find computer experts, technicians and developers, which have to solve difficile system integration tasks, finding solutions to optimize the actual workflow and develop very specialized in-house software to solve requiremenets, where no ready made solution is available on the market. that's a very interesting field somewhere in between those other more familiar opposite camps. their work has a lot in common with free software development resp. are often build upon developer tools and approaches derived from this field, but it also shows significant similarities to commercial software development, because it's costly part of production and the archived results often have to be kept secret as competitive edge over the competition.

With a background in broadcasting, within an organisation affected by international sanctions placed on the country, this was standard fare - in other words, innovating your way out of a problem.

The interesting thing is that, with ST2110, NMOS, Ravenna, and Node-RED, broadcasting remains a open source environment (with source available on GitHub). COTS hardware with open, and freely available code, is the new normal. The BBC, AMWA, EBU, Lawo, ARD ZDF, ARTE & ARTE+, et cetera, all contribute and place their code on GitHub.

Further, if you want to build a Netflix clone, the components are all available on GitHub available gratis and with a lenient license. But, it requires the user to configure everything and integrate the various components, build out the required AWS infrastructure, stomach the financial burden, and then produce the content to sell to users. To date, not a single user or organisation has taken the Netflix code and created a competing product and service. But, it's all there, allowing one to do just that.

when i have to judge about the openness and suitability of products for more advanced work, i usually examine to which degree they fit into this framework of requirements -- i.e. how much customized adaptation and workflow optimizations based on technical experts insight they allow. applications, which only try to satisfy typical end user demands, often turn out as very unsatisfactory in respect to this kind of indispensable requirements with regard to more advanced professional use.

Always on the look out for way to streamline the workflow and be more efficient, I would be interested in which open source and customisable solutions you have successfully integrated that rival Resolve or another closed source environment.

Take something like Reaper which (while being closed source, truly is an "anything can be anything" environment where video, audio, or MIDI, may live on a single track and be processed as a single entity if required, and which runs on any hardware even a Raspberry Pi, if that's your thing) offers a very flexible API with Lua scripting to expand the system to be what you want.

But Resolve solves the problems that even Reaper is currently unable to (and those of several other highly experienced engineers who are transitioning over). Plus, even in such a flexible environment as that which Reaper provides, not everyone has the required time or skill set to create a ton of Lua scripts in order to solve their problems and build the functions they require. They simply move on, and deliver something on time, and within budget, and hopefully to the satisfaction of the client. The client doesn't care how they got there.

but that's definitely no answer to the reasonable questions of the TO

I think it obviates the need to answer those question, though. H.264 is just not designed for editing. It will never edit as well as DNx or Cineform. It's a bad choice for shooting, it's a bad choice for editing.

The real issue is that camera makers use it despite it's being less than ideal for recording. Hence, proxies now and forever with H.264.

Having developed in a both "closed" hardware and software environments (UNIX variants, "Classic" Mac OS and OS X, and FPGAs with VHDL), as well as completely "open" environments (Linux variants), I don't regard completely "closed" environments disappointing at all. They are simply just another thing, a tool to satisfy and solve a problem.

yes -- i agree largely.
closed source software and interfaces are often much better/nicer documented, because that's a tedious job, and open source projects usually neither have the budget nor the man power to focus on this kind of perfection. but on the hand it's often much more useful to have direct access to the source code, if things do not work as expected resp. described in those nice written papers...

From experience (and the experience of others within the open source community), I can safely state that the majority of users lack the required skill set, to firstly determine the root of a bug, and secondly fix the associated bugs, but also do so without breaking something else completely. Or, have the required time to even begin learning how to begin to do so.

Less than 1% of users have ever taken the source, fixed bugs discovered in software, committed those changes to be rolled back to the community in subsequent releases. And, I would venture than even less than that can honestly confirm that they have.

that's somehow a generation problem. access and usability of open source solutions have changed a lot over time. when i started with linux in the early 90ths, it usually came as a couple of 3.5" (SLS or slackware) disks and you simply had to compile most applications yourself. that was a very useful practical training to become used in fixing little bugs and incompatibilities and increase your C and makefile knowledge. but this has changed in the meanwhile. i also became lazy and prefer the comfort to rest on the labour of other busy bees preparing debian packages.

nevertheless i'm still digging for bugs and suggest fixes occasionally, when i stumble over troubles concerning open source projects. it's usually nothing exciting, but just this minimal kind of active feedback and shared labor involvement, which i still see as an inevitable obligation for any average citizen of the open source world.

a remarkable difference concerning this marginal contribution and active feedback should be seen in the fact, that you are usually directly communicating with competent developers and interested colleagues on the other side. that's much more efficient and satisfaying than all those hierarchic communication filter chains and alienated role play as you'll usually find them on the commercial side. that's a point, where i can't agree with your description. engaged and charismatic developers can usually translate pretty awkward suggestions and imprecise bug reports in a very constructive manner with just a little bit of good will in most cases. that's in fact, what often distinguishes successful and exemplary managed open source projects from more shallow pro forma open core access.

but there is an interesting third realm between this confirmed open source scene and a strict profit oriented traditional software business on the other side

If a developer or engineer designs a piece of software or hardware, and decides to charge for their time and efforts, then they deserve to be compensated for their efforts. Every single time. No different to us providing a service, and expecting to be paid for our time and efforts. Why should the two be different?

well -- i definitely don't want to argue against any form of wage, which open source developers need and deserve like anyone else. but that's not the only kind of return, we have to consider, when we discus vital aspects of open source survival. if you look for example, how the big film industries made a lot of use from open source achievements, without giving much back in return to the wider community, it's an undoubtedly sign, that something runs wrong. emphasizing just the legitimate interests of individual developers, doesn't give an answer to this very important more comprehensive question. i really think, a kind of tax like regulation would be more suitable, to discipline those manufacturies, which only make profit on base of open source tools and software, but do not show any motivation to give back anything useful of commensurate value in return on a voluntary base. this obvious lack of fair play is really significant, otherwise we would have much better free video editing solutions on the linux platform right now.

Further, if you want to build a Netflix clone, the components are all available on GitHub available gratis and with a lenient license. But, it requires the user to configure everything and integrate the various components, build out the required AWS infrastructure, stomach the financial burden, and then produce the content to sell to users. To date, not a single user or organisation has taken the Netflix code and created a competing product and service. But, it's all there, allowing one to do just that.

for three decades i'm now working for academic and art related institutions, where this kind of large scale open source application is quite common. i therefore share your point of view concerning the real impact and possibilities of this kind of valuable software. but that's really a point of view, most other common computer users and contemporaries can not grasp. it's more a hidden world behind the curtains of more popular commercial software offers.

a sphere, which is not so much outstanding, because of free (in the sense of free beer) access, but of it's extraordinary freedom, to solve uncommon tasks and really innovative jobs in a quite different manner as it would be possible resting only upon closed source commercial solutions -- or that's at least, how i would describe it and explain my favor for this kind of tools.

Always on the look out for way to streamline the workflow and be more efficient, I would be interested in which open source and customisable solutions you have successfully integrated that rival Resolve or another closed source environment.

i think, natron is by far the most interesting free project in this respect right now. it's more or less the only really impressive free video processing solution, which allows accurate video processing on a quality level, which i would see as absolutely essential for serious work nowadays. what we are still missing, is a kind of timeline counterpart of the same quality level.

you could argue, that fusion, nuke, flame or mistika look much more powerful and suitable for professional work and are even available to some of us at quite attractive conditions, but i wouldn't agree. i definitely prefer the open source choice, wherever it represents a usable alternative and opens new perspectives. yes -- that's the price, you have to pay for progress in this filed: you can't just choose your tools in a utterly opportunistic and eclectic way. you also have to be consequent in your beliefs and accompany the progress of those more radical alternatives on their stony and tedious way to success.

Take something like Reaper which (while being closed source, truly is an "anything can be anything" environment where video, audio, or MIDI, may live on a single track and be processed as a single entity if required, and which runs on any hardware even a Raspberry Pi, if that's your thing) offers a very flexible API with Lua scripting to expand the system to be what you want.

yes, reaper is a nice software, and a really like the fact, that it's manufactures did a serious linux port of this software, just because of user request. that was a very uncommon move, which hardly has any other forerunner. but frankly i prefer paul davis ardour even more. and that's to some degree also caused by the fact, how much more it's author did for the linux community on the way to establish a very capable framework for audio applications on this platform. reaper is just a very nice DAW, but beside this really impressive port efforts, it didn't change so much for users on this operating system.

But Resolve solves the problems that even Reaper is currently unable to (and those of several other highly experienced engineers who are transitioning over). Plus, even in such a flexible environment as that which Reaper provides, not everyone has the required time or skill set to create a ton of Lua scripts in order to solve their problems and build the functions they require. They simply move on, and deliver something on time, and within budget, and hopefully to the satisfaction of the client. The client doesn't care how they got there.

sure -- this kind of troubles are not easy to solve, and i don't expect any miraculous sudden changes. but i really miss any sign of interest and endeavors on BMDs side, to make their tools more attractive and compatible to third party development and freedom of integration. that's a really a frustrating observation. if you compare the related capabilities in resolve to the possibilities in nuke studio or attempts like mistika-hyperspeed, you'll immediately see, that something is absent. even the plugin development support of adobe products (and that's really not the most exemplary open source friendly company) outclass resolve.

as i told you before, i really like to use natron a lot, and calling this tool straight from resolves timeline would be much more useful to me than many other superficial improvements, which resolve got recently. using my preferred file readers and writers would be a similar important requirement. this are things, which could be realized quite easily from a technical point of view, but are somehow completely unthinkable within the fences of closed source commercial software.

sure -- i also try to find a reasonable balance of practical interests and do not want to fall into the traps of dogmatism, but we simply have to face this kind of limitations and drawbacks as well, if we want to strive for really satisfaying solutions in the long run. for those of us, which are only interested, if software comes for a few bucks/bugs more or less, this maybe seen as pure rubbish, but for others it's the crucial point, why an actual solution can't be accepted as sufficient suitable to our needs.

[sorry -- that's again completely off topic -- but it's an interesting topic... nevertheless i don't want to disturb the original discussion, because the introductory question was not less important and worthwhile to ask for! ]

[sorry -- that's again completely off topic -- but it's an interesting topic... nevertheless i don't want to disturb the discussion, because the original question was not less important and worthwhile to ask for! ]

Thank you for the reply Martin (and the link). It is an interesting discussion.

I apologise for my part in taking this off topic, and in drying out everyones eyeballs.

In some other Universe, Blackmagic has paid a lot to Cockos to integrate REAPER in the audio page instead of Fairlight. I'm in the wrong Universe again... At least in this Universe I am in, REAPER exists In another Universe, Davinci Resolve has tons of actions like REAPER, and custom actions, and scriptable actions

I think H264 acceleration should be the same in the free version.

edit:
ok the confusion is in the change log:

• Support for hardware accelerated H.264 decoding when using NVIDIA GPUs on Linux and Windows

Doesn't mention is only studio version.. so I guess it sohuld be in the free version too.

and then:

Improved decode performance of 10-bit 4K H.264 media on DaVinci Resolve Studio

it mentions it is only in Studio version. But only for 10 bit H264 files I guess.

The first statement doesn't clarify if no MacOS acceleration at all or on AMD (there are very few Macs with a capable Nvidia card these days).

Many replies (which are rather guessing) and no clarification from BM.
Is it something which BM doesn't want to comment?

I found it funny after a drop price of 66% users still complain that [put feature here] must be free because [put silly reason here]......

I found it funny after a drop price of 66% users still complain that [put feature here] must be free because [put silly reason here]......

I think the complaining is about the lack of clarity in what is the difference in the Studio version, so I can know if I want to purchase it or not.
H264 decoding acceleration is going to be used mostly by people that maybe don't need the more professional features of Studio version. Professional users won't be probably using H264 footage in the first place.

I found it funny after a drop price of 66% users still complain that [put feature here] must be free because [put silly reason here]......

I think the complaining is about the lack of clarity in what is the difference in the Studio version, so I can know if I want to purchase it or not.
H264 decoding acceleration is going to be used mostly by people that maybe don't need the more professional features of Studio version. Professional users won't be probably using H264 footage in the first place.

300$... that is less than the drone used to make the images......

Please.....

[Rohit Gupta]

We are seeing more and more questions recently about performance (or the lack thereof) with H.264 footage on different hardware. While 'transcode!" used to be the usual mantra, some are reporting excellent performance with version 14 even in 4K. But the picture is blurred and the configuration guide doesn't deliver a clear answer.

So, I'd like to ask the knowledgeable folks at BM to give us some guidelines, in particular for those who'd like to assemble their own configuration for Windows or Linux. My questions would be:

– Is it correct that there is no acceleration by dedicated hardware in the free version?
(Please, no bashing here, dear colleagues, this might be a licensing issue which BM doesn't want to pay for)

– Is it correct that an up-to-date, CUDA capable Nvidia card will always take over if present?

– Which unit is taking over if there is an AMD GPU only, specific CPUs or no acceleration at all?

– Which CPUs are taken advantage of for hardware acceleration?

– What's the situation with Apple's turnkey systems, given that they all have GPUs by AMD?

– What are the limits of H.264 formats supported in hardware, given the wide range of possible features?
(I know we could look up the latter, but maybe it's easy to tell for BM's engineers)

I'm sure not to be the only one who'd be grateful for a complete answer and it can only serve decisions of others to go for the Studio version, so TIA, Blackmagic.

Hardware decode acceleration for h264 8-bit is supported on the following platform:

1. macOS on last 3-4 years Macbook, Macbook Pro and iMac (both free and Studio version)
2. Windows with capable NVIDIA GPU with 3GB RAM or more (Studio version only)

Also, h264 decode performance on Windows is much better with the Studio version, for example, you’ll see better random access and editing performance.

Also, 10-bit h264 and h265 etc is only supported for decode on the Studio version.

and what's about 4:2:2 h.264 support? ...because the nvida acceleration does not support this kind of color subsampling and win10 also doesn't want to play/decompress this kind of footage utilizing its system provided codecs?

[but thanks for the general clarification!]

@ Martin Schitter:
Studio version: GH5 10 BITS 422 / Windows 10 X64 PRO: no problem as BMD supports media type in studio version (and NVIDIA is out of context, meaning that we do not count at 100% on NVIDIA but maybe ?). Or did I misunderstand your question?

@ Martin Schitter:
Studio version: GH5 10 BITS 422 / Windows 10 X64 PRO: no problem...

if resolve studio on windows is using the nvidia hardware acceleration on windows, as Rohit Guptas explanations suggest, some [presumable slower] fall back mechanism has to be used for this kind of footage, because nvdec hardware acceleration doesn't support it:

Hardware decode acceleration for h264 8-bit is supported on the following platform:

1. macOS on last 3-4 years Macbook, Macbook Pro and iMac (both free and Studio version)
2. Windows with capable NVIDIA GPU with 3GB RAM or more (Studio version only)

Also, h264 decode performance on Windows is much better with the Studio version, for example, you’ll see better random access and editing performance.

Also, 10-bit h264 and h265 etc is only supported for decode on the Studio version.

Thanks Rohit for the additional information.

If hardware acceleration is supported on those Macs which have AMD GPUs, is it possible and does BMD have plans to enable hardware acceleration for AMD GPUs in Windows?
I specifically bought my AMD 280X GPU to run FCPX under MAC OS (dual boot), but now have decided to use DVR 14 & Windows 10.

Maybe they needed to program that for the CPU, since AMD cards might not offer acceleration or not enough of it? And no current Apple machine has an Nividia GPU. So, reading between the lines, I suppose they had to program it all for the CPU for MacOS.

If Nvidia is only accelerating 4:2:0, I don"t care too much about 10 or 12 bit. So, I can fully understand why BM is charging for 10 bit 4:2:2 formats in H.264.

I'm grateful we got some answers, Rohit.

I'm quite impressed by the performance of Resolve Studio 14 on my new iMac with the 580 Radeon Pro, BTW.

@ Martin Schitter:
Studio version: GH5 10 BITS 422 / Windows 10 X64 PRO: no problem...

if resolve studio on windows is using the nvidia hardware acceleration on windows, as Rohit Guptas explanations suggest, some [presumable slower] fall back mechanism has to be used for this kind of footage, because nvdec hardware acceleration doesn't support it:

422 is not natively supported: It does not mean it's impossible. This is certainly where BMD comes in.

I can see H.264 UHD to run very smoothly on FHD timeline, even with my limited power machine (i3-7350k + GTX970)

however, my better machine (dual xeon X5690 + GTX1080Ti), when running HEVC 5K on FHD timeline, it runs at 5fps, CPU is at 30%, GPU is at 15%

is it the CPU or any other part limiting the decoding? can I expect smooth playback with an even more powerful machine?

I just did a test with a HEVC UHD on a UHD timeline. It's a clip at 24fps.

I changed the playback frame rate to 60 fps and it's OK. The only thing: it's in an MP4.

Code: Select all

Général
Nom complet                              : K:\_Shots_Shots\H265\BigBuckBunny_2000hevc.mp4
Format                                   : MPEG-4
Profil du format                         : Base Media
Identifiant du codec                     : iso4 (iso4/hvc1)
Taille du fichier                        : 2,40 Mio
Durée                                    : 10s 0 ms
Débit global moyen                       : 2 013 kb/s
Date d'encodage                          : UTC 2014-08-25 21:13:56
Date de marquage                         : UTC 2014-08-25 21:13:56

Vidéo
ID                                       : 1
Format                                   : HEVC
Format/Info                              : High Efficiency Video Coding
Profil du format                         : Main@L6@Main
Identifiant du codec                     : hvc1
Identifiant du codec/Info                : High Efficiency Video Coding
Durée                                    : 10s 0 ms
Débit                                    : 2 010 kb/s
Débit maximum                            : 3 061 kb/s
Largeur                                  : 3 840 pixels
Hauteur                                  : 2 160 pixels
Format à l'écran                         : 16/9
Type d'images/s                          : Constant
Images par seconde                       : 24,000 Im/s
Espace de couleurs                       : YUV
Sous-échantillonnage de la chrominance   : 4:2:0
Profondeur des couleurs                  : 8 bits
Bits/(Pixel*Image)                       : 0.010
Taille du flux                           : 2,40 Mio (100%)
Titre                                    : hevc:fps=24@GPAC0.5.1-DEV-rev4807
Bibliothèque utilisée                    : x265 1.3+20-6e6756f94b27:[Windows][MSVC 1700][64 bit]
Paramètres d'encodage                    : wpp / ctu=64 / tu-intra-depth=3 / tu-inter-depth=3 / me=3 / subme=4 / merange=57 / rect / amp / max-merge=4 / no-early-skip / no-fast-cbf / rdpenalty=0 / no-tskip / no-tskip-fast / strong-intra-smoothing / no-lossless / no-cu-lossless / no-constrained-intra / no-fast-intra / open-gop / interlace=0 / keyint=250 / min-keyint=24 / scenecut=40 / rc-lookahead=40 / bframes=8 / bframe-bias=0 / b-adapt=2 / ref=5 / weightp / no-weightb / aq-mode=2 / aq-strength=1.00 / cbqpoffs=0 / crqpoffs=0 / rd=6 / psy-rd=0.50 / psy-rdoq=0.80 / signhide / lft / sao / sao-lcu-bounds=0 / sao-lcu-opt=1 / b-pyramid / cutree / rc=2 / pass / bitrate=2000 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ipratio=1.40 / pbratio=1.30
Date d'encodage                          : UTC 2014-08-25 21:13:56
Date de marquage                         : UTC 2014-08-25 21:14:00


UHD_HEVC.jpg

I can see H.264 UHD to run very smoothly on FHD timeline, even with my limited power machine (i3-7350k + GTX970)

however, my better machine (dual xeon X5690 + GTX1080Ti), when running HEVC 5K on FHD timeline, it runs at 5fps, CPU is at 30%, GPU is at 15%

is it the CPU or any other part limiting the decoding? can I expect smooth playback with an even more powerful machine?

How much and what type speed/channels of RAM do you have, and how much is free, and what's your I/O sitting at?

however, my better machine (dual xeon X5690 + GTX1080Ti), when running HEVC 5K on FHD timeline, it runs at 5fps, CPU is at 30%, GPU is at 15%

that's the next problem!

hardware acceleration solutions usually support only a clear defined maximal resolution:



in the case of a 1080ti card, 5k HEVC should work, but 5K h.264 definitely wouldn't be handled by the nvdec acceleration mechanism. (in the case of intels quick sync it's even more limited and changing with any new iGPU generation)

@ Martin Schitter:
Studio version: GH5 10 BITS 422 / Windows 10 X64 PRO: no problem...

if resolve studio on windows is using the nvidia hardware acceleration on windows, as Rohit Guptas explanations suggest, some [presumable slower] fall back mechanism has to be used for this kind of footage, because nvdec hardware acceleration doesn't support it:

422 is not natively supported: It does not mean it's impossible. This is certainly where BMD comes in.

Nothing what BM can do for hardware acceleration. It's fixed by GPU chip/Nvidia driver so BM can't expand this by its own coding. It's not part of main GPU where you can write own code in CUDA or OpenCL. Decoding is done by separate dedicated chip which power and features are rather limited/fixed and fully controlled by Nvidia.
BM can only use good/optimised CPU decoder.

in the case of a 1080ti card, 5k HEVC should work, but 5K h.264 definitely wouldn't be handled by the nvdec acceleration mechanism. (in the case of intels quick sync it's even more limited and changing with any new iGPU generation)

Can we even be sure that hardware acceleration is not fixed at certain standard resolutions? Like 4K or 8K, but no 5K? I didn't even find a list yet that shows which bit depths or color subsampling are supported by Intel's QuickSync. I'd suppose that Resolve is using QuickSync on iMacs and MBPs, which is also making FCP-X so fast on otherwise limited hardware.

I have only used standard sizes like HD and UHD with GOP formats until now and I'm impressed with Resolve 14 on my 2017 iMac. 5K in R3D is a different chapter, but that's only CPU anyway and you can always reduce resolution there.

Maybe they needed to program that for the CPU, since AMD cards might not offer acceleration or not enough of it? And no current Apple machine has an Nividia GPU. So, reading between the lines, I suppose they had to program it all for the CPU for MacOS.

If Nvidia is only accelerating 4:2:0, I don"t care too much about 10 or 12 bit. So, I can fully understand why BM is charging for 10 bit 4:2:2 formats in H.264.

I'm grateful we got some answers, Rohit.

I'm quite impressed by the performance of Resolve Studio 14 on my new iMac with the 580 Radeon Pro, BTW.

I don't see how they could "program that for the CPU". According to Rohit, hardware acceleration is enabled on all recent MACs, so it has to be done by the AMD GPU. I would like to see that appear in Windows as well, although I suspect Apple provided the APIs to get the hardware assisted encoding/decoding and the application developer does not need to program directly for one or another GPU platform.

I'm not sure if they don't resort to Intel's QuickSync on the Mac.

...Given the nature of H.264, I wouldn't hesitate to recommend the same for any NLE.

Precisely. We still consider H264/5 as Acquisition codecs only to be always transcoded with user set Timecode and Reel #s for painless future Conforms. As a dedicated and long time Lightworks Pro editor, I cannot see myself editing in Resolve any time soon. Whilst DaVinci has steadily developed remarkable features under BMD's control, for the foreseeable future we will continue to bring fine tuned, timecode based EDLs and AAFs into Resolve for CC and Export to high quality DPX Image Sequence Masters.

So, did a few tests of my own with a shiny new iMac with Radeon Pro 580.

Encodes of H.264 with standard settings are exactly the same, both in the free and the Studio version, slightly faster than realtime (8 minutes for 10 minutes of footage). As soon as I switch to "Multiple", both are getting much slower, like 32 minutes for the same footage. Can't tell which part is working harder, both CPU and GPU get considerably hotter.

Regarding import, the restrictions on some advanced formats in H.264 and all H.265 apply, these are only read by DR Studio. The 10 bit formats out of the GH5 and the H.265 out of a Samsung are overwhelming this machine, they don't play smoothly. In these cases there's obviously no hardware acceleration, since all four CPU cores struggle close to 100%. With all H.264 in UHD 8 bit, which is playing and scrubbing smoothly, I can see far less load on the CPUs. Whatever I throw at it in HD, including XAVC 10 bit 422 from a Sony Z150, is playing smoothly without challenging the CPU.

BTW, VP9 encoding doesn't work at all.

422 is not natively supported: It does not mean it's impossible. This is certainly where BMD comes in.

Nothing what BM can do for hardware acceleration. It's fixed by GPU chip/Nvidia driver so BM can't expand this by its own coding. It's not part of main GPU where you can write own code in CUDA or OpenCL. Decoding is done by separate dedicated chip which power and features are rather limited/fixed and fully controlled by Nvidia.
BM can only use good/optimised CPU decoder.

(Geforce Forum)
Which GPUs support HEVC (a.k.a. H.265)

https://forums.geforce.com/default/topi ... 7/#5036767

decoding start : Feature Set F
Introduced dedicated HEVC Main (8-bit) & Main 10 (10-bit) and VP9 hardware decoding video decoding up to 4096 × 2304 pixels resolution.
GeForce GTX 750 SE, GTX 950, GTX 960

Feature Set G
Introduced dedicated hardware video decoding of HEVC Main 12 (12-bit) up to 4096 × 2304 pixels resolution.

Feature Set H are capable of hardware-accelerated decoding of 8192x8192 (8k resolution) H.265/HEVC video streams
GeForce GTX 1070, GTX 1080, GeForce GTX 1060, NVIDIA TITAN XP, GeForce GTX 1050, GTX 1050 Ti

Thank you for commenting.

The 10 bit formats out of the GH5 and the H.265 out of a Samsung are overwhelming this machine, they don't play smoothly.

right, that's what I am trying to work on, the GH5 6k photo is running HEVC 5K resolution at 200Mbps

How much and what type speed/channels of RAM do you have, and how much is free, and what's your I/O sitting at?

72GB of DDR3 1333 ECC RAM installed (8Gb X 9 I think this is the maximum for Dell T5500)
the media files are placing in a Plextor M8Pey 512GB NVme SSD

the SSD is not running anything near 10%.
plenty of free RAM still showing

422 is not natively supported: It does not mean it's impossible. This is certainly where BMD comes in.

Nothing what BM can do for hardware acceleration. It's fixed by GPU chip/Nvidia driver so BM can't expand this by its own coding. It's not part of main GPU where you can write own code in CUDA or OpenCL. Decoding is done by separate dedicated chip which power and features are rather limited/fixed and fully controlled by Nvidia.
BM can only use good/optimised CPU decoder.

(Geforce Forum)
Which GPUs support HEVC (a.k.a. H.265)

https://forums.geforce.com/default/topi ... 7/#5036767

decoding start : Feature Set F
Introduced dedicated HEVC Main (8-bit) & Main 10 (10-bit) and VP9 hardware decoding video decoding up to 4096 × 2304 pixels resolution.
GeForce GTX 750 SE, GTX 950, GTX 960

Feature Set G
Introduced dedicated hardware video decoding of HEVC Main 12 (12-bit) up to 4096 × 2304 pixels resolution.

Feature Set H are capable of hardware-accelerated decoding of 8192x8192 (8k resolution) H.265/HEVC video streams
GeForce GTX 1070, GTX 1080, GeForce GTX 1060, NVIDIA TITAN XP, GeForce GTX 1050, GTX 1050 Ti

Thank you for commenting.

What' point exactly are you trying to make? Every thing Andrew said, and you quoted from another forum are correct.

https://developer.nvidia.com/nvidia-video-codec-sdk

for h.264 you are limited to 8 bit 4K. it will only decode 4:2:0, and will only encode 4:2:0 or 4:4:4.
for h.265 you are limited to 12 bit 8K. it will only decode 4:2:0, and will only encode 4:2:0 or 4:4:4.

BMD can't magically work around this issue. If they don't use the dedicated encode/decode api & hardware, they have to fall back on the general computational apis, namely CUDA & OpenCl. that doesn't run on dedicated hardware, and isn't optimized for working with video streams/files/footage.

How much and what type speed/channels of RAM do you have, and how much is free, and what's your I/O sitting at?

72GB of DDR3 1333 ECC RAM installed (8Gb X 9 I think this is the maximum for Dell T5500)
the media files are placing in a Plextor M8Pey 512GB NVme SSD

the SSD is not running anything near 10%.
plenty of free RAM still showing

This should be fine, thus my assumption without sitting in front of your machine and running a bunch of diagnostics, is that the cpu is bottlenecking on the hvec decode (as it is a lot more computationally expensive).

BMD never said anything about offloading hvec/h.265 duties to the gpu, just h.264. so I bet your low power machine is leveraging the gpu, and your high power one isn't.

What' point exactly are you trying to make?
...
BMD can't magically work around this issue. If they don't use the dedicated encode/decode api & hardware, they have to fall back on the general computational apis, ....

i think, it's very important for users to understand why the performance for a particular file format may not look as satisfying as in other cases.

nobody here is asking for any miraculous workarounds by [black]magic! it's just this basic comprehension, to understand what's really going on within this black[magic] box, which should be seen as justified by practical interest affecting all active users of this application.

What' point exactly are you trying to make? Every thing Andrew said, and you quoted from another forum are correct.

https://developer.nvidia.com/nvidia-video-codec-sdk

for h.264 you are limited to 8 bit 4K. it will only decode 4:2:0, and will only encode 4:2:0 or 4:4:4.
for h.265 you are limited to 12 bit 8K. it will only decode 4:2:0, and will only encode 4:2:0 or 4:4:4.

BMD can't magically work around this issue. If they don't use the dedicated encode/decode api & hardware, they have to fall back on the general computational apis, namely CUDA & OpenCl. that doesn't run on dedicated hardware, and isn't optimized for working with video streams/files/footage.

Exactly.
Problem goes further because heavily parallelisation which is a key feature of GPU with CUDA or OpenCL is not going to work well with h264/h265 decoding. Those processes can't be split into 100s or 1000s of threads which means GPUs are not good for writing h264/h265 decoders/encoders. For very this reason GPUs now have dedicated chip which is purely there for codecs decoding/encoding tasks.

I understand that some users complain that there are differences in results depending on whether it is with a studio version or not.

Now, you say that CUDA does not know how to do things: but if you pay: CUDA or other things do a lot of things.
I do not have a very powerful machine: already one year .. it goes very fast but I do not complain. So ?

(and concerning the programming in GPU: It is quite astonishing what one happens to make ..). It is not a public poster that limits the perimeter. Are you registered with NVIDIA developers?

But whether BMD or other: do you believe that an editor will deliver you its manufacturing secrets? Seriously.

But whether BMD or other: do you believe that an editor will deliver you its manufacturing secrets? Seriously.

i don't think, there is so much serious secret or intellectual property involved. nobody sane will develop it's own codecs from scratch these days. they all use/license ready made blocks to build upon. and there are not so many alternatives available.

it's just very unsatisfying for the actual end users of applications, if they are forced to guess which kind of codecs are used in fact by their software, just by indirect reasoning and stumbling over characteristic bugs, which reveal all available implementations sooner or later.

I understand that some users complain that there are differences in results depending on whether it is with a studio version or not.

Now, you say that CUDA does not know how to do things: but if you pay: CUDA or other things do a lot of things.
I do not have a very powerful machine: already one year .. it goes very fast but I do not complain. So ?

(and concerning the programming in GPU: It is quite astonishing what one happens to make ..). It is not a public poster that limits the perimeter. Are you registered with NVIDIA developers?

But whether BMD or other: do you believe that an editor will deliver you its manufacturing secrets? Seriously.

Nothing to do with secrets.
It's all about nature of processes. GPU (over CUDA or OpenCL) loves process which can be heavily parallelised due to its 1000s processing units. If you have process which can be split into many subprocesses then GPU is your friend. Problem is that h264/h265 decoding can't be heavily parallelised, so writing decoder on CUDA or OpenCL is difficult and at the end it won't be very fast anyway. This is the reason why GPUs have today special units just for this, which are not part of main processing engine.

This is also reason why things like blur effect are not so fast on GPU. They also can't be heavily parallelised, where things like brightness adjustment can be split into even e.g. pixel/per GPU thread (as they are totally independent). You can't for example decode h264 stream per pixel due to its complexity and architecture.

There are codecs which are made for GPUs from the ground:
https://www.daniel2.com
but these are rather intermediate codecs with low complexity. Problem is that this will eat main GPU processing power, so Resolve will have less to use.