Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Video Encoding > High Efficiency Video Coding (HEVC)

Reply
 
Thread Tools Search this Thread Display Modes
Old 17th November 2015, 17:02   #1  |  Link
shae
Registered User
 
Join Date: Jun 2006
Posts: 397
The state of h265 as of Nov 2015?

I haven't been following h265 at all. Can anyone summarize where it stands currently?

Current quality versus h264 (and also specifically in available PC encoders vs x264), what quality improvements are still expected (encoder tuning and yet-unimplemented features), current commonly used encoders and decoders, encoding and decoding speed and compatibility concerns and outlooks...

How long do you think it will take for h265 to replace h264 as the de facto standard format for PC creation and consumption? Is Bluray UHD now the real beginning of widespread adoption?

Last edited by shae; 17th November 2015 at 17:32.
shae is offline   Reply With Quote
Old 19th November 2015, 00:33   #2  |  Link
pandy
Registered User
 
Join Date: Mar 2006
Posts: 1,049
http://compression.ru/video/codec_comparison/hevc_2015/
pandy is offline   Reply With Quote
Old 19th November 2015, 15:52   #3  |  Link
Motenai Yoda
Registered User
 
Motenai Yoda's Avatar
 
Join Date: Jan 2010
Posts: 709
I hope it'll take about 1 year for x265 to totally overcome x264 on all sides.
__________________
powered by Google Translator
Motenai Yoda is offline   Reply With Quote
Old 19th November 2015, 21:16   #4  |  Link
fields_g
x264... Brilliant!
 
Join Date: Mar 2005
Location: Rockville, MD
Posts: 167
This is an in depth comparison. Remember this is a good snapshot of codecs available April 1, 2015. Some of these codecs are undergoing improvements faster than others since then.
fields_g is offline   Reply With Quote
Old 20th November 2015, 05:46   #5  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 4,821
The way that testing was done makes me wonder how often Apples were being compared with Apples. In some instances CBR was used for one encoder and 2 pass VBR for another. The SSIM tuning was used for x264 but not for x265. Varying keyint settings. When a minimum encoding speed was required and 2 pass encoding was used I'm not sure if it applied to only the second pass, or both passes combined.

Ignoring those types of differences though, HEVC doesn't seem to be setting the world on fire. According to those tests x265, which generally rated the best in respect to bitrate for a specific quality, still didn't do all that much better than x264. 74% the bitrate of x264 when encoding speed wasn't a factor and around 90% for more realistic encoding speeds. Wasn't the original promise somewhere in the vicinity of 50%?

Last edited by hello_hello; 20th November 2015 at 05:48.
hello_hello is offline   Reply With Quote
Old 20th November 2015, 09:22   #6  |  Link
rwill
Registered User
 
Join Date: Dec 2013
Posts: 341
Quote:
Originally Posted by hello_hello View Post
The way that testing was done makes me wonder how often Apples were being compared with Apples. In some instances CBR was used for one encoder and 2 pass VBR for another. The SSIM tuning was used for x264 but not for x265. Varying keyint settings. When a minimum encoding speed was required and 2 pass encoding was used I'm not sure if it applied to only the second pass, or both passes combined when multi pass encoding was used.
As far as I know the encoder developers were asked to provide encoder settings for their encoder. So if an encoder performs below its capabilities its the developers fault. I agree that more specified and constrained use cases would have helped for a more fair comparison but then again not all encoders would have been able to enter for a use case as they are lacking certain features. Its the first time the MSU did an HEVC encoder comparison. Regarding speed requirements, it was all passes combined.

Quote:
Originally Posted by hello_hello View Post
Ignoring those types of differences though, HEVC doesn't seem to be setting the world on fire. According to those tests x265, which generally rated the best in respect to bitrate for a specific quality, still didn't do all that much better than x264. 74% the bitrate of x264 when encoding speed wasn't a factor and around 90% for more realistic encoding speeds. Wasn't the original promise somewhere in the vicinity of 50%?
You should not assume that just because x265 did below your expectations in that particular test for HEVC that HEVC as a standard is not "delivering". There was an option to participate in the MSU test and have the results for an encoder to remain private and not show up in the publicly available results. I mean the only interesting encoders in the public comparison are Intel, x265 and Ittiam. There are possibly quite a lot of results kept private or some developers just did not bother to participate. It is a wrong assumption that x265 is the best HEVC encoder out there.
rwill is offline   Reply With Quote
Old 20th November 2015, 09:31   #7  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,336
Quote:
Originally Posted by hello_hello View Post
Wasn't the original promise somewhere in the vicinity of 50%?
And it will take a couple more years to reach that. It just takes time until encoders mature. Note that it was never expected to reach 50% at the same encoding speed, so having a slower encode is expected.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is offline   Reply With Quote
Old 20th November 2015, 17:03   #8  |  Link
x265_Project
Guest
 
