i had some very good results with totalcode HEVC encodings.

MPC now have HEVC decoder built-in, so makes very easy to reproduce.

I also came across this:

https://x265.github.io/

but haven't tried it yet

With x265 it can take a week to encode a 3 hour program, which is about five times faster than a year ago.
So my answer is "not yet."

I encoded a video as H.265 using a 3rd party app (this was before I had purchased VP 13) and found it got really superior compression results, far better than H.264. Then I was unable to find a decoder that could properly display the video. One produced only audio and a single frame of the video, another couldn't decode it all. That was including MPC.

Render time was really slow compared to H.264 and the decoding (for what is was) pushed the CPU usage really high.

Not an authoritative experiment but enough to convince me to wait a while before trying to use H.265 any further.

http://www.divx.com/en/software/technologies/hevc

I find it kind of curious that recording bitrates don't seem to change that much over the years. When I began this avocation in 2000 I shot in DV, which ran at 25Mb/sec. Then went to HDV, which kept the same bitrate. And AVCHD shoots at about the same rate. In each instance the quality has increased but the bitrate has held steady.

As for processor power, I remember that doing DV meant being sure the PC and its hard drive could keep up (!). Then HDV was an issue because of the leap in processor power needed, followed by AVCHD and another significant jump in required power.

So it is fitting that the latest codec will tax current systems but will no doubt be a breeze on new hardware two years from now!

What has fascinated me all these years is that the number of bits needed to build an image keeps dropping. Makes me wonder what the limit is, for surely there is a limit. I suspect 265 is getting pretty close.

The latest version of FFMPEG does a good job of encoding h265. FFPlay to playback. On a gen1 i7, I see about 3-10 fps on conversion from XDCAM-ex to HD h265.

I just tried a test frameserving from Vegas to ffmpeg using the x265 encoder option. I got 20-25% realtime of a 30p source, so around 6fps. 4Ghz 4770k CPU (quad core).

ffmpeg -threads 0 -i server.avs -c:v libx265 -preset fast -crf 28 -x265-params me=umh -colorspace bt709 -color_primaries bt709 -color_trc bt709 -pix_fmt yuv420p -c:a libmp3lame -qscale:a 2 -chunk_size 64K output.mp4

That's not bad at all; seems to have come a long way in the past year.
How much do encoding times increase if you set crf=18 or crf=20 ?

The encoding times do not really change. I tried 23 and 20. crf only affects the different quant factors applied to I/P/B frame(s) respectively so I would not expect any change. crf does not change any encoding parameters like the diff between preset fast and preset medium.

With the frame serving it is hard to use the Vegas render dialog timer since I have to do some clicking on the frameserver dialog and the click/run my script. All encodes were within a few seconds of each other and the very tiny test encode as around 37 seconds. But watching the frameserver % real-time output and the ffmpeg fps console output they are close enough to not care.

The difference between preset fast and preset medium is seat of your pants noticeable.

crf 18 and 20 are values people using the the x264 world. I have normally used 25. x265 docs state that their default crf 28 is roughly equivalent to an x264 default crf of 23. I've made no visual comparisons to test that but I so no reason for false claims.

I suppose one can have each output SSIM and use the default preset medium on each and then tweak the crf of one to get the SSIM values to be very close. That might be how x265 makes their crf 28 approx equivalent claim across a sample of source inputs.

Yes, I've already surmised that there wasn't (much of) any effort to correlate scale values between the two encoders.

Which begs the question: if you set the x265 CRF in the 32-36 range, do render times decrease noticeably?
I know using a frameserver is not the best way to test this.