Jump to content

h.265 vs h.264 discussion

bobhays

Hi everyone, I saw the h.265 option in hanbrake while converting an mkv video. I converted the same video using h.264 and h.265 to test it out.

 

The h.264 conversion took the file size from 9.6GB to 4.8GB.

The h.265 conversion took the file size from 9.8GB to 4.3GB

 

Some quick math 4.3/4.8 shows that the h.265 file was 90% of the size of h.264

BUT it took 3 times as long to encode (3hrs vs 1hr) and takes twice the cpu utilization during playback (10% vs 5%)

 

After comparing the two I have to question whether the benefits of h.265 are worth the consequences.

I know that this was just one video but if h.265 is going to be the new standard I believe it should either make the video smaller or take less processing power.

 

As far as quality is concerned, both were close enough that I couldn't tell which one was playing in a "blind" test.

Link to comment
Share on other sites

Link to post
Share on other sites

it aims for Video Call and Instant messaging. main interest for the codec was delivering same if not higher quality on low resolution

diminishing returns for each codec hasn't been progressing so far as I know since DivX and WMV9 in comparison in  term file size decrease at higher resolution.

h264 doesn't do much either, it just lighter whereas older codec had issues when it need to be played/stream on low power machine (it could be your phone, tablet, computer, watch, fridge, anything).

 

actually I haven't heard anything since 3 years ago after I saw the news on TPB front page.

we can blame ISP data cap for this (or slow internet)

 

I mean we have blue ray since like what? 12 years ago? with single layer it can contain more than 40GB data, capping our monthly use for 10/30/300 GB/month is definitely not a joke.

Link to comment
Share on other sites

Link to post
Share on other sites

it aims for Video Call and Instant messaging. main interest for the codec was delivering same if not higher quality on low resolution

diminishing returns for each codec hasn't been progressing so far as I know since DivX and WMV9 in comparison in  term file size decrease at higher resolution.

h264 doesn't do much either, it just lighter whereas older codec had issues when it need to be played/stream on low power machine (it could be your phone, tablet, computer, watch, fridge, anything).

 

actually I haven't heard anything since 3 years ago after I saw the news on TPB front page.

we can blame ISP data cap for this (or slow internet)

 

I mean we have blue ray since like what? 12 years ago? with single layer it can contain more than 40GB data, capping our monthly use for 10/30/300 GB/month is definitely not a joke.

If it's meant for video and ims for mobile devices I feel like h.264 is still better. Unless other results are much better than mine because mobile processors are not very powerful. Encoding for 3 times as long and decoding at twice the usage would use more power and kill battery life. All just so that it uses a bit less data.

 

Also single layer blu-rays are 25 gb, dual is 50 (but most are dual anyways)

Link to comment
Share on other sites

Link to post
Share on other sites

ofcourse it's better, because almost all current hardware today already have h264/mp4 hardware acceleration including mobile chipset.

that's the influence of industry support.

 

Eversince h264 replacing xvid on youtube everything progressing faster, but still not fast enough since we still have to deal with adobe flash for most part.

 

h265 doesn't have any of that as for now (or there is?i really dont know)

About blu ray capacity yeah,but you get my point.

Link to comment
Share on other sites

Link to post
Share on other sites

If it's meant for video and ims for mobile devices I feel like h.264 is still better. Unless other results are much better than mine because mobile processors are not very powerful. Encoding for 3 times as long and decoding at twice the usage would use more power and kill battery life. All just so that it uses a bit less data.

 

Also single layer blu-rays are 25 gb, dual is 50 (but most are dual anyways)

 

Its meant for delivering content to mobile devices; not producing it on mobile devices... because a lot of countires (UK included) have crappy 3G/4G connections (Unless you are on 3 where you get no data limit) but the speed still sucks...

Link to comment
Share on other sites

Link to post
Share on other sites

I still prefer HVEC, and WebM.

Link to comment
Share on other sites

Link to post
Share on other sites

I still prefer HVEC, and WebM.

HVEC is h.265 but I haven't tried V9
Link to comment
Share on other sites

Link to post
Share on other sites

Its meant for delivering content to mobile devices; not producing it on mobile devices... because a lot of countires (UK included) have crappy 3G/4G connections (Unless you are on 3 where you get no data limit) but the speed still sucks...

I get that but what I'm saying is it also takes 2x the power to decode/playback the video,but that might get solved with more ubiquitous hardware decoders.

