Available HEVC/H.265 test encoders

[geoyo]

Originally Posted by MasterNobody

I did my own little codec comparison on the first 201 frames of park_joy 1080p sample. Sample was encoded as 25fps instead of 50fps for easier watching during comparison (so it is 2x slowed down).

I make image

Originally Posted by xooyoozoo

Kimono 1080p24
1068 HEVC playable*
1815 VP9  playable*
2138 x264
3207 MPEG4
4276 MPEG2

What are these numbers? 1068 1815 2138 4276? Where explanation?

[pieter3d]

Originally Posted by adkalkan

Hello Im new to this forum and I would like to ask something

I built the HM-10.0 on VisualStudio2010 32bit Win7 laptop
Specs: Intel Core 2 duo @2.4Ghz each and 2GB RAM

I downloaded the sample bitstreams from ftp://ftp.kw.bbc.co.uk/hevc/hm-10.0-anchors/bitstreams/

I decoded the RaceHorses416x240_30_qp22.bin clip for all profiles and the results I got are:

i_main 300frames 166secs (1.80fps)
ld_main 300frames 82secs (3.65fps)
lp_main 300 frames 75secs (4fps)
ra_main 300frames 70 secs (4.2fps)


Do these figures seem OK?
My goal is to improve the Reference Decoder so that it reaches the target >30fps for mobile devices and Im trying to estimate roughly the quality of code of the Reference Decoder(how much is optimized, how much can it be optimized)

You will be WAY better off writing your own decoder from scratch

[Kurtnoise]

Found an optimized reference HEVC encoder...

[xooyoozoo]

Originally Posted by geoyo

What are these numbers? 1068 1815 2138 4276? Where explanation?

Those are the bitrates for each encoder.

[posdnya]

couple HM 10 samples http://www.elecard.com/en/download/videos.html
SD - 563 kbps, average Y-PSNR - 39.60, UV - 43.5
720p - 1039 kbps, average Y-PSNR - 41.87, UV - 46

Original uncompressed: http://media.xiph.org/BBB/

HEVC Player sample for Windows (alpha): http://www.elecard.com/en/technology/researchlab/hevc-player.html
Indepth analisys tool: http://www.elecard.com/en/products/professional/analysis/hevc-analyzer.html

At the same PSNR as JM bitrate is lower then JM approx at 20% and 40% for SD and 720p respectively.
Visually looks significantly better then AVC at the same PSNR.

Would be glad to compare with the best possible encoding made by x264 at the same bitrates.
GOP structure: IBBBPBBBP, Intra period 32 frames, open GOP

[xooyoozoo]

Originally Posted by posdnya

Would be glad to compare with the best possible encoding made by x264 at the same bitrates.
GOP structure: IBBBPBBBP, Intra period 32 frames, open GOP

Was this encoded with reference HM or Elecard's own solution? If the latter, does it do things current AVC encoders would do, like scene-detection, adaptive quant, weighted pred (though I think this is in HM but defaults to off), etc?

Lastly, there's already pre-made 360p/720p BBB versions off of the main Xiph Derf download page. Is it right to assume that the Elecard versions were made off of those instead of off the original 1080p uncompressed plus ad-hoc downscaling?

Edit: to answer my own questions: elecard, i think; nope; dunno but the embedded logo makes it non-worthwhile to find out for more precise metric testing

[foxyshadis]

Originally Posted by xooyoozoo

Was this encoded with reference HM or Elecard's own solution? If the latter, does it do things current AVC encoders would do, like scene-detection, adaptive quant, weighted pred (though I think this is in HM but defaults to off), etc?

Lastly, there's already pre-made 360p/720p BBB versions off of the main Xiph Derf download page. Is it right to assume that the Elecard versions were made off of those instead of off the original 1080p uncompressed plus ad-hoc downscaling?

Edit: to answer my own questions: elecard, i think; nope; dunno but the embedded logo makes it non-worthwhile to find out for more precise metric testing

I've considered hacking external frame-type files into the TAppEncoder, then generate them with x264's excellent decisions, to see how it would handle real shows. It already has qpfile and custom quant file support, not sure why they didn't include that.

I probably should have filed a bug for it back when things were still in the early stages. Kind of late now.

[xooyoozoo]

Originally Posted by posdnya

Would be glad to compare with the best possible encoding made by x264 at the same bitrates.
GOP structure: IBBBPBBBP, Intra period 32 frames, open GOP

Did a comparison versus x264 with typical comparison settings (2pass veryslow --open-gop -I 32), and x264 was unmistakably better. Then, I decided to make things more "fair" by also matching frame decisions (--no-scenecut -b 3 --b-adapt 0). I was still unimpressed by the Elecard-HEVC encode...

The main problem is that the Elecard encode is more macroblock-friendly. These two pictures summarize the issue fairly well: (nevermind)

x264 has its own issues. The hides of the animals sometimes 'shimmer', which I suspect is mostly from psy-rd overextending itself. However, it's much less noticeable and doesn't scream compression as much as blocky images.

Here's a visually transparent (x264 10bit CRF10), arbitrarily chosen scene from BBB done in the style of the two snapshots above: (nevermind). The visual examples all used the "handicapped" x264 encode.

[posdnya]

Originally Posted by xooyoozoo

Was this encoded with reference HM or Elecard's own solution? If the latter, does it do things current AVC encoders would do, like scene-detection, adaptive quant, weighted pred (though I think this is in HM but defaults to off), etc?

Lastly, there's already pre-made 360p/720p BBB versions off of the main Xiph Derf download page. Is it right to assume that the Elecard versions were made off of those instead of off the original 1080p uncompressed plus ad-hoc downscaling?

