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