Posts: n/a
Quote:
Originally Posted by hello_hello View Post
The SSIM tuning was used for x264 but not for x265.
Yeah, that was a problem. We didn't realize that quality would be measured only with Y-SSIM, otherwise we would have added --tune SSIM to our command line for these tests, and x265 would have done much better.

Quote:
Originally Posted by hello_hello View Post
According to those tests x265, which generally rated the best in respect to bitrate for a specific quality, still didn't do all that much better than x264. 74% the bitrate of x264 when encoding speed wasn't a factor and around 90% for more realistic encoding speeds. Wasn't the original promise somewhere in the vicinity of 50%?
You're right. These tests were forcing each encoder to run at a particular speed on a particular machine. At a given encoding speed, x264 can be run at relatively higher quality settings than x265. The promise of 2x the encoding efficiency of HEVC vs AVC is achievable, but not for free. You only get the full benefit of HEVC only if you pay for it with more computation (which means, more powerful hardware or slower encoding). The MSU test was based on x265 from early April. Since that time we've made a number of solid improvements in speed and quality, adding a massive amount of AVX2 assembly code optimizations, and improving many algorithms (--limit-refs, --limit-modes, --lookahead-slices). We believe a fair retest today would demonstrate much more impressive results for x265.
  Reply With Quote
Old 20th November 2015, 18:09   #9  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 4,821
Thanks for the info guys. I didn't mean to come across as being anti-x265 or anything like that. Just trying to look at it objectively.... and understand

If the speed requirements included both passes combined, it seems to me x265 would have faired better if CRF encoding was used. Probably harder to test given there's no bitrate control but assuming at the same bitrate CRF and 2 pass encode the same way, maybe in some cases a slower speed preset could have been used if a 1st pass wasn't required.

There's some things I don't understand, such as why for the Ittiam HEVC Software Encoder, 2 pass encoding was used for the "ripping" tests while CBR encoding was used for the other two, or why (according to pdf) the ultrafast x265 preset was used for the "desktop 30fps" test while the superfast preset was used for the "server 60fps" test. Logically to me it should have been the other way around.
hello_hello is offline   Reply With Quote
Old 20th November 2015, 21:17   #10  |  Link
vivan
/人 ◕ ‿‿ ◕ 人\
 
Join Date: May 2011
Location: Russia
Posts: 643
Quote:
Originally Posted by hello_hello View Post
why (according to pdf) the ultrafast x265 preset was used for the "desktop 30fps" test while the superfast preset was used for the "server 60fps" test. Logically to me it should have been the other way around.
Server had 14 cores, while desktop only 4 (but at higher clocks). According to benchmarks (Core i7 4770R vs Xeon E5 2697v3) server is 2.25 times faster, so it makes sense.

Last edited by vivan; 20th November 2015 at 21:19.
vivan is offline   Reply With Quote
Old 27th November 2015, 00:49   #11  |  Link
shae
Registered User
 
Join Date: Jun 2006
Posts: 397
Thanks.

I don't find that comparison very informative. Besides the difficult to understand testing criteria and presentation it's not doing any subjective analysis. Is SSIM that helpful? Doesn't color matter? Doesn't it make sense to include UHD when testing H265?

I remember fondly the nice codec comparisons of old (was it here?) of Divx3 vs Divx5 vs Xvid vs..., with screenshots showing problem areas, etc.

Things I'd like to know are more along the lines of, for example, how's banding, how well is "line art" content handled, detail retention in dark areas, any problems in motion, is a given codec better than another in every one of the test samples...

BTW, how crucial is manual tuning nowadays, both of global encode parameters and maybe even scene-specific? Audio encoding is practically "choose bitrate or quality". I still get the sense that video encoding is full of pitfalls, and an ideal encode needs manual work, plus extensive knowledge not only of the codec in general but also of the specific encoder.
shae is offline   Reply With Quote
Reply

Tags
h264, h265, hevc

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 06:47.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.