Really disappointed with HEVC

Musicvid wrote on 7/29/2019, 9:00 AM

I've never been a fan of hardware encoding, going back to my earliest impressions of CUDA. Now that I've been blessed with a modestly spiffy home machine, I've been doing a lot of testing of lightweight renderers for quick HD proofs (dailies) to throw up on the home media server for preview, as well as proxies, prerenders, rough cuts, and the like. It's the way I learned to work.

I really, really promised myself to give HEVC, and Intel QuickSync in general, a chance. Boy, have I been disappointed. I mean, 900% realtime renders at lower bitrates are tempting, even to retired warriors. However, this on-cpu stuff, next to x265/x264, which take longer to render, is simply horrid. That's a technical term.

So, my takeaway is that if I am going to use hardware encoders, it will be at much higher bitrates, which eat up time and size savings. What goes around comes around.

[Spoiler Alert] Quantified tests coming soon, to a thread near you!

Comments

Kinvermark wrote on 7/29/2019, 9:24 AM

+1. I look at it as "horses for courses." For best quality go slow with x264/5 cpu render. For other purposes perhaps QSV is good enough. I think I remember reading somewhere that QSV is not at the same quality standard as NVENC and VCE.

mikelinton wrote on 7/29/2019, 9:40 AM

@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).

j-v wrote on 7/29/2019, 9:41 AM

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.

met vriendelijke groet
Jan

Camera : Pan X900, GoPro Hero7 Hero Black, Samsung Galaxy A8
Desktop :MB Gigabyte Z390M, W10, i7 7900 4.7Ghz,16 DDR4 GB RAM, Gef. GTX 1660 Ti.
Laptop  :Asus ROG GL753VD, W10 home, version 1903 build 18.362,295 CPU i7 7700HQ, 16 GB RAM, GeF. GTX 1050 (2 GB) + Int. HD Graphics 630(2GB).VP 15,16,17 and VMS PL 15,16 are installed
Both Nvidia GPU's have driver version 431.86 Studio Drivers
TV      :LG 4K 55EG960V

Dutch video tutorials for beginners

My slogan is: BE OR BECOME A STEMCELL DONOR !!!

Kinvermark wrote on 7/29/2019, 9:53 AM

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.

 

Musicvid wrote on 7/29/2019, 9:59 AM

... 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.

 

mikelinton wrote on 7/29/2019, 10:05 AM

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.

Musicvid wrote on 7/29/2019, 12:01 PM

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, ....

JN_ wrote on 7/29/2019, 12:29 PM

 

Desktop and Laptop basic specs ...

Both run Win 10, has latest updates ...

Running latest ver. of Vegas Pro with latest updates.

VP13 B453 also.

Vegaseur and Pluraleyes installed on both ...

Quicktime 7.79.80.95

PC ...

i9 9900K, Intel Graphics 630. Nov 2018.

Mem. 32gb DDR4

Graphics card .. Nvidia Rtx 2080 Ti

Nvidia Graphics driver .. latest Studio driver.

Latest Intel Graphics driver

 

Laptop ... (Acer Predator G9-793-77AC)

CPU .. i7-6700HQ Skylake-H

Memory ..16GB DDR4 

Graphics card .. Nvidia GTX 1070, latest Studio driver.

fifonik wrote on 7/29/2019, 5:41 PM

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...

Camcorder: Panasonic X920

Desktop: MB: MSI B350M PRO-VDH, CPU: AMD Ryzen 1600, RAM: G'Skill 16 GB DDR4 2400, Graphics card: MSI RX470 4GB, SSD: Samsung 850 EVO SATA 250MB, HDDs: Seagate & Toshiba 2TB, OS: Windows 10 64-bit 1809

NLE: Vegas Pro 11, 12, 13, 15

bob-h wrote on 7/29/2019, 7:47 PM

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.

Barton-Santello wrote on 7/30/2019, 12:23 PM

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.

Uwe-Erbrich wrote on 8/1/2019, 2:03 PM

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.
 

Uwe-Erbrich wrote on 8/1/2019, 2:04 PM

Uwe-Erbrich wrote on 8/1/2019, 2:49 PM

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!
fifonik wrote on 8/1/2019, 3:48 PM

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.

Last changed by fifonik on 8/1/2019, 8:02 PM, changed a total of 6 times.

Camcorder: Panasonic X920

Desktop: MB: MSI B350M PRO-VDH, CPU: AMD Ryzen 1600, RAM: G'Skill 16 GB DDR4 2400, Graphics card: MSI RX470 4GB, SSD: Samsung 850 EVO SATA 250MB, HDDs: Seagate & Toshiba 2TB, OS: Windows 10 64-bit 1809

NLE: Vegas Pro 11, 12, 13, 15

Musicvid wrote on 8/1/2019, 8:24 PM

@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/

Uwe-Erbrich wrote on 8/2/2019, 6:40 AM

@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!

 

Uwe-Erbrich wrote on 8/2/2019, 7:19 AM

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.

Uwe-Erbrich wrote on 8/2/2019, 7:34 AM

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.

Uwe-Erbrich wrote on 8/2/2019, 8:28 AM

@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.

 

Musicvid wrote on 8/2/2019, 9:13 AM

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

vkmast wrote on 8/2/2019, 9:20 AM

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

Uwe-Erbrich wrote on 8/2/2019, 3:14 PM

Will do!

Musicvid wrote on 8/18/2019, 9:26 AM

Back to topic, I found a setting to make QSV h264 look "better," although still not entirely to my liking. If I set the CQ comparatively low, like 14, the overall bitrate approaches that of good x264, and the veil of softness is lifted. Somewhat, if my eyes aren't fooling me.

Still, the temptation of fast machine encoding remains, and maybe the next generation of hardware encoders will bring more accurate imaging. Or maybe not...