H265 Optimize for Speed checkbox

Hello everyone,

Page 3902 of the current DR18 manual - Rendering media
"Quality: If the currently selected option in the Render to drop-down menu has options for changing the compression quality, this drop-down menu lets you choose the quality you want to use. Otherwise, it’s disabled."

When rendering H265 there's an additional checkbox - optimize for speed. Can't find it mentioned in the manual. Is it for playback/streaming speed or for rendering speed, I'm assuming the former.
Either way, it's not clear to me if there would be a noticable visual quality impact.

Anyone dug into this?

If final deliverable is for YT, does it make any difference?
Thanks.

Can you show us? (Screen grab)

Sure, thanks for replying so quickly Jim.

Never seen that before. Show the whole video tab. Maybe it only shows up under specific choices.

This is on a Mac Studio. Haven't tried it on my PC yet to see if it's any different there.

Must be a Mac thing. Not sure I can help.

Sorry.

No worries. Thanks for your time.

If I have time I'll render some test files out to see what difference it makes, if any.

V18 added a lot of new options on the delivery tab for Mpeg4 export. I haven't seen this in V17, so I assume it was added recently.

Apparently BM has been consistent to their commitment of lack of documentation.

My assumption it would be equivalent to the x265 fast decode?

https://x265.readthedocs.io/en/master/presets.html

Fast Decode

--tune fastdecode disables encoder features which tend to be bottlenecks for the decoder. It is intended for use with 4K content at high bitrates which can cause decoders to struggle. It disables both HEVC loop filters, which tend to be process bottlenecks:

--no-deblock
--no-sao

It disables weighted prediction, which tend to be bandwidth bottlenecks:

--no-weightp
--no-weightb

And it disables intra blocks in B frames with --no-b-intra since intra predicted blocks cause serial dependencies in the decoder.

'Web Optimized' Fast start, Is a thing in handbrake.

https://handbrake.fr/docs/en/latest/adv ... mised.html

If you are encoding for the web and using the MP4 file format, you’ll want to turn on “Web Optimised” checkbox. This places the MP4 container header at the start of the file, optimizing it for streaming across the web.

This is often referred to as MP4 “Fast Start”.

Apparently BM has been consistent to their commitment of lack of documentation.

I'm glad to see it isn't only me that feels that way

Thanks Zeb, I think you could be right about the fast decode equivalent.

It makes me wonder what impact it has on the Youtube encoder, if any.
I could try to render two large files, one with the speed checked and the other without, and see if there is a noticable difference in YT processing time of the file, but I'm guessing there are a lot of other variables at play that affect the processing time - so it might be a pointless exercise.

Either way the file gets re-encoded so my guess is that if uploading to YT or Vimeo you can leave it unchecked.

As for the manual... well it's 4000+ pages, so I wouldn't say that's a total lack of commitment
Then again, that's why this forum is great.
Thanks for the links.

As for the manual... well it's 4000+ pages, so I wouldn't say that's a total lack of commitment
Then again, that's why this forum is great.
Thanks for the links.

It clearly needs to be 4050 pages then so they have documentation for the h264/265 functionality.


Lack of documentation is a symptom of poor software engineering. When you see 'Airport had 36 hr outage from Windows 95 software' the reason they are still running windows 95 software is the guy who wrote it back in the day did not document how it works, so no one can re-write it.


You would never see a feature added to something like SSL without documentation, the engineer would get laughed out of the room. In reality you write a lot of the documentation before you write any of the code.

Strange that we accept this for so many 'Professional' tools.

Interesting point.

Future manuals will undoubtedly have some ChatGPT style involvement.
Not sure if that helps the developers or makes them less scrupulous.

I have no idea what's involved on BM's side of development, but I'm guessing it's a lot.

As for the 'Pro' tag. That's been mislabled on plenty of software and tools for the last decade or so; usually until professionals complain enough to bring back useful feature sets and fix old bugs. I think this is the result of the prosumer market. Different discussion...

In reality you write a lot of the documentation before you write any of the code.