Still a pain to encode in h.265 though

Link to comment
Share on other sites

Link to post
Share on other sites

ofcourse it's better, because almost all current hardware today already have h264/mp4 hardware acceleration including mobile chipset.

that's the influence of industry support.

 

Eversince h264 replacing xvid on youtube everything progressing faster, but still not fast enough since we still have to deal with adobe flash for most part.

 

h265 doesn't have any of that as for now (or there is?i really dont know)

About blu ray capacity yeah,but you get my point.

IIRC YouTube doesn't use Flash anymore. It uses VC-1 iirc and HTML5. And it runs like crap! At least on Google Chrome, can't talk about other browsers though.

Check out my guide on how to scan cover art here!

Local asshole and 6th generation console enthusiast.

Link to comment
Share on other sites

Link to post
Share on other sites

HVEC is h.265 but I haven't tried V9

I know, But I still like it more, even it it takes more power to encode.

 

and WebM files are only about 256 mb for about 5 min @ 1600 * 900 24 fps. (SSR Simple Screen Recorder)

Link to comment
Share on other sites

Link to post
Share on other sites

Here's a lot of confusion going on

Link to comment
Share on other sites

Link to post
Share on other sites

I get that but what I'm saying is it also takes 2x the power to decode/playback the video,but that might get solved with more ubiquitous hardware decoders.

Still a pain to encode in h.265 though

 

Because bandwidth costs the suppliers money - They dont give a fuck about your CPU usage/battery life...

Link to comment
Share on other sites

Link to post
Share on other sites

IIRC YouTube doesn't use Flash anymore. It uses VC-1 iirc and HTML5. And it runs like crap! At least on Google Chrome, can't talk about other browsers though.

 

It depends on the hardware and software you're running. Performance varies significantly depending on the configuration.

 

VP9 playback can slow down machines at high resolutions and/or frame rates (especially since most do not have hardware VP9 decode).

Link to comment
Share on other sites

Link to post
Share on other sites

IIRC YouTube doesn't use Flash anymore. It uses VC-1 iirc and HTML5. And it runs like crap! At least on Google Chrome, can't talk about other browsers though.

it's not the browser, browser actually have nothing to do with playback

everything is streamed with 3rd party, and most of time it use flash for the player,browser just a layer for that player, again it doesn't matter what content was being streamed.

even ads still rely heavily on flash, that's why we are stuck with it for so long.

The reason why it's not showing on chrome base browser it because they have independent build flash to decode instead using flash from OS system, if you play it using other browser it will use plugin-container.exe which is flash player no matter what, if you playing multimedia within your browser.

 

that's the problem with everything actually, HTML5 while it has lot's of feature and benefits that doesn't mean easier to adapt

since I'm not content creator or programmer or any of that digital producer I can't say that for 100%, just search "HTML5 is hard".or "why HTML5 still can't overtake flash"

most of results that I get even already more than 5 years old, and we still haven't moving on that far.

 

 

Here's a lot of confusion going on

in the end, it's all about market decision

 

once big company start rolling with more implementation in their application/or hardware it will mature and we will get benefit

that's all it's about, licensing cost money and all these codecs require that.

 

same thing like divx, wmv, xvid, x264.mp3, ogg, aac, or any codec for that matter.

 

xvid was in grey area because it has same based with divx, and they had the license for the base.

 

and divx was actually competing with youtube long time ago, and once youtube decide to leave divx completely they've gone bankrupt.

they have their own website before, it was my first source to get 1080p HD quality video (not upscaled)

 

ofcourse these information that I had in my head is quite outdated

I've completely ignored all the news since 5 years ago.

 

Today we have all power and resources, it all depends which one these companies decide what next to become their upcoming feature.

 

it's all connected though

codec matter a lot because it could make storage more efficient

and to solve "infrastructure problem" that we actually don't have to suffer if all these ISP just upgrade their network so we get more speed/bandwith.

and the last one how much power that our devices need to make it available for everyone, everywhere not just exclusive to certain platform (ex: computer only), because that's definitely not good for business especially with these all exposure we could already see literally on tip of our finger.

 

Please feel free to correct me.

Link to comment
Share on other sites

Link to post
Share on other sites

You didn't compare the same file twice, so your comparison is void, if you're gonna test variation between two codecs, you ought to do it with the same sample file, but that's not quite the point.

