has any one else noticed a quality regression with x265?

[deadrats]

allow me to preface this with the statement that this is not meant as troll bait or a desire to flame and i know that i have been very critical of the x265 project from the get go.

having said this, it seemed to me that when x265 was first released with std::in support and we finally got a chance to test it, the quality of the encodes it produced easily surpassed x264 at the same bit rates. but lately it seems that the quality of my test encodes has been going down, to the point where i now feel that at the same bit rate, with x264 and x265 configured for the same encoding speed (typically that involves using very slow for x264 and ultra fast for x265), x264 produces the better quality and easily at that.

interestingly enough, it also seems to me that DivX265 has taken a step back in quality, speaking only of the faster settings since i don't have the patience to test the slower settings.

part of me wonders if my eyes are getting worse but i don't think so, test encodes i did previously still look the same to me. part of me wonders if maybe the various software players i use have taken a step back but my gut tells me that in an effort to improve encoding speed, both x265 and DivX265 have taken programming shortcuts via the use of assembler and SIMD instructions to speed up the encoding process at the expense of quality.

so i would like to know from those of you that regularly do test encodes with x265 and DivX265, does it seem to you that these encodes have taken a quality step back, especially at the faster settings.

[Hoser Rob]

... it also seems to me that DivX265 has taken a step back in quality, speaking only of the faster settings since i don't have the patience to test the slower settings...

Not an x265 expert here, but wouldn't the big quality advance be in the slower settings? That certainly seems to be the way it is comparing ASP to AVC.

[Acesn8s]

i don't use DiVX 4 anything and i do plenty of encoding. i use the x265 builds from http://builds.x265.eu/
with MeGUI or selurs app and they work awesome 4 me. x265 is really taking off as of late.
i have yet to find an encoder that has this kinda quality at half the bitrate and jus one pass.
its faster than x264 on my pc + does a better job. soon there will b more options added.
i.e will b able 2 change the levels etc.. when is gets settled n with more support i will uninstall
x264 and XViD. wish komisar would complile an x265vfw for dubmod but doubt that will ever happen lol

[DarrellS]

Hoser Rob is correct. You're using the best quality for x264 and the worst quality x265. Of coarse x264 is going to look better.

@Acesn8s, something is definitely wrong with your copy of x264 if x265 is faster. x265 has plenty of options, it just needs to be a lot faster. You need to drop that mod of Virtualdub and start using the real Virtualdub 1.10.4 which can use the x265.exe and DivX265.exe encoders with the external encoder feature since they both accept stdin "-".

[Atak_Snajpera]

i don't use DiVX 4 anything and i do plenty of encoding. i use the x265 builds from http://builds.x265.eu/
with MeGUI or selurs app and they work awesome 4 me. x265 is really taking off as of late.
i have yet to find an encoder that has this kinda quality at half the bitrate and jus one pass.
its faster than x264 on my pc + does a better job. soon there will b more options added.
i.e will b able 2 change the levels etc.. when is gets settled n with more support i will uninstall
x264 and XViD. wish komisar would complile an x265vfw for dubmod but doubt that will ever happen lol

Nice lies my amigo. x264 --preset medium is about ~4-5x faster than x265 with preset medium or x264 preset veryslow has the same encoding speed as x265 preset medium. Still x264 gives more detailed image than x265. I will have to prepare quick test to just open your eyes. x265 is still in early days of development.

CPU: Xeon E5-2690 @ 2.9Ghz ( 8C - 16T )
x264 --preset veryslow , encoding speed 8.3 fps , average bitrate : 2279 Kbps , file size : 16.3 MB
https://mega.co.nz/#!BE0nmTrZ!Nf6dG2BC4aBb3CBWdp9nPPIZj4bj7b2WEPbrWgz93YY

x265 --preset medium , encoding speed 7.7 fps , average bitrate : 2269 Kbps , file size : 16.3 MB
https://mega.co.nz/#!NN9mwbiY!2Zp4lN2bJ-zLbHWh9jGRKChDAjPk5ROwkID6on6Gs0g

Screenshots

x264
frame 625 -> http://i.cubeupload.com/99I2GS.png
frame 1065 -> http://i.cubeupload.com/21QL6S.png

x265
frame 625 -> http://i.cubeupload.com/Jrl3mg.png
frame 1065 -> http://i.cubeupload.com/oHudEz.png

[Selur]

x265 and DivX265 have taken programming shortcuts via the use of assembler and SIMD instructions to speed up the encoding process at the expense of quality.

How is using assembler and cpu optimizations a programming shortcut ?

[deadrats]

x265 and DivX265 have taken programming shortcuts via the use of assembler and SIMD instructions to speed up the encoding process at the expense of quality.

How is using assembler and cpu optimizations a programming shortcut ?