Strange that we accept this for so many 'Professional' tools.

I'm sure BM software engineers document their work.
Manuals for public consumption (PDFs for download for example) are often written by a separate team from engineering - professional manual writers. This is where things are usually "lost in translation".

I recently rendered a project of mine with the checkbox unchecked, and that resulted in poor playback over the network (I use the Infuse app to play files from my PC to my Apple TV). Rendering with the box checked created a file that played without hiccups.

Have had some funny stuff with rendering h265 this far though. For some reason, one time, my project rendered in a few minutes, but the file size was smaller, and I could see some compression that I did not see on the more normal, 1 hour+ rendering sessions... Not sure what happened there..

(a 20 minute short, pre-rendered (ProResHQ), with 5.1 audio)

Thanks for the info Johan.

I still haven't been able to run any conclusive tests with regards to Youtube uploads but it looks like the checkbox is for situations such as the one that you describe; playing over a network.

Not sure what is causing those h265 irregularities.

You would never see a feature added to something like SSL without documentation, the engineer would get laughed out of the room.

SSL (I'm assuming you mean "Secure Sockets Layer") is a specification, not a piece of software. It is, by definition, nothing but documentation.

In the scope of desktop computer applications Resolve has a pretty vast UI. I'm impressed that it's as well documented as it is. Omissions are inevitable, IMHO the best we can hope for is that they get plugged when we point them out.

Omissions are inevitable, IMHO the best we can hope for is that they get plugged when we point them out.

6 months, nothing

viewtopic.php?f=21&t=166300

You would never see a feature added to something like SSL without documentation, the engineer would get laughed out of the room.

SSL (I'm assuming you mean "Secure Sockets Layer") is a specification, not a piece of software. .

True, i should have said OpenSSL that is the actual code everyone uses.

https://github.com/openssl/openssl

Did anyone figure out an answer to this?

My guess would be 'Optimize for speed' uses encoder settings which lower the output quality in favour of improving render speed. But that's purely a guess.

It used to be the option in other encoders forced hardware only encoding to improve speed at expense of quality, but there is another option in the settings to use/not use hardware encoding so I guess thats not it!


I don't think it's the same as optimising for web, I think the "Network Optimization" setting is for that as I'm assuming that the network optimization setting puts the MooV atom (i.e. the index of the video) at the beginning of the rendered file instead of at the end (same as the ffmpeg faststart option) so that seeking through the file is quicker as the client has that index information as soon as it begins to open the file.

I found this in an article on 9to5mac, which appears to be referencing the release notes of v17.3:

Along with the new all-new engine, DaVinci Resolve 17.3 supports M1 Macs to use H.265 hardware encoding with the ability to optimize for speed or quality

and

DaVinci Resolve 17.3 also supports a new option on Mac computers with M1 for H.265 hardware encoding. Customers can choose to prioritize speed vs quality when rendering, further improving render times up to 65%.

My guess is that this is referring to the "Optimize for speed" option in the Export Video Quality settings when H.265 is the codec, although the text doesn’t quite specify that checkbox directly.

I still don't see any documentation of this option in the August 2024 reference manual for Resolve 19, although I want to add that I don't generally have a problem with Blackmagic's documentation. It's usually pretty thorough.

Feature is rather self explanatory.
You either encode faster or with better quality.
It has no direct correlation to x265. HW and x265 are quite different encoders.

HW encoders are very fast so I would rather stick to "better quality".

Feature is rather self explanatory.
You either encode faster or with better quality.
It has no direct correlation to x265. HW and x265 are quite different encoders.

It's not self-explanatory at all. Without documentation, "speed" could be referring to anything from how quickly the video starts playing to how quickly it downloads. Given the information I found, I believe it is referring to how quickly it renders, although I haven't had a chance to run any scientific tests. But even if that is the case, does "Optimize for speed" improve rendering time across the board? Or is it an optimization for specific source codecs, or for other specific attributes of the video, e.g. color, compression artifacts, audio? Does it only apply to Apple Silicon? How does checking this box differ from simply lowering the bit rate? Does it impact file size? And perhaps most importantly, how much IQ degradation can be expected, if any, and in what circumstances?

And lastly, it's absolutely correlated to h.265/HEVC. That may be the only thing that is actually self-explanatory, since the option doesn't appear for other codecs.

I think it's notable that the option is checked by default. So one would expect that if there is a loss of quality, it is negligible, but obviously the option to disable it exists for a reason.

Feature is rather self explanatory.
You either encode faster or with better quality.
It has no direct correlation to x265. HW and x265 are quite different encoders.

Correct.

HW encoders are very fast so I would rather stick to "better quality".

But, throwing a bit more bitrate at it makes the quality all equal again.

And lastly, it's absolutely correlated to h.265/HEVC. That may be the only thing that is actually self-explanatory, since the option doesn't appear for other codecs.

H.264 HW encoders have the same type of shortcomings as H.265 HW encoders.

By the way H.264 and H.265 are encoding standards (their options are determined by their levels), x.264 and x.265 are particular software implementations of those standards.

AI tells me the following

The "H265 Optimize for Speed" checkbox in DaVinci Resolve's Deliver page is designed to enhance the rendering speed of H.265 (HEVC) video exports. When this option is enabled, the software prioritizes faster processing over maximum video quality, which can be particularly beneficial for quick outputs or when working with limited hardware resources.
Advantages

Faster Rendering Times: Enabling this option significantly reduces the time required to export videos, making it ideal for projects with tight deadlines or when quick previews are needed.
Efficiency in Resource Usage: This setting can be advantageous for users with less powerful hardware, as it allows for smoother operation during the rendering process without overwhelming the system.
Suitable for Streaming: If the final output is intended for platforms like YouTube, the speed optimization can be beneficial, as it allows for quicker uploads without a noticeable drop in quality for most viewers

.

Disadvantages

Potential Quality Loss: The primary trade-off for faster rendering is the possibility of reduced visual quality. The optimization may lead to lower bitrates and less efficient compression, which can affect the final output's clarity, especially in scenes with high detail or motion.

Less Control Over Compression Settings: Users may have less flexibility in adjusting compression settings when this option is enabled, which could limit the ability to fine-tune the output for specific needs.

In summary, the "H265 Optimize for Speed" checkbox is useful for achieving quicker exports at the potential cost of visual quality, making it a practical choice for certain workflows, particularly in fast-paced environments.

So based on the above knowledge, I use it mostly when sending proofs for approval to the client or when outputting for Instagram reels.

When I need to output for final Youtube videos I disable it on my M2 Mac to get the best quality (but longer rendering times)

So based on the above knowledge, I use it mostly when sending proofs for approval to the client or when outputting for Instagram reels.

When I need to output for final Youtube videos I disable it on my M2 Mac to get the best quality (but longer rendering times)

Increasing the bitrate compensates for the lower quality that comes from using speed-optimized encoding, as it allows more data to reduce compression artifacts. Optimized encoding is only important when file size is limited, such as when content must fit on fixed-size media, like DVDs and Blu-rays in the past. In addition for fixed-size media, a two-pass encoding is even better as it can maximize the available size.

In short, don't worry about speed-optimized encoding, just throw some extra bitrate at it.

HW encoders are very fast so I would rather stick to "better quality".

But, throwing a bit more bitrate at it makes the quality all equal again.

If you can yes, but sometimes bigger file is not an option.

What is the actual speed difference on Mac for this 2 options?
How much do you save for eg. 1h source?

In my tests you save about one third, like cutting down from one hour to around 40 minutes.

Just tested a 4 mimute short film, rendering out as HD h265 to test both the slower and faster ways: the slower render produced a file that is about 1% larger. I do not discern any visible quality difference (viewing files on an Eizo CG2700x). Has anyone tested to compare for any discernable quality difference with 4K material and a 4K output, and was there any discernible quality difference in the slower and faster rendered outputs in a 4K render?