Maybe, I get over 5:1 in simple 1080p H.264 to H.265 transcode with same bitrate in PD18 so not sure you are seeing anything great at ~4.5:1. For at least a comparison, run the same in PD18 with only your GTX1050 with GPU doing both encode and decode since simple transcoding and post what you get for encode duration to similar specifics as HandBrake.

Jeff

Good to know.

I would run your test, but am still waiting for CL to patch the problem where my iGPU is blocking me from using my nVidia. (What appears to be a Display Enumeration problem, as Optodata discovered.)

But if sufficiently motivated, I can disable the iGPU in my BIOS and run your test.

Quote
But if sufficiently motivated, I can disable the iGPU in my BIOS and run your test.

Is that a laptop or a desktop?
If is a laptop, there are just a few that can do that, equiped with a hardware mux switch between the chipsets. The rest rely on cheaper Optimus.

Quote Is that a laptop or a desktop? If is a laptop, there are just a few that can do that, equiped with a hardware mux switch between the chipsets. The rest rely on cheaper Optimus.

His desktop, he outlined the issue here: http://forum.cyberlink.com/forum/posts/list/81933.page#337628 Yes, he has control in BIOS as referenced prior, just needs to adjust and repeat when sufficiently motivated.

Jeff

So, Jeff, a dumb question:

I converted a 1080p H.264 to HEVC using PD. I accepted the default profile for 1080p HEVC. (Since, when I use Profile Analyzer, it always wants to "convert" to H.264, and doesn't give me any advice on HEVC settings.)

The original video has a BW of 30,000 Mb/S. The PD default profile for HEVC is 11,000.

I did the conversion and the new video is noticably blockier than the original.

So I thought, 'Okay, I'll set the BW for the HEVC to 30.,000."

I did the conversion again, and, to my surprise, the file size of the H.265 is exactly the same as the H.264!

I thought that HEVC was supposed to deliver approx half the file size for the same quality/BW video?

Am I doing something wrong? Or not understanding?

When I did the same conversion using HandBrake, it too lowered the BW of the converted video - lower, to 9,000. The file size was about a third of the original, and the video looks good to me. I notice that HandBrake presets a "comb" filter for the conversion. Whereas PD doesn't. Could that be the difference?

(Can discuss PM if you want.)

Quote So, Jeff, a dumb question:

I converted a 1080p H.264 to HEVC using PD. I accepted the default profile for 1080p HEVC. (Since, when I use Profile Analyzer, it always wants to "convert" to H.264, and doesn't give me any advice on HEVC settings.)

The original video has a BW of 30,000 Mb/S. The PD default profile for HEVC is 11,000.

I did the conversion and the new video is noticably blockier than the original.

So I thought, 'Okay, I'll set the BW for the HEVC to 30.,000."

I did the conversion again, and, to my surprise, the file size of the H.265 is exactly the same as the H.264!

I thought that HEVC was supposed to deliver approx half the file size for the same quality/BW video?

Am I doing something wrong? Or not understanding?

When I did the same conversion using HandBrake, it too lowered the BW of the converted video - lower, to 9,000. The file size was about a third of the original, and the video looks good to me. I notice that HandBrake presets a "comb" filter for the conversion. Whereas PD doesn't. Could that be the difference?

(Can discuss PM if you want.)

You said nothing about the relative performance of the two comparisons for your example of what is possible hardware wise.

I simply think not understanding, when one defines 30Mbps you are essentially define the file size. Be it H.264, H.265, 2K, 4K or 1080, they will ALL have the same files size if in fact the encoder held that bitrate throughout the video. You've defined for the encoder that you want 30Mbps, or 3.75MB of file size for each second of video in your timeline. So yes, when you select H.265 or H.264 to use 30Mbps, of course the file size should be the same, that's what you asked for, 30Mbps. Many encoders use varible bitrate though, like PD, so they try to maintain the request on average, but if your video is lacking motion scenes and has say a slide show, the encoder bitrate will fall way off as one does not need the higher bitrate to capture that static scene.

What H.265 brings with that encoding technology is the same quality at a lower bitrate. So a 30Mbps 1920x1080 H.264 will only need maybe 20Mbps for the same quality, which will be a smaller file, 20/30 ratio smaller. That's why when you look at PD defaults for say a very basic 1920x1080/30p MP4 it lists 16Mbps for H.264 and 11Mbps for H.265. CL simply trying to help the average user get a constant quality file so they reduce the H.265 bitrate because it's a better encoder. Or, one can think of it in reverse, if I use the same bitrate since storage is cheap, I get a better picture quality for the same storage cost. One downside of H.265 is it's very computationally intensive to both encode and decode. That's why most that play in the H.265 arena like a good hardware encoder as it's much, much, faster than CPU based encoding for hardware $'s.

That's why I indicated when you do the comparison, make sure your produced file is like for like as far as quality as measured by bitrate as the work the encoder needs to do is dependent on that.

Jeff

Thanks. Now that you explained it from a math viewpoint, it does sound like a "Duh" moment on my part.

I suppose I'll have to get a feel for what a good BW is for HEVC encodes.

I'll have to do some more comparisons, but it seems that the HEVC done by the Intel GPU is fuzzier than the HEVC done by nVidia.

Oh, BTW, I did the HEVC conversion test with the GTX-1650 Super. Like you, I got a 5.6:1 ratio of time to encode to length of video.

Here's a screenshot from TaskManager.

As a fun note, see the usage of the disk drives? Everyone that claims that you need fast SSD drives for video editing should look at that graph.
The same goes with the RAM memory usage. It will go up a bit is using multiple files at 4k, but will still be fairly low.

Quote BTW, I did the HEVC conversion test with the GTX-1650 Super. Like you, I got a 5.6:1 ratio of time to encode to length of video.

So as was originally guessed, this example of what is possible hardware utilization wise was really not what it was cracked up to be. You are now getting better encode performance with less system load, sounds like a win win deal but often true on simple transcode as your test. Keep the decode and encode on the same device typically lowers CPU duty, RAM duty and alternate decode device duty.

Yes, quality is from the device and what internal settings are being used by PD in communication with the device API. So one has to compare quality from CPU encode, iGPU encode, GPU encode for your workstream and see what overall is good for you. What is good for H.264, not necessarily good for H.265.

Jeff