H.264 Multi Pass Encoding... WHERE IS IT?

Mine is: encoder : Lavc58.18.100 libvpx-vp9

and whatever you do it's at least 3x slower than x265.
Both are actually slow and in quite many cases (when you not trying to do 10Mbit UHD file) x264 is still best choice for quality/encoding time ratio.

... x264 is still best choice for quality/encoding time ratio.

I think there is also a third factor and that is bitrate.

Generally speaking the higher the bitrate the less the 'finesse' of the compression method actually matters. For instance, for very low bandwidth situations H.265 can do miracles compared to H.264 but on the other hand, for very high bandwidth situations the savings may not even be worth it.

I think there is also a third factor and that is bitrate.

Generally speaking the higher the bitrate the less the 'finesse' of the compression method actually matters. For instance, for very low bandwidth situations H.265 can do miracles compared to H.264 but on the other hand, for very high bandwidth situations the savings may not even be worth it.

I think this is correct. I don't expect to move away from H.264 for a long time, maybe when AV1 is mature and implemented everywhere. The only situation we ever use ultra low bandwidth is for automatic generation of low-res proxies for web playback on our media asset management system. H.264 deliveries are otherwise usually 20-40Mb/s for us.

... x264 is still best choice for quality/encoding time ratio.

I think there is also a third factor and that is bitrate.

Generally speaking the higher the bitrate the less the 'finesse' of the compression method actually matters. For instance, for very low bandwidth situations H.265 can do miracles compared to H.264 but on the other hand, for very high bandwidth situations the savings may not even be worth it.

Yes, that's why you should quote whole sentence:

"Both are actually slow and in quite many cases (when you not trying to do 10Mbit UHD file) x264 is still best choice for quality/encoding time ratio."

not cutting some part of it and changing meaning of my comment.

For instance, for very low bandwidth situations H.265 can do miracles compared to H.264 but on the other hand, for very high bandwidth situations the savings may not even be worth it.

even in cases, where bandwidth isn't the most important criteria, it's still a much better solution to export 10bit deliveries resp. all kinds of HDR content in a more compatible manner. because 10bit h.264 is really bad supported in real world.

but i'm personally quite often working on diverse video streaming solutions and self hosted video delivery, where efficient bandwidth utilization and adaptive delivery techniques are still a very important requirement in practice. just because some of us may have perfect network connectivity at their work spaces, this doesn't hold true for ordinary consumers, mobile devices etc...

... x264 is still best choice for quality/encoding time ratio.

I think there is also a third factor and that is bitrate.

Generally speaking the higher the bitrate the less the 'finesse' of the compression method actually matters. For instance, for very low bandwidth situations H.265 can do miracles compared to H.264 but on the other hand, for very high bandwidth situations the savings may not even be worth it.

Yes, that's why you should quote whole sentence:

"Both are actually slow and in quite many cases (when you not trying to do 10Mbit UHD file) x264 is still best choice for quality/encoding time ratio."

not cutting some part of it and changing meaning of my comment.

Oh, I am so sorry, I overlooked that. I apologize!

Slightly off topic - we all know HEVC (H.265) takes a lot more computing power to encode than AVC and that software encoding generally produces better quality than hardware. How do digital cameras work? eg New tiny Hasselblad on Mavic drone has a 1" sensor plus UHD H.265 10 bit or a GH5 with 4K HEVC 4:2:2.
Assume they use some type of hardware encoder chip as they don't have space for an 8 core Ryzen

Yes, they use ASIC chips which are made specifically for encoding task. Similar to ones which are in GPUs.

Thanks Andrew - found some more info on ASICs. Given the popularity of AVC/HEVC could ASIC hardware encoding/decoding be a PC solution for NLEs to improve speed (realtime) and reduce CPU load - and the need for 4K proxy editing plus fast render?
Found one that claims H.264/265 4K 4:2:2 10 bit 60p encoding and decoding (better than Intel Quicksync specs).
https://www.socionext.com/en/products/assp/h264h265/MB86M30/

Thanks Andrew - found some more info on ASICs. Given the popularity of AVC/HEVC could ASIC hardware encoding/decoding be a PC solution for NLEs to improve speed (realtime) and reduce CPU load - and the need for 4K proxy editing plus fast render?
Found one that claims H.264/265 4K 4:2:2 10 bit 60p encoding and decoding (better than Intel Quicksync specs).
... (URL Redacted) ...

This is already very common. The consumer NLE market uses QSV, for example, heavily to achieve this.

I think pro NLEs like Edius Pro, Video Pro X, and others also do this. I have used VPX, and scrubbing/playing H.264 on the timeline was like using Optimized Media in Resolve. IIRC, it uses Intel QSV for this. I assume Edius Pro does similar (but am not sure). It is well-known for its speed, I've heard.