it's a programming shortcut if the output of the assembler and/or SIMD doesn't match the output produced by pure C code.

i don't know how old you are or how long you've been writing code for, but i remember back in the early days of SIMD where it was known that the SIMD units would take math shortcuts, particularly with floating point math, as a way of speeding up math calculations and the results produced by by SIMD operations didn't match the output of straight C.

i also remember the intel C compiler, if you enabled the optimizing assembler/simd features of the compiler would produce code that would produce wrong output on some calculations; this was also true of gcc, visual c and borland's compilers but to a lesser extent.

in fact. a few years ago i did some tests using the older version of tmpg, whatever version 3 was called, where i did a bunch of test encodes with all the SIMD instructions enabled and with all of them disabled and the results produced with no SIMD was of higher quality than with albeit painfully slow.

in fact, here's a test you can do if you have the patience, x264 has a no-asm switch if i remember correctly, do two test encodes using the exact same settins for both but disabled asm for one of the encodes and compare the results via PSNR and SSIM, i'm willing to bet that n-asm results in higher quality.

[Selur]

i don't know how old you are or how long you've been writing code for, but i remember back in the early days of SIMD where it was known that the SIMD units would take math shortcuts, particularly with floating point math, as a way of speeding up math calculations and the results produced by by SIMD operations didn't match the output of straight C.

