x264 vs x265 vs vp9

[karasu]

After a long time with x264, I decided to try the new encoders to see if they are better suited to archive my movies.

As I always use quality mode, I made several encodings to find the right value producing the same file size for each encoders.

source (http://i.cubeupload.com/iHwllC.png)

x264 (http://i.cubeupload.com/tpc6Xq.png) v0.146.2555
cli: x264 input --preset slower --tune grain --crf 21 -o out.x264
stat: 5.53fps 9337kb/s

x265 (http://i.cubeupload.com/iOMhiC.png) v1.7
cli: x265 --preset slower --tune grain --crf 18 -o out.x265
stat: 0.57fps 9433kb/s

VP9 (http://i.cubeupload.com/kZGGaJ.png) v1.5
cli: vpxenc input --end-usage=3 --cq-level=13 --good --cpu-used=0 -o out.vp9
stat: 0.7fps 8929kb/s


x264 clearly provide the better picture. Did I do something wrong?

[Nintendo Maniac 64]

I believe this is largely conjecture on my part, but if the stars align correctly maybe it won't be...


The source might not be the best test since it's somewhat grainy, and both HEVC and VP9 can somewhat remove film-grain.

This is possibly because both HEVC and VP9 are optimized for low bit rates, and AVC is known to turn into a pixelated mess at particularly low bitrates, so HEVC and VP9 might be tuned to "blur" rather than "pixelate" which may have the side-effect of reducing film-grain.

[foxyshadis]

Is this a still picture you encoded? Or a frame of a video? You can't tell anything about video unless you control the rate control (the frame type and size), looking at just one frame is the worst way to judge a video encoder. You either have to specifically look for several frames that are the same type across all encodes, or many frames all over the video, or better yet, just holistically concentrate on short clips rather than stills (since real video is in motion, after all).

One of the priorities of the next release or two of x265 is modifying --tune grain, even if it's at the expense of other things. I doubt VP9 will ever be optimized for it though.

I think you might have an error in your vp9 command-line: --end-usage=3 is q, not cq, unless you intended to use constant-quant instead of constant-quality (crf). (Don't use the numbers for this reason, stick to the letters.) You should also use -p 1 with either one.

[karasu]

I encoded a short sample of ~900 frames, each encoded files are ~40MB

I know it's not enough to judge on one frame, but the loss of grain is consistent over the whole clip for x265 and VP9. X264 looks better in motion as well.

Foxyshadis : I had trouble finding up to date documentation for VP9, for some reason --end-usage=cq doesnt work (it fall back to a 200kb/s default). And I found a page telling 3=cq. Which number is CQ?
also, what does -p 1does?

So overall, you guys don't find this result so surprising?

[huhn]

a huge color shift for VP9 and HEVC.

i saw this before and i wonder why.

[pandy]

It is not fair to compare sufficiently mature codec encoder implementation (such as x264 for h.264) with new and immature codecs.

[foxyshadis]

0 is vbr, 1 is cbr, 2 is cq, and 3 is q. It's pretty easy to verify by using --q-hist=63. Strange that it isn't working with text, works here.

I don't find it too surprising, overall, though the degree of smoothing in x265 is a little more than I'd expect. Since the 1.7 release there have been a few grain-related changes, and more are on the way for 1.8, so at least it isn't all bad, though HEVC simply doesn't seem suited to grain (at least not more than the much faster AVC). If you shared the sequences, there might be more to say.

[Atak_Snajpera]

x265 is quite mature. AQ is implemented as well as psy rd. I think that problem lies in not optimal default settings. You may get better results if you increase values in aq and psy.

[foxyshadis]

a huge color shift for VP9 and HEVC.

i saw this before and i wonder why.

I don't see any color shift at all. The all have identical hues, but the black bleeds more into x265 and much more into vp9 than into x264, making for overall darker images. I agree it doesn't look right, but it doesn't look obviously wrong either. Might have to do with block size.

I suspect this frame might be a B-frame in the x265 but P-frame in x264?

[Jamaika]

http://i67.tinypic.com/xf6fl3.png

Edit: The advantage of creating animation BPG is negligible. There isn't implementation in FFmpeg. Much better and faster converting with new codecs X265 {--ref 1 --bframes 0 --preset placebo}. If we have such a need, the contents X265 can be copied using the HEX editor to containers BPG. (24/01/2016)

[huhn]

I don't see any color shift at all. The all have identical hues, but the black bleeds more into x265 and much more into vp9 than into x264, making for overall darker images. I agree it doesn't look right, but it doesn't look obviously wrong either. Might have to do with block size.

I suspect this frame might be a B-frame in the x265 but P-frame in x264?
the color "issue" is more about why is x264 looking like the source and VP9 and HEVC have "deeper red with less saturation".

looking at the pictures histrogram shows that HEVC has a lot higher AVG blue.

source: 58.58
HEVC: 59.12

other colors are +- ~0.15

[pandy]

x265 is quite mature. AQ is implemented as well as psy rd. I think that problem lies in not optimal default settings. You may get better results if you increase values in aq and psy.

Not sure - x265 lib seem to not work at all (for example seem only CRF supported - no CBR sign at all) - tried to use x265 trough ffmpeg - almost all settings passed trough -x265-params are ignored...
Perhaps i'm to stupid for x265 but x264 works OK with same approach...

[benwaggoner]

x265 is quite mature. AQ is implemented as well as psy rd. I think that problem lies in not optimal default settings. You may get better results if you increase values in aq and psy.
But --tune grain isn't that mature, and changed a lot between 1.7 and 1.8. I've heard some people have had good results using 1.8 but with the 1.7 grain parameters.

In general, --tune grain should be used when the most important thing to do is preserve grain, which often isn't a good psychovisual choice. What x265 really needs is a --tune film equivalent.

As far as color shifts, the likely problem there is due to different decoder paths going through different color space conversions. I've not seen any fundamental color level differences between them.

I can't speak to x265's implementation in ffmpeg. I just use ffmpeg for decoding, and pipe the results into x265.exe. That lets me use the latest builds, and all the parameters work.

[pandy]

I can't speak to x265's implementation in ffmpeg. I just use ffmpeg for decoding, and pipe the results into x265.exe. That lets me use the latest builds, and all the parameters work.

From my perspective x265 rev 1.8 should be sufficiently mature to support all legal parameters - if from some reason x265 doesn't work it means that it is not sufficiently mature - and there is nothing wrong with this - i fully accept outcome of this that good software need time and patience.

[karasu]

Ok, thanks for your feedback, I'll make some new tests this weekend with the latest x265 and better parameters for VP9.

[huhn]

can you add YUA frame so we can check if it is a renderer issue with the color shift?

and what software was used to create these screenshoots?

[karasu]

huhn > what is a YUA frame?

I used ffmpeg to extract the frames.

[benwaggoner]

From my perspective x265 rev 1.8 should be sufficiently mature to support all legal parameters - if from some reason x265 doesn't work it means that it is not sufficiently mature - and there is nothing wrong with this - i fully accept outcome of this that good software need time and patience.
There have been lots of useful improvements, and at least one new parameter (--limit-modes) since 1.8 stable.

You can see the different parameters per version by setting version in the lower left corner of x265.readthedocs.org. Click on the v:default.

[pandy]

There have been lots of useful improvements, and at least one new parameter (--limit-modes) since 1.8 stable.

You can see the different parameters per version by setting version in the lower left corner of x265.readthedocs.org. Click on the v:default.

Thx Ben - then i will try to follow Your advise (i mean pipe ffmpeg > x265 > ffmpeg).

[huhn]

huhn > what is a YUA frame?

I used ffmpeg to extract the frames.

sorry i mean YUV.

just a YCbCr frame that isn't converted to RGB yet.

you could just use madVR to make sure it is converted correctly.

[karasu]

huhn > Do you know if it's possible to export from ffmpeg to a YUV image format (jpg?) without loss?

[foxyshadis]

yuv4mpegpipe (y4m) is a fairly compatible uncompressed YUV format that has its own headers (frame size, bit depth, color format, etc) and is supported in many encoders, and any player that uses LAV filters.

If you must have it compressed, -c:v libx264 -preset slow -qp 0 should work well. (You can vary the preset from ultrafast to veryslow as usual.)

[Jamaika]

a huge color shift for VP9 and HEVC.
i saw this before and i wonder why.
There isn't difference in colors between VP9 on X265. The player set to BT709 and tv range.
I think you might have an error in your vp9 command-line: --end-usage=3 is q, not cq, unless you intended to use constant-quant instead of constant-quality (crf). (Don't use the numbers for this reason, stick to the letters.) You should also use -p 1 with either one.
That's true. Just where to apply --end-usage=2?

Test Jamaika: 100 image PNG(RGB24) to codec {Daala, x265 and VP9} for CRF=28:size=5.45MB, then convert to y4m:
X265 1.8.0.130_x265.cc or BPG image 0.9.6
https://www.sendspace.com/file/ku6ttq
VP9 1.5.0.132_LigH
https://www.sendspace.com/file/vbfhzp
Daala 0.0.1350_Xiph
https://www.sendspace.com/file/1fykmx

[karasu]

foxyshadis > I was thinking about exporting a still image in a YUV format in order to post them here. But PNGs should be fine, I'll try to upload a short clip as well.