h265 is harder to decode and encode now because most hardware doesn't natively support it, most decoders in GPUs only support h264 and other older codecs so of course it used more CPU time during playback, and h265 is only in the same situation that h264 was in just a few years ago.

h264 used to take forever compared to mpeg4, but now with hardware and software support h264 is nearly as fast as mpeg4, and the same is true of h265, it'll take longer now but once the support is in place it should be just as fast if not faster than h264.

I'll get handbrake installed and run some encode tests and see what the numbers give, also remember that the advantage of h265 is not really speed, it's compression and the resulting file sizes, h265 allows for a file about half the size of h264 for the same quality, and that's the important part, which if you only compare similar settings for h264 vs. h265, h264 wins nearly every time, but start compressing h264 more and more and watch as the quality tanks, whereas h265 holds the same quality but at greater compression ratios.

Edit:

This is my results for h264 vs h265. CAUTION LARGE IMAGES! YOU HAVE BEEN WARNED!

The same sample video was used every time, the original video is a 1minute 36 second video recording of Sonic the Hedgehog 2 at 1920x1080p resolution and is a h264 file with a CQ value of 16 using the fast preset. Original file size is 75.5MB, image quality is excellent with zero visible artifacts and no detail loss.

post-170258-0-39169300-1440606409_thumb.


The first comparison set was run at 1920x1080p with a CQ value of 20 with the medium preset for both h264 and h265. File size is 52.6MB for h264, and 53.4MB for h265. Image quality is identical for both, artifacts are present, but essentially unnoticeable unless pixel spotting, h264 wins by a small margin due to the slightly smaller file size and identical quality.
h264post-170258-0-75531300-1440606501_thumb. h265post-170258-0-22353900-1440606590_thumb.


The second comparison set was again 1920x1080p with a CQ value of 30 with the medium preset for both. The file sizes are 26.5MB for h264, and 24.9MB for h265. h265 has better image quality, but details are lost in both and artifacts are clearly visible in both without the need to resort to pixel spotting. h265 wins here by a small margin, it isn't enough to convince me to switch now, but maybe as time goes on it'll get better.
h264post-170258-0-74193800-1440606647_thumb. h265post-170258-0-91984600-1440606693_thumb.

The third set was the most surprising, it was also run at 1920x1080p, but with a completely unrealistic CQ of 45 and the medium preset for both h264 and h265. The file sizes are 13.8MB for h264 and 10.1MB for h265. H264 is terrible, major detail loss, blurry image and prominent artifacting across the entire image, h265 is even worse though, it is absolutely atrocious, entire blocks of video are completely messed up and details are almost nonexistent, it's blurry and just awful, but this comparison is completely unrealistic, anyone using these settings needs taking out behind the barn and put out of their misery cause no one could watch a video this bad.

h264post-170258-0-98402700-1440606758_thumb. h265post-170258-0-54984700-1440606788_thumb.

I'm glad I ran this comaprison tbh, I've found that although h265 can produce smaller files, it isn't actually as much as we've been led to believe, but we need to wait and see if the h265 codec gets better in the future, but as it stands right now, it's not quite ready for use as a replacement for h264.

post-170258-0-39169300-1440606409_thumb.

post-170258-0-75531300-1440606501_thumb.

post-170258-0-22353900-1440606590_thumb.

post-170258-0-74193800-1440606647_thumb.

post-170258-0-91984600-1440606693_thumb.

post-170258-0-98402700-1440606758_thumb.

post-170258-0-54984700-1440606788_thumb.

CPU: Core i5 2500K @ 4.5GHz | MB: Gigabyte Z68XP-UD3P | RAM: 16GB Kingston HyperX @ 1866MHz | GPU: XFX DD R9 390 | Case: Fractal Design Define S | Storage: 500GB Samsung 850 EVO + WD Caviar Blue 500GB | PSU: Corsair RM650x | Soundcard: Creative Soundblaster X-Fi Titanium
Click here to help feed our lasses Pokemon

Link to comment
Share on other sites

Link to post
Share on other sites

I still prefer HVEC, and WebM.

WebM is literally god.

Silverstone ML08  ||  Intel i5-6600  ||  Gigabyte HD 7950 @ Stock  ||  Corsair 2x4GB DDR4 2133MHz  ||  Gigabyte H170-N WIFI  ||  Samsung 840 Pro 128GB  ||  WD Caviar Black 1TB  ||  MSX 64-bit