Edit: to answer my own questions: elecard, i think; nope; dunno but the embedded logo makes it non-worthwhile to find out for more precise metric testing

It's HM 10 encoder, not Elecard. There is no scene dection, adaptive quant, weighted prediction. Encoding was made on pre-made 720p.
Sorry for logo, but I was going to do measurements by myself, just asking to prepare well done encoding with x264

[posdnya]

Originally Posted by xooyoozoo

Here's a visually transparent (x264 10bit CRF10), arbitrarily chosen scene from BBB done in the style of the two snapshots above: (96 MB). The visual examples all used the "handicapped" x264 encode.

Thank you very much. I'll do comparisons and will post my conclusions.

[xooyoozoo]

Originally Posted by posdnya

Thank you very much. I'll do comparisons and will post my conclusions.

(nevermind)

x264 2pass --preset veryslow --no-scenecut -b 3 --b-adapt 0 --open-gop -I 32 -B 1039

Edit: the macroblocking thing is quite interesting then. I was ready to believe the clip was from a non-HM encoder because in my own tests with scenes from BBB, blocks were a non-issue. However, those tests also had HM's included-but-disabled adaptive quant settings activated; I recall the JCT-VC docs on those settings claiming that the switches help with blocking/distortions in flat areas (which BBB has lots of), but I've never bothered to compare those claims versus default HM.

[posdnya]

Originally Posted by xooyoozoo

the macroblocking thing is quite interesting then. I was ready to believe the clip was from a non-HM encoder because in my own tests with scenes from BBB, blocks were a non-issue. However, those tests also had HM's included-but-disabled adaptive quant settings activated; I recall the JCT-VC docs on those settings claiming that the switches help with blocking/distortions in flat areas (which BBB has lots of), but I've never bothered to compare those claims versus default HM.

The issue is that simple - it was encoded with no deblock :-(
Will upload new encodings shortly

[xooyoozoo]

Originally Posted by posdnya

The issue is that simple - it was encoded with no deblock :-(
Will upload new encodings shortly

Ahh that explains it then.

Visually looks significantly better then AVC at the same PSNR.

This also applies to x264 vs HEVC with perceptually-tuned metrics, as they favor x264 quite a bit when tune-ssim is activated. Consequently, when matching metric output, comparative visual results suffer. Vanilla SSIM is the worst with this (because it favors x264 the most), followed by MS-SSIM, then PSNRHVSM.

I've done some tests where the process is conceptually* along the lines of:

• encode HEVC at QP x
• interpolate equivalent x264 bitrate using x264 veryslow 'tune ssim' encodes and 1+ metrics (averaged)
• encode x264 2pass veryslow no-tunings and visually compare

Haven't kept all the results, but here's two: (sintel) (lupo) (side by side cropping and composition made post-encode. Re-encoded CRF10 for transparency)

First one is with HEVC-QP29 and matched MSSSIM+PSNRHVSM (+67% bitrate). Second one is with HEVC-QP35 and matched PSNRHVSM (+100% bitrate). The first clip clearly favors HEVC, while the second clip leaves more room for debate. However, I generally prefer artifacts that don't move of their own free will.

*The process assumes x264 no-tunings has strictly better visual performance than tune-ssim, which should be true with these clips.

[JEEB]

Some time ago HM 10.1 was released. I built a 32bit Windows binary, and it is available here (configuration file folder included).

[sl1pkn07]

any fix to build with gcc 4.8?

http://sl1pkn07.no-ip.com/paste/view/53ffb394

[foxyshadis]

Use -Wno-array-bounds?

[sl1pkn07]

oks, adding that flags on CPPFLAGS on build/linux/common/makefile.base fix my build issue

thanks foxyshadis for giving me light

greetings

[IgorC]

Originally Posted by posdnya

couple HM 10 samples http://www.elecard.com/en/download/videos.html
SD - 563 kbps, average Y-PSNR - 39.60, UV - 43.5
720p - 1039 kbps, average Y-PSNR - 41.87, UV - 46

Original uncompressed: http://media.xiph.org/BBB/

HEVC Player sample for Windows (alpha): http://www.elecard.com/en/technology/researchlab/hevc-player.html
Indepth analisys tool: http://www.elecard.com/en/products/professional/analysis/hevc-analyzer.html

At the same PSNR as JM bitrate is lower then JM approx at 20% and 40% for SD and 720p respectively.
Visually looks significantly better then AVC at the same PSNR.

Would be glad to compare with the best possible encoding made by x264 at the same bitrates.
GOP structure: IBBBPBBBP, Intra period 32 frames, open GOP

I have tried to play "Big Buck Bunny" HEVC 1080p video. It was playable on 3770k @ 3.7 GHz except a few scenes where CPU load was 50-70% and frame rate was slowed down and accelerated later to synchronize with audio. The decoder still needs a performance optimizations.

Overall the quality is good but there are visual blocks and scene detection isn't handled (as xooyoozoo have already mentioned). The picture is sharp and detailed, the details are a bit simplified but acceptably.

[qwddn]

I wonder know when the finalized HEVC spec released, anyone knows?

thanks very much ~

[JEEB]

ITU-T's Last Call only takes a month so ITU-T Recommendation H.265 is already published and available for buying since around middle of April. ISO/IEC's FDIS ballot takes two months, so the same specification should become available as ISO/IEC 23008-2 (MPEG-H Part 2 [HEVC]) around 22nd (?) of May.

So yeah, HEVC version 1 has already been "out there" for quite a while already. Even longer if you take into mention the point of time when the last draft was uploaded onto JCT-VC's document tracker By now you could even start grabbing the "Editors' proposed corrections to HEVC version 1" documents for an even newer version of the text.