I too know the beginning of SIMD and I have written quite a bit assembler when I started programming (more than 15 years ago; and I'm happy that time is over) and I can assure you, that saying assembler and SIMD in general are short cuts is just wrong.

it's a programming shortcut if the output of the assembler and/or SIMD doesn't match the output produced by pure C code.

I agree that in that case it would be a short cut. But for lots of calculations the output of functions does not need to be exact matches. If for example one output says: 0.1234 and the other says 0.1235, but only the first two digits after the dot are important the output of the functions differs, but the end result will not change.

Also using some CPU instruction sets in an unproper way and using inline assembler in general are different things.

in fact, here's a test you can do if you have the patience, x264 has a no-asm switch if i remember correctly, do two test encodes using the exact same settins for both but disabled asm for one of the encodes and compare the results via PSNR and SSIM, i'm willing to bet that n-asm results in higher quality.

I would bet against it.


My points are that:
a. assembler and SIMD code does not necessary produce different output than C code would (there is no inherent difference)
b. even if the output is different, it does not necessary mean that the output is worse

Cu Selur

[deadrats]

CPU: Xeon E5-2690 @ 2.9Ghz ( 8C - 16T )
x264 --preset veryslow , encoding speed 8.3 fps , average bitrate : 2279 Kbps , file size : 16.3 MB
https://mega.co.nz/#!BE0nmTrZ!Nf6dG2BC4aBb3CBWdp9nPPIZj4bj7b2WEPbrWgz93YY

x265 --preset medium , encoding speed 7.7 fps , average bitrate : 2269 Kbps , file size : 16.3 MB
https://mega.co.nz/#!NN9mwbiY!2Zp4lN2bJ-zLbHWh9jGRKChDAjPk5ROwkID6on6Gs0g

these encoding speeds seem very low, especially for x264 using an 8 core xeon (that is a nice setup btw).

what did you use for source and how did you encode, i want to run a speed test on my system and see how it compares.

[enim]

one of the foundation stone for HEVC says

HEVC is said to double the data compression ratio compared to H.264/MPEG-4 AVC at the same level of video quality. It can alternatively be used to provide substantially improved video quality at the same bit rate.

Now, considering Atak's test run,

Originally Posted by Atak_Snajpera

CPU: Xeon E5-2690 @ 2.9Ghz ( 8C - 16T )
x264 --preset veryslow , encoding speed 8.3 fps , average bitrate : 2279 Kbps , file size : 16.3 MB

x265 --preset medium , encoding speed 7.7 fps , average bitrate : 2269 Kbps , file size : 16.3 MB

Should not x265 bitrate be read as 1140kbps?
-or-
At same bitrate x265 should claim far better quality than x264/AVC?

[Atak_Snajpera]

CPU: Xeon E5-2690 @ 2.9Ghz ( 8C - 16T )
x264 --preset veryslow , encoding speed 8.3 fps , average bitrate : 2279 Kbps , file size : 16.3 MB
https://mega.co.nz/#!BE0nmTrZ!Nf6dG2BC4aBb3CBWdp9nPPIZj4bj7b2WEPbrWgz93YY

x265 --preset medium , encoding speed 7.7 fps , average bitrate : 2269 Kbps , file size : 16.3 MB
https://mega.co.nz/#!NN9mwbiY!2Zp4lN2bJ-zLbHWh9jGRKChDAjPk5ROwkID6on6Gs0g

these encoding speeds seem very low, especially for x264 using an 8 core xeon (that is a nice setup btw).

what did you use for source and how did you encode, i want to run a speed test on my system and see how it compares.

sample -> http://www.diktafon.atw.hu/112.MTS

script

DirectShowSource("112.MTS",audio=false)

x265 --crf 30
x264 --crf 33.6

[Acesn8s]

i don't use DiVX 4 anything and i do plenty of encoding. i use the x265 builds from http://builds.x265.eu/
with MeGUI or selurs app and they work awesome 4 me. x265 is really taking off as of late.
i have yet to find an encoder that has this kinda quality at half the bitrate and jus one pass.
its faster than x264 on my pc + does a better job. soon there will b more options added.
i.e will b able 2 change the levels etc.. when is gets settled n with more support i will uninstall
x264 and XViD. wish komisar would complile an x265vfw for dubmod but doubt that will ever happen lol

Nice lies my amigo. x264 --preset medium is about ~4-5x faster than x265 with preset medium or x264 preset veryslow has the same encoding speed as x265 preset medium. Still x264 gives more detailed image than x265. I will have to prepare quick test to just open your eyes. x265 is still in early days of development.

CPU: Xeon E5-2690 @ 2.9Ghz ( 8C - 16T )
x264 --preset veryslow , encoding speed 8.3 fps , average bitrate : 2279 Kbps , file size : 16.3 MB
https://mega.co.nz/#!BE0nmTrZ!Nf6dG2BC4aBb3CBWdp9nPPIZj4bj7b2WEPbrWgz93YY

x265 --preset medium , encoding speed 7.7 fps , average bitrate : 2269 Kbps , file size : 16.3 MB
https://mega.co.nz/#!NN9mwbiY!2Zp4lN2bJ-zLbHWh9jGRKChDAjPk5ROwkID6on6Gs0g

Screenshots

x264
frame 625 -> http://i.cubeupload.com/99I2GS.png
frame 1065 -> http://i.cubeupload.com/21QL6S.png

x265
frame 625 -> http://i.cubeupload.com/Jrl3mg.png
frame 1065 -> http://i.cubeupload.com/oHudEz.png

open my eyes lol ok
i don't care what ur stats say mate we don't have the same computers. i use the ultrafast preset and only having to make 1 pass is WAY faster and more efficient 4 me/ they don't call it hevc 4 nothing. it only needs 1 pass. compared to x264 way bigger file size and 2 passes.
the ultrafast preset can't even really b used with any decent quality using x264. it takes me 3-4 hours to do 1 pass with x265 (1080 blurays) and 6-7 hours to do 2 passes with x264 point being x264 has to have 2 passes.and x265 just 1 pass so not having to make the xtra pass is way faster.

[_Al_]

I have to ask obvious, why x264 would not encode 1pass CRF?

[hello_hello]

open my eyes lol ok
i don't care what ur stats say mate we don't have the same computers. i use the ultrafast preset and only having to make 1 pass is WAY faster and more efficient 4 me/ they don't call it hevc 4 nothing. it only needs 1 pass. compared to x264 way bigger file size and 2 passes.
the ultrafast preset can't even really b used with any decent quality using x264. it takes me 3-4 hours to do 1 pass with x265 (1080 blurays) and 6-7 hours to do 2 passes with x264 point being x264 has to have 2 passes.and x265 just 1 pass so not having to make the xtra pass is way faster.

And you're completely unaware x264 also has a single pass, quality based encoding mode??? Unless you've got a magical argument for claiming x264 must run 2 passes I think you've just disqualified yourself from the discussion.

My little test encodes of a few weeks ago seemed to somewhat match what Atak_Snajpera is saying. I used the default settings for both encoders (CRF23 and the medium speed preset) and x265 didn't even come close to matching x264 for quality. Two different ballparks. Chalk and cheese. And x265 was much, much slower. By the time I'd lowered the CRF value for the x265 encoder to the point it was matching x264 for quality it was around CRF16 and the bitrates were very similar. And that was at CRF23 for x264. I didn't bother trying to work out how low I'd need to take the CRF value for x265 before it'd match x264 at CRF18.

For the record, I ran my test encodes using MeGUI and the version of x265 it installed, which I don't think has changed in the last couple of weeks, so according to MeGUI that's version 0.6+282. The x265 exe is dated 2014/01/14.

[DarrellS]

The latest build is 0.8.0.136. There have been a few changes since 0.6+282 was released. I don't know if you can encode a 7680x4320 frame with x264. I can't. The 7680x4320 frames that I have produced look pretty good to me. It takes me 32 seconds to produce one frame but at least it will produce a file. I'll try and encode a 8192x4320 frame later if I can find a source file that big. High resolutions are where the HEVC encoder is said to excel..