Link to comment
Share on other sites

Link to post
Share on other sites

WebM is literally god.

WebM is just a container

Link to comment
Share on other sites

Link to post
Share on other sites

Try compressing blu-ray movies (rip them from disk, then compress). I've gotten much smaller file sizes without seeing an impact on image quality. 

I've also ecountered movies that are compressed so small by x265 that I've re-compressed then with a higher CQ value, just because the file was so small, it kinda worried me. (I expected 9GB, got 5GB or so, and since I live audio uncompressed, that's very small.). 

 

Seeing these results, I've used x265 and aimed for a bit smaller file sizes when compressing, than I did with x264. I have no complains about the visual result. 

 

For reference, I usually use 18 as CQ, sometimes I go as "low" as 15 when files get very small. This is using Fast preset. I tested, faster, fast and medium, didn't notice any real difference, so I went with fast just in case. 

Ryzen 7 5800X     Corsair H115i Platinum     ASUS ROG Crosshair VIII Hero (Wi-Fi)     G.Skill Trident Z 3600CL16 (@3800MHzCL16 and other tweaked timings)     

MSI RTX 3080 Gaming X Trio    Corsair HX850     WD Black SN850 1TB     Samsung 970 EVO Plus 1TB     Samsung 840 EVO 500GB     Acer XB271HU 27" 1440p 165hz G-Sync     ASUS ProArt PA278QV     LG C8 55"     Phanteks Enthoo Evolv X Glass     Logitech G915      Logitech MX Vertical      Steelseries Arctis 7 Wireless 2019      Windows 10 Pro x64

Link to comment
Share on other sites

Link to post
Share on other sites

You didn't compare the same file twice, so your comparison is void, if you're gonna test variation between two codecs, you ought to do it with the same sample file, but that's not quite the point.

h265 is harder to decode and encode now because most hardware doesn't natively support it, most decoders in GPUs only support h264 and other older codecs so of course it used more CPU time during playback, and h265 is only in the same situation that h264 was in just a few years ago.

h264 used to take forever compared to mpeg4, but now with hardware and software support h264 is nearly as fast as mpeg4, and the same is true of h265, it'll take longer now but once the support is in place it should be just as fast if not faster than h264.

I'll get handbrake installed and run some encode tests and see what the numbers give, also remember that the advantage of h265 is not really speed, it's compression and the resulting file sizes, h265 allows for a file about half the size of h264 for the same quality, and that's the important part, which if you only compare similar settings for h264 vs. h265, h264 wins nearly every time, but start compressing h264 more and more and watch as the quality tanks, whereas h265 holds the same quality but at greater compression ratios.

Edit:

This is my results for h264 vs h265. CAUTION LARGE IMAGES! YOU HAVE BEEN WARNED!

The same sample video was used every time, the original video is a 1minute 36 second video recording of Sonic the Hedgehog 2 at 1920x1080p resolution and is a h264 file with a CQ value of 16 using the fast preset. Original file size is 75.5MB, image quality is excellent with zero visible artifacts and no detail loss.

attachicon.gif01 Original.png

The first comparison set was run at 1920x1080p with a CQ value of 20 with the medium preset for both h264 and h265. File size is 52.6MB for h264, and 53.4MB for h265. Image quality is identical for both, artifacts are present, but essentially unnoticeable unless pixel spotting, h264 wins by a small margin due to the slightly smaller file size and identical quality.

h264attachicon.gif02 h264 CQ20.png h265attachicon.gif03 h265 CQ20.png

The second comparison set was again 1920x1080p with a CQ value of 30 with the medium preset for both. The file sizes are 26.5MB for h264, and 24.9MB for h265. h265 has better image quality, but details are lost in both and artifacts are clearly visible in both without the need to resort to pixel spotting. h265 wins here by a small margin, it isn't enough to convince me to switch now, but maybe as time goes on it'll get better.

h264attachicon.gif04 h264 CQ30.png h265attachicon.gif05 h265 CQ30.png

The third set was the most surprising, it was also run at 1920x1080p, but with a completely unrealistic CQ of 45 and the medium preset for both h264 and h265. The file sizes are 13.8MB for h264 and 10.1MB for h265. H264 is terrible, major detail loss, blurry image and prominent artifacting across the entire image, h265 is even worse though, it is absolutely atrocious, entire blocks of video are completely messed up and details are almost nonexistent, it's blurry and just awful, but this comparison is completely unrealistic, anyone using these settings needs taking out behind the barn and put out of their misery cause no one could watch a video this bad.

h264attachicon.gif06 h264 CQ45.png h265attachicon.gif07 h265 CQ 45.png

I'm glad I ran this comaprison tbh, I've found that although h265 can produce smaller files, it isn't actually as much as we've been led to believe, but we need to wait and see if the h265 codec gets better in the future, but as it stands right now, it's not quite ready for use as a replacement for h264.

To be fair, you're compressing an already heavily compressed video file that is already h.264.

 

As @ aerandir92 says, try the same tests with an uncompressed Blu-Ray rip, via MakeMKV. It would be a more realistic result, since you're starting with a proper source. The results might end up being 100% identical to what you've already done, but they would be more useful data points.

 

Try compressing blu-ray movies (rip them from disk, then compress). I've gotten much smaller file sizes without seeing an impact on image quality. 

I've also ecountered movies that are compressed so small by x265 that I've re-compressed then with a higher CQ value, just because the file was so small, it kinda worried me. (I expected 9GB, got 5GB or so, and since I live audio uncompressed, that's very small.). 

 

Seeing these results, I've used x265 and aimed for a bit smaller file sizes when compressing, than I did with x264. I have no complains about the visual result. 

 

For reference, I usually use 18 as CQ, sometimes I go as "low" as 15 when files get very small. This is using Fast preset. I tested, faster, fast and medium, didn't notice any real difference, so I went with fast just in case. 

 

I would start to rip my Blu-Rays using h.265, but my HTPC is using an ancient Core2Duo with integrated graphics, so it likely wouldn't handle h.265 very well. One of these days I'll get around to upgrading it...

For Sale: Meraki Bundle

 

iPhone Xr 128 GB Product Red - HP Spectre x360 13" (i5 - 8 GB RAM - 256 GB SSD) - HP ZBook 15v G5 15" (i7-8850H - 16 GB RAM - 512 GB SSD - NVIDIA Quadro P600)

 

Link to comment
Share on other sites

Link to post
Share on other sites

To be fair, you're compressing an already heavily compressed video file that is already h.264.

 

As @ aerandir92 says, try the same tests with an uncompressed Blu-Ray rip, via MakeMKV. It would be a more realistic result, since you're starting with a proper source. The results might end up being 100% identical to what you've already done, but they would be more useful data points.

 

 

I would start to rip my Blu-Rays using h.265, but my HTPC is using an ancient Core2Duo with integrated graphics, so it likely wouldn't handle h.265 very well. One of these days I'll get around to upgrading it...

 

Had the same problem, threw out the HTPC and have my "old" gaming PC as stand in for now (i7 930 and 5970, heh, op? no no)

Ryzen 7 5800X     Corsair H115i Platinum     ASUS ROG Crosshair VIII Hero (Wi-Fi)     G.Skill Trident Z 3600CL16 (@3800MHzCL16 and other tweaked timings)     

MSI RTX 3080 Gaming X Trio    Corsair HX850     WD Black SN850 1TB     Samsung 970 EVO Plus 1TB     Samsung 840 EVO 500GB     Acer XB271HU 27" 1440p 165hz G-Sync     ASUS ProArt PA278QV     LG C8 55"     Phanteks Enthoo Evolv X Glass     Logitech G915      Logitech MX Vertical      Steelseries Arctis 7 Wireless 2019      Windows 10 Pro x64

Link to comment
Share on other sites

Link to post
Share on other sites

To be fair, you're compressing an already heavily compressed video file that is already h.264.

 

As @ aerandir92 says, try the same tests with an uncompressed Blu-Ray rip, via MakeMKV. It would be a more realistic result, since you're starting with a proper source. The results might end up being 100% identical to what you've already done, but they would be more useful data points.

 

 

I would start to rip my Blu-Rays using h.265, but my HTPC is using an ancient Core2Duo with integrated graphics, so it likely wouldn't handle h.265 very well. One of these days I'll get around to upgrading it...

 

I am going to actually take a crack at some h265 Encoding my Blu-Ray Library. What were you using to transcode?

Link to comment
Share on other sites

Link to post
Share on other sites

Please don't use x265 yet it's horrible especially at higher bitrates.

Link to comment
Share on other sites

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×