@Musicvid keep in mind HEVC is a new codec standard regardless of how you are rendering it, it yields superior image quality for comparable file sizes to H264. That said, it also requires a lot more overhead to decode, so it's definitely not for every situation (yet).

I wrote here ( under another username) last year that NVENC to AVC or HEVC encoding in the lowe bitrates is far better than the QSV option, that I never will use for encoding.
A lot of artifarcts in renders with the same settings compared to NVENC and when the development team of Vegas wrote here that there is a lot of communication between them and the developpers of NVidia my suspicion about quality grew more and more.

it yields superior image quality for comparable file sizes to H264

I prefer to look at it the other way around: same image quality, but smaller files. That's not marketing "sexy" though. :)

@mikelinton There are a few variables here though... Encoding method (hardware vs software) as well as the benefit (or not) at different bitrates. Low bitrates seem to benefit more from h265.

... it yields superior image quality for comparable file sizes to H264.

No, it claims to yield equal quality at lower file sizes; that's a big difference in thinking. What I'm finding out is yeah, I can render them three or four times smaller, but can I bear to watch them?

It's not h265 technology I'm blaming, although interframe compression may be nearing the end of its usefulness; it is hardware encoder production, which just isn't there yet afaiac.

All I was saying is, let's not throw HEVC under the bus because NEVC's hardware encoding does a piss poor job. :) HEVC in and of itself, is a very good codec and provides many advantages over H264 (smaller file sizes, 10bit color, 4:4:4 colour space in version 2, 4K etc.) Anyway, I haven't played with any of the hardware accelerated codecs, we just use the good ol' tried and true let the CPU chug it out.

Low bitrates seem to benefit more from h265.

Or perhaps, suck less?

I swear, this "little movies" trend hasn't come very far since the original h263 Divx era.

Note to self: OK now, one more time. Size, Quality, Speed, ....

Topic is a bit misleading.

HEVC is fine.

The HW encoding implementations are sucks (for 265 & 264).

BTW, in my tests NV was the best in terms of quality with the similar bitrate from NV/QSV/VCE. Not as good as CPU...

You would typically want to double the bitrate when hardware encoding, except with very low bitrates where doubling may not be enough to appear similar to the software equivalent. If you have the bandwidth available and you're uploading it somewhere for re-encode then that may work for you. If you are encoding the version that your viewer will see on the internet (no re-encode) then hardware is not good enough as efficiency is most important, you want your bitrate as low as possible especially if you know many viewers will be using mobile devices

I am pretty sure that people know hardware encoding is a compromise. For best results use cpu.

What if you have a GPU that has HEVC encoding "built-in" like NVIDIA's Quadro P2000? I have Magix's Video Pro X and if I check 'Hardware Encoding' when rendering, I either get an encoding failure or the rendering slows to a crawl so painful, I end up cancelling the render.

In order to assess the viability of software/hardware HEVC, I used a quantitative approach similar like JN_. I focused completely on UHD though and compared XAVC-I, XAVC-S, Magix AVC and Magix HEVC for descending Mb/s, whereby I largely used the same "intervals" as suggested by the default render templates.

Assuming as a newcomer to this forum that these results may be of of potential interest, I will include a table of the results.

I used the Happy Otter Scripts (HOS) tool "Render Quality Metrics" https://tools4vegas.com/render-quality-metrics-2/ from W. Waag to evaluate Mean squared error (MSE) and Peak Signal Noise Ratio (PSNR, see also Wikipedia for some mathematical background).

My system: Gigabyte Aero 15 Laptop, CPU: Intel i7-8750H, GPU: NVIDIA GTX 1070 with Max Q

I used a movie sequence of one of my movies, which can be made available on request. The reference sequence is a XAVC-I render called 1. generation.

I will upload the table in the next step.
 

The following conclusions may have some merits:

1. XAVC-S delivers the best quality within the 8 bit AVC flavors in the 135Mb/s range closely followed by Mainconcept VBR.
2. The inclusion of 2 further reference frames has much less effect at high Bit rates (example Main Concept 135 Mb/s) than at low ones (50 Mb/s, probably not unexpected).
3. The increase of "slices" in the Main Concept renders does not result in an increase of quality, but in a decrease.
4. Mainconcept VBR results in the best Mainconcept quality. "2 pass renders" lead surprisingly to a decrease in quality. Altogether the default Render templates make sense!
5. Happy Otter Script x264 CPU renders are very close in quality to 4 reference frames Main Concept VBR renders. Magix AVC Main Concept renders should therefore be considered as equivalent to x264 as per this evaluation.
6. Intel QSV (Encode 7) is the best hardware renderer for Magix AVC, not very far away from Main Concept. For HEVC NVIDIA renders provide better Quality than Intel QSV.
7. Comments very welcome!

1. ... Magix AVC Main Concept renders should therefore be considered as equivalent to x264 as per this evaluation

It is possible that with your source (I do not see any details) and your bitrate that can be true while you comparing single-number metrics.

However, in general, I absolutely does not agree with the claim.

In my tests, Mainconcept AVC/Magix AVC gives much worse quality on the same bitrate than x264. Sources, results, project and explanation how metrics were build provided there.

Some other people noticed similar quality issues with their sources/workflow.

P.S. Something wrong with your numbers. Mainconcept VBR with final avg bitrate 52.1 gives you file size 0.377 GB while Mainconcept VBR with final avg bitrate 29.2 gives file size 0.431 GB. This is mathematically impossible for the same source. If sources were different (the only way lower bitrate can gives bigger file), you cannot compare metrics.

