[HEVC] x265.EXE: mingw builds

[DarrellS]

Why DivX Player refuses to play x265 video files.... The reason for the lack of agreement on a standard decoders of HEVC participants?

Change extension from .mkv to .divx and x265 encoded files play just fine. I'm sure that if you chose DivX Player to be the default player for .mkv that it would play them also but I'm not willing to let DivX take over my PC.

[El Heggunte]

build 1.2+555-866f21378d94

[Mephesto]

El Heggunte, you are the best.
Sadly, I didn't see any ads when I clicked on there.
Just a stupid hooterless blank Google page.

[El Heggunte]

"Google is an ADvertising machine" => http://www.google.com/search?q=%22google+is+an+advertising+machine%22&btnG=Search&comp...=0&hl=en&gbv=1

As you can see, there always exists a method in my madness

[LigH.de]

Because it is "stable" now, x265 1.2+557-87400d5c90aa.

[El Heggunte]

build 1.2+569-d15367360097

[El Heggunte]

build 1.2+570-75d01da6df07

[El Heggunte]

build 1.2+575-80129b1b6260

[Gravitator]

Used x265_1.2+575-80129b1b6260 (x64) - obtained transparent textures.
Original sample > park_joy (mega.co.nz).

[Selur]

"obtained transparent textures", can you elaborate on that?

[Gravitator]

can you elaborate on that?

In what sense?

[Selur]

What do you understand as textures when looking at images/videos?

[Gravitator]

I see that man transparent (rayed rear baffle/partition/fence). Incorrect superposition of two elements in the construction of a frame (moving object + object do not move).

[LigH.de]

This "transparency" might in fact be a belt which got blurred in all but the one frame where it is best matching to the fence.

You seem to have chosen such a low bitrate or quality level that x265 was forced to use even barely similar references.

[Gravitator]

I think that the links of one chain.
Examples:
1. Future 1 & Future 2
2. Blurred/Smoothing problem
-----
It would be a wonderful presence developers DivX, f265 to compare the results with x265 (more rapid identification of problems).
+ Powerful processors.

[Selur]

Using Kvazaar and f265 doesn't really make much sense atm. since they lack lots of features.
If you want to compare x265 and DivX265 against another encoder, compare against the reference encoder (and the original).

[El Heggunte]

build 1.2+580-9461fc801cd2

[El Heggunte]

build 1.2+581-97ea21754381

[LigH.de]

x265_1.3+18-bad70432b1d3

[El Heggunte]

x265_1.3_18-bad70432b1d3.7z

At last \o/

[El Heggunte]

build 1.3+20-6e6756f94b27

[Gravitator]

Handbrake fan Wadka commented problem playing x265 through DivX player.

Unfortunately the presets won't load in handbrake and throw a very long exception.
Furthermore the syntax used in the post is not for handbrake but for x265.
The -I option in x265 lets you set the keyint value but in Handbrake it enables Ipod 5g support.
I tried x265 myself and figured out, that it is able to encode a h.265 stream that is compatible with the divx player. The limitations in the post are not even necessary to add.

So after all, good news. It's neither a bug in x265 encoding nor in divx decoding. We found a bug in the handbrake beta and that's perfectly fine.

I'm going to post this in the handbrake forums.

Source > DivX

[El Heggunte]

build 1.3+26-5acfb12ec5d1

[El Heggunte]

build 1.3+35-32891b95f669

[LigH.de]

If you don't wait for a "merge with stable", you may have included changes since the last merge in only either "default" or "stable" branch.

x265 1.3+36-77fe0cc583e8

[El Heggunte]

build 1.3+53-b18ae1fe86b8

[Mephesto]

I've done another quality test, the first since I tried 1.0 back in May with disappointing results. 1.3 has really changed the game.

With the 720x320 music video, x265 beat x264 with an SSIM of 0.98374 vs x264's 0.98134, making it about 15% better objective quality.
The revolution is here, brothers and sisters. x265 has finally outclassed x264. Dunno if I'll be using it yet though, the speed was 1 fps for a 720x320 video. Jeez. 13 times slower. When I first got this i7 in 2010 it was a mother f**ing godsend that enabled me to encode 720p in realtime. No way in hell I'm going back to that mess I had with that Pentium D that was slow as shit despite being 4 GHZ.

On a video game recording video the average SSIM between both was perfectly tied. I had to add black borders because the video was so small (256x224) and H265's lowest tier encodes nothing below 320x240. This limitation should be lifted. But x265 also added a dark tint to the left of the video so I had to crop that so the SSIM values don't get messed. It might be a slightly biased comparison because I used the toughest settings in x264 and tried to use the best settings in x265 as well but since I'm unfamiliar with half the settings I can't say I did, but I did use 16 refs with 16 bframes which is the most important.

Next I need to test a cartoon and see how well x265 does with that.

The score for x265 1.0 was 0.97981 and 0.97917 for the one from Nov. 2013 in case anyone's interested.

I did not subjectively evaluate the quality yet.

BPP for both videos are 0.163 and 0.089.

Command lines used:

avs2yuv exgf.avs -o - | x265 --y4m --crf 21.9 --me 3 --subme 7 --rect --amp --rd 6 --ref 8 --bframes 16 -o exgf.hevc - 
avs2yuv ng2.avs -o - | x265 --y4m --crf 22 --me 3 --subme 7 --rect --amp --rd 6 --ref 16 --bframes 16 -o ng2.hevc -

[Selur]

x265 beat x264 with an SSIM of 0.98374 vs x264's 0.98134, making it about 15% better objective quality.

How is a difference of 0.0024 15% percent?

Since the SSIM values are nearly identical. (scaling differences can make small difference look a lot larger then they are )
What about the file sizes? (Clearly with the same SSIM values, the file with the lower file size would be preferable)
Also is there anything easy noticable different to the frames/scenes where x265 looses SSIM wise?

[Detmek]

((1-Old SSIM)/(1-New SSIM)-1)*100=((1-0.98134)/(1-0.98374)-1)*100=14,7601476%

[Selur]

@Detmek: Doh, thanks! I always forget that 0.98 is twice as good as 0.96 and that that looks x% better is not really that objective.