P.P.S. It is not correct to compare VBR (Mainconcept) vs CBR (x264). Encoder with CBR cannot increase bitrate for more complicated frames and decrease it for simple frames that lead to worse overall quality. You should compare them in the similar conditions (all VBR or all CBR). Note, even in the unfair conditions x264 won in resulting size and quality (MSE) based by numbers you provided.

@Uwe-Erbrich

I don't know where you dropped in from, but your testing protocol and data presentation are excellent and most welcome!

There are several variables and common templates left out of your first round so I would regard any conclusions as being tentative, contingent on including more data sets in subsequent testing (e.g., x264 CRF, minimum bitrate considerations for local encoders, etc.)

It should be noted that for PSNR (shadow noise), higher is better, and anything over 30dB should be fine for digital source. For the MSE scale, lower is better, with 0 being a perfect match [corrected]. Even my tired old eyes consistently see a difference above MSE 4.0.

Since MSE (actually RMS Regression, remember Algebra II?) is not perceptually weighted, I ran a round of software intermediate tests using the MSU SSIM freebie, but it is a hassle because one needs to crop to 640x480 for comparison. Also, I'm sure you know their annual encoder shootouts are regarded world-wide. https://www.compression.ru/video/

@fifonik

"It is possible that with your source (I do not see any details) and your bitrate that can be true while you comparing single-number metrics.

However, in general, I absolutely does not agree with the claim.

In my tests, Mainconcept AVC/Magix AVC gives much worse quality on the same bitrate than x264. Sources, results, project and explanation how metrics were build provided there.

Some other people noticed similar quality issues with their sources/workflow."

I have looked at the examples you provided in the forum and I too can see the difference, when looking at your material on my TV. As far as the root cause is concerned, it is difficult from my perspective to conclude from the distance whether it is rooted in a set-up issue of your computer/Vegas Software (too many variables), or whether it is due to the averaging process of the PSNR/MSE algorithm (e.g. high drop of minimal bitrate), which can of course not be excluded. Because I was aware of your results, I chose a sequence (altogether 3715 frames) including dark / shady pics (dark clothes) and I did not see any difference (which is not a proof either of course).

If I upload some darker pics of this sequence: Would you be willing to look at them and provide me with your opinion (as I am travelling tomorrow to Mexico this may be delayed for a few days)?

I still see value in aligning objective measurement results with subjective quality evaluations, as the eye can only be trusted to an extent (my opinion).

Provided that we are looking at the same sequence for the original and rendered file I have given preference to the PSNR / MSE measurement due to the following reasons:

1. Availability of a simple tool from W. Waag
2. A comparatively simple algebra allowing relatively easy evaluation of the results in a closed algebraic form (I will extend on that a bit later).
3. An over proportional emphasis on high errors (!) due to the squared MSE term. This should counteract to some extent a potential tendency to hide issues through the averaging process.

In this context it might be interesting to evaluate your problematic sequences through W. Waag´s tool, which is of course much simpler than the tools you have applied.

The metrics you provided were very impressive by the way as was your whole test package!

P.S. Something wrong with your numbers. Mainconcept VBR with final avg bitrate 52.1 gives you file size 0.377 GB while Mainconcept VBR with final avg bitrate 29.2 gives file size 0.431 GB. This is mathematically impossible for the same source. If sources were different (the only way lower bitrate can gives bigger file), you cannot compare metrics.

Many thanks for the alert to this error! Seems I am becoming old! You are absolutely right. I will correct in the original post based on the raw data as still available.

P.P.S. It is not correct to compare VBR (Mainconcept) vs CBR (x264). Encoder with CBR cannot increase bitrate for more complicated frames and decrease it for simple frames that lead to worse overall quality. You should compare them in the similar conditions (all VBR or all CBR). Note, even in the unfair conditions x264 won in resulting size and quality (MSE) based by numbers you provided.

This is probably a misunderstanding. The abbreviation abr (not cbr as for constant bit rate) as per the Happy Otter Script means "average bit rate" for x264. I should have explained that better.

@Musicvid

"I don't know where you dropped in from..."

Thanks for your interest! Glad to introduce myself.

I am a German physical chemist, with ongoing interest in private/semiprofessional documentaries and science. Since I have dropped Super 8 film for HD (as only then I could see an equivalence in quality) I have worked with Vegas PRO (starting with version 9) and follow the twists and turns of the Vegas forum, where I learned a lot!!

This is my first active contribution to this forum (I am retired meanwhile, so I have a bit more time).

I am looking forward to continue learning a lot from you.

"There are several variables and common templates left out of your first round so I would regard any conclusions as being tentative, contingent on including more data sets in subsequent testing (e.g., x264 CRF, minimum bitrate considerations for local encoders, etc.)"

Absolutely! I just decided to start somewhere and use the input then for further data collection, if considered value added.

"For the MSE scale, lower is better, with 1 being a perfect match"

This is probably a typing error. As per the formula MSE=0 and not 1 for a perfect match. The corresponding PSNR is therefore undetermined in this case as division through 0 is forbidden.

Well by all means keep testing! It must be your scholarly background, but your semantic cadence has a familiar ring.

@Uwe-Erbrich welcome to this forum. As @Musicvid already said, please keep contributing.

Will do!