Available HEVC/H.265 test encoders [Archive] - Page 2

View Full Version : Available HEVC/H.265 test encoders

Pages : 1 [2] 3

SeeMoreDigital

26th January 2013, 12:34

ITU has approved this codec (http://www.itu.int/net/pressoffice/press_releases/2013/01.aspx#.UQNyyr-zJ8E)...
That's great news... I wonder how quickly we'll see hardware decoding (and encoding) support?

Limit64

26th January 2013, 13:08

According to Golem.de (http://www.golem.de/news/hevc-itu-gibt-videostandard-h-265-frei-1301-97168.html) devices with Broadcoms HEVC decoder chip are planed for mid 2014.

hajj_3

26th January 2013, 17:56

Nearly ratified then :) Lets hope that nvidia and AMD add decoding support into the programmable areas of their gpus like they did with h264 before they created dedicated silicon in their gpu's for h.264. I reckon intel will probably have dedicated silicon in their chips within 18 months as they have a lot of cash to throw at it.

Now someone go do an in-depth test on how good it's compression is at 720x400, 1280x720, 1920x1080 :)

Limit64

26th January 2013, 18:24

Before you can run useful tests you need a good implementation for the new codec. Perhaps x264 will be extended to support the new codec.

Kurtnoise

28th January 2013, 10:13

Looks like x265 project (not related to x264 though) has been updated few days ago (http://code.google.com/p/x265/downloads/list)...

--- Status ---
The final version is 201209, these source will upload at Q3 2013.
The latest source is 201206.

Currently, the project is suspend.

I will working on my commercial version(GPU based) late, and I will come back after the Chinese New Year of 2013.
My attempt of GPU Intra failed, the NVidia Kepler GPU switch so slower, I will continue try it.

Excuse me, I am busy now, so the executeable is up to date, but the source have delay released about 6-9 months.
The SDK will upload after HM-N.0 has released, the latest SDK match to HM-9.0

I am wait a week, but there are no HM-9.2, so I sync to HM-9.2rc1

The code is develop on my x86 platform.
The x64 platform is not office support now
If you use the x64 system, please change UInt32 and Int32 from "int" to "long" in file config.h by youself.

I will decide next year's whereabouts during January, I have no more time to wasting.
I guess it comes down to a simple choice: Get busy living, or get busy dying.

Last Update: 26th Jan, 2013

edison

28th January 2013, 10:32

hm_9.2_r3282_release (http://x264.fushizen.eu/builds/hevc-hm/hm_9.2_r3282_release.7z) built and added (contains the configuration files for that revision as well) :)

The TAppDecoder.exe does not work to me. I did tried it on Win8/Win7 x64 .

hm_9.2_r3282_release>TAppDecoder.exe -b ChinaSpeed_1024x768_30_qp37.bi
n -o 123.yuv

HM software: Decoder Version [9.2rc1][Windows][VS 1600][32 bit]
Assertion failed: uiCode == 3, file ..\..\source\Lib\TLibDecoder\TDecCAVLC.cpp,
line 657

JEEB

28th January 2013, 14:12

The TAppDecoder.exe does not work to me. I did tried it on Win8/Win7 x64 .
WorksForMe with a HM 9.2-encoded stream.

TAppDecoder.exe -b zeroma_HM9.2.hevc -o zeroma_HM9.2.yuv

HM software: Decoder Version [9.2rc1][Windows][VS 1600][32 bit]
TDecCavlc::parsePPS(): m_bUseWeightPred=0 m_uiBiPredIdc=0

POC 0 TId: 0 ( I-SLICE, QP 20 ) [DT 0.006] [L0 ] [L1 ] [:,,,(unk)]
...

xooyoozoo

28th January 2013, 20:46

The TAppDecoder.exe does not work to me. I did tried it on Win8/Win7 x64 .

hm_9.2_r3282_release>TAppDecoder.exe -b ChinaSpeed_1024x768_30_qp37.bi
n -o 123.yuv

HM software: Decoder Version [9.2rc1][Windows][VS 1600][32 bit]
Assertion failed: uiCode == 3, file ..\..\source\Lib\TLibDecoder\TDecCAVLC.cpp,
line 657

You have to match the decoder revision with whatever was used to encode the bitstream.

Kurtnoise

29th January 2013, 13:57

Except the reference decoder and the libav experimental branch, is there a free decoder available yet ?

JEEB

29th January 2013, 19:41

No idea about exact details, but smarter did note that the OpenHEVC (https://github.com/OpenHEVC) folk were also making their own decoder, and using HM + smarter's decoder to test results against.

...
< JEEB> openhevc
< JEEB> some french project of some uni
<@BBB> they're doing an encoder?
< JEEB> they're just using HM as far as I can see
< JEEB> using it as a lib
<@BBB> so what are they using his code for then?
< JEEB> they're using it as the decoder it seems
<@BBB> maybe hm is too slow
< smarter> nop, they're doing a decoder for http://orcc.sourceforge.net/
...

sl1pkn07

29th January 2013, 21:24

hi

im build on my linux

588K ene 29 21:04 TAppDecoderStatic
3,3M ene 29 21:04 TAppDecoderStaticd
1023K ene 29 21:04 TAppEncoderStatic
4,5M ene 29 21:04 TAppEncoderStaticd
26K ene 29 21:04 annexBbytecountStatic
95K ene 29 21:04 annexBbytecountStaticd
89K ene 29 21:04 convert_NtoMbit_YCbCrStatic
398K ene 29 21:04 convert_NtoMbit_YCbCrStaticd

what is need and what diference between "d" and without "d"?

and "found" this:

http://hevc.info/
svn -> https://hevc.hhi.fraunhofer.de/svn/svn_HEVCSoftware/trunk

its different branch?

greetings

paradoxical

29th January 2013, 21:32

With "d" means debug build. Without "d" means release build.

JEEB

29th January 2013, 21:32

TAppDecoder is the decoder, and TAppEncoder is the encoder, annexBbytecount seems to be some test app and convert_NtoMbit_YCbCr helps you convert raw YCbCr streams' bit depths it seems. You will mostly need the encoder and decoder I would guess.

I would guess the ones with a 'd' are debug binaries, and the static at the end means they've been statically linked as opposed to shared linking.

That SVN repository should be the same thing, also hosted over at the BBC, as well as having a git mirror over at the BBC. I felt that the git mirror was simplest to use, so I picked it :)

sl1pkn07

29th January 2013, 21:59

oks, thanks for all guys (the static is obious XD, but with D have doubts)

mandarinka

30th January 2013, 01:12

BTW I noticed that DivX announced they will be jumping on H.265 too, apparently they will have some transcoding application (based on Mainconcept) and likely decoder too. No idea when they plan to release, if it is soon, it might be useful for some time before FOSS land reacts :)

xooyoozoo

31st January 2013, 03:31

Took some time, but finally started trying to build this ( http://i.imgur.com/MQhJgT2.png ) up using the HEVC bitstreams as reference points. I haven't gotten around to all the encodes yet, but I doubt the comparative numbers would change much beyond what you see now. You can read the cells in light green as "HEVC will reduce bitrate by [x]", and their story is fairly similar to all the "official" HEVC-AVC comparisons seen so far. (Edit: I assume that 8bit x264 would 5-10% worse? Anyone know?)

I thought about doing a SSIM comparison too, but I don't think that would tell us much other than that reference encoders are really naive (Edit: HEVC actually gets higher SSIM; I just haven't charted it), which is entirely par for the course.

The spreadsheet with its underlying equations were shameless copied from the JCT-VC docs site, btw.

Last edit: Looking at published results, PSNR difference between reference h264 encoder and x264 High10 veryslow|tune-psnr is irrelevantly small. No more of this "it's just the JM" business. ;)

edison

2nd February 2013, 09:46

Took some time, but finally started trying to build this ( http://i.imgur.com/MQhJgT2.png ) up using the HEVC bitstreams as reference points.

hmm, can you tell me how to measure the PSNR (maybe SSIM too) when the origin file is 8-bit and the encoded file is 10bit ?

xooyoozoo

2nd February 2013, 21:54

hmm, can you tell me how to measure the PSNR (maybe SSIM too) when the origin file is 8-bit and the encoded file is 10bit ?

The PSNR is reported by the encoder?

Beyond that, I'd argue "downsampling" to 8bit creates a strictly accurate measurement in this scenario as any decoder would have to do the same thing for 99% of devices.

Also, this ( http://qpsnr.youlink.org/ ) app depends on libav to decode images. I haven't tested it, but it should be fairly flexible as a result.

edison

5th February 2013, 04:34

The PSNR is reported by the encoder?

Beyond that, I'd argue "downsampling" to 8bit creates a strictly accurate measurement in this scenario as any decoder would have to do the same thing for 99% of devices.

Also, this ( http://qpsnr.youlink.org/ ) app depends on libav to decode images. I haven't tested it, but it should be fairly flexible as a result.

My results:

ChinaSpeed_1024x768_30.yuv

H.265 JCT-VC HM 9.2 r3282 build-in_cfg: ra_main (2,734,212 bytes): 0.9506898 SSIM (500 frames)
H.264 x264 0.129.2230 "megui anime toons insane 2-pass" 1370kbps (2,830,294 bytes): 0.9420076 SSIM (500 frames)
H.265 JCT-VC HM 9.2 r3282 build-in_cfg: ra_he10 (2,720,498 bytes) decoded as 8-bit (I420 YUV): 0.9510426 SSIM (500 frames)

I don't know how to input 10-bit I420 into avisynth script that I used for SSIM value measure(http://forum.doom9.org/showthread.php?t=167103).

JEEB

5th February 2013, 08:01

HM 10.0 final was released last night, here (http://x264.fushizen.eu/builds/hevc-hm/hm_10.0_r3352_release.7z) is a build for it.

There is a bug fix for HM 10.0 rc1 that basically makes rc1-encoded files undecode'able with it, just so you know (in addition to previous version's streams probably failing with it, too).

MasterNobody

10th February 2013, 19:19

I did my own little codec comparison on the first 201 frames of park_joy 1080p sample (http://media.xiph.org/video/derf/y4m/park_joy_1080p50.y4m). Sample was encoded as 25fps instead of 50fps for easier watching during comparison (so it is 2x slowed down).

For comparison this versions of encoders was used (used_bin.zip (http://www.mediafire.com/?a5zx3x1rrxm869r) or mirror (http://www.sendspace.com/file/bwd5k1)):
HM-10.0 git-538e6fe
VP8/VP9 Encoder v1.2.0-1570-g7f5e4fd
x264 0.129.2245 bc13772

Encoding params: park_joy_params.txt (http://privatepaste.com/49a4ffcc26)
Encoded samples: encoded_samples.zip (http://www.mediafire.com/?nddua2977kzzon7) or mirror (http://www.sendspace.com/file/qrjm33)
Screenshots of frame #100: screenshots.zip (http://www.mediafire.com/?a4ux3rohmsyk7e8) or mirror (http://www.sendspace.com/file/f9j9l6)

Note: VP9 missed target bitrate of ~7000 kbit/s so it have little bit smaller file size but I doubt difference was significant enough to change anything in results. Also I didn't have time (8 hours) to remake sample with higher target bitrate (without confidence that it wouldn't miss it again).

APSNR_YUV:
H.265/HEVC 31.2758
VP9 30.2742
VP8 29.7419
x264_qp 30.5967
x264_crf_cqp 30.4806
x264_crf 30.7392
x264_crf_psy 29.9721
OPSNR_YUV:
H.265/HEVC 31.1003
VP9 30.0838
VP8 29.5136
x264_qp 30.4833
x264_crf_cqp 30.2792
x264_crf 30.6451
x264_crf_psy 29.8869

SSIM_YUV:
H.265/HEVC 0.8638
VP9 0.8359
VP8 0.8214
x264_qp 0.8277
x264_crf_cqp 0.8289
x264_crf 0.8596
x264_crf_psy 0.8502
SSIM_YUV (dB):
H.265/HEVC 8.6582
VP9 7.8489
VP8 7.4811
x264_qp 7.6371
x264_crf_cqp 7.6674
x264_crf 8.5263
x264_crf_psy 8.2448

And now my subjective opinion:
H.265/HEVC - impressive. It is definitely visually better than H.264. I would say quality of HM-10.0 better then what x264 can do without varying QPs on MB-level with AQ/MBTree (x264_crf_cqp), on par when you allow such varying (x264_crf), and little bit worse if you will allow x264 to use psy optimizations also (x264_crf_psy).
VP9 - not really impressive. Yes, it is better than VP8 but that is all. Quality is worse than H.265/HEVC or x264 (x264_crf or x264_crf_psy). While quality is better than x264_crf_cqp I wouldn't call such comparison correct because VP9 wasn't limited to one QP per frame as H.265/HEVC was. And if they didn't take advantage of such thing in VP8 I doubt they will/can do in VP9.

P.S. Both HM-10.0 and VP9 are unbelievable slow (7-9 hours for this 201 frame 1080p sample). That is probably 10 times slower than x264 without asm-optimizations and with single thread.

Selur

10th February 2013, 19:59

the mediafire download of the used binary has been removed for violation :(

Snowknight26

10th February 2013, 20:13

All of them have.

MasterNobody

10th February 2013, 20:27

Added sendspace mirrors. btw mediafire links work ok for me so dunno what wrong with them (may be something new in there sharing policy).

easyfab

10th February 2013, 21:51

Can you also add JM h.264 reference encoder to see difference between hevc and avc reference encoder . Because x264 is alot better than JM and I think futur Hevc encoder will be better than HM

edison

11th February 2013, 03:28

MasterNobody

11th February 2013, 06:39

hmm... why use HM10 QP32 vs x264 QP35 ?
Because we compare quality at the same bitrate/size and not at some abstact QP value that doesn't have any meaning outside of used codec.

iwod

11th February 2013, 13:19

Exciting time. In fact there has never been a Reference Encoder that beats its previous best implementation. HEVC is the first.

I am not sure if we could get a gigantic leap like we did from H.264 reference to x264. But if we do then HEVC is looking great, along with its Picture Format. Hopefully we can finally get rid of jpeg for good.

xooyoozoo

15th February 2013, 06:37

It occurred to me that subjective comparisons of encoders at the same filesizes are a bit limiting because there's really no intuitive link between relative fidelity and relative bitrates. To partially address that (and to humor my curiosity ;)), here's a little exercise: what happens if you accept all the purported bit savings and act accordingly? As in, how would x264 perform at half of MPEG2's bitrate and double HEVC's?

I'm going to take the QP32 versions of two 1080p HM10 bitstreams, Kimono and BasketballDrive (ftp://ftp.kw.bbc.co.uk/hevc/hm-10.0-anchors/bitstreams/ra_main/), and compare it against x264, ffmpeg MPEG-4, ffmpeg MPEG-2 at 200%, 300%, 400% of HEVC's bitrate, respectively. I'm also throwing in VP9, and based on some other results (http://forum.doom9.org/showthread.php?p=1614397#post1614397), I'm going to assume that VP9 can handle itself at 170% of HEVC's bitrate. Theoretically, all of these clips should be equally preferable.

All encoders had key intervals set to match HEVC's one per second and, where possible, open GOP was set. VP9 was also built using yesterday's latest experimental branch and with switched on experiments to get a sense of its bleeding edge code. Here's some exact details on that, along with command line settings (http://privatepaste.com/82e5c8e646) for everything else.

Kimono 1080p24
1068 HEVC (https://mega.co.nz/#!bJcEGJYZ!WQUXZj3Rzx5rcbmKdfFeDmhruYwFi8CRJFnD_zoHrjg) playable*
1815 VP9 (https://mega.co.nz/#!uJEjgLhZ!CJcHKFhBeCmQrETru2kusjQwor0MYgp2_XyZG9xtVL4) playable*
2138 x264 (https://mega.co.nz/#!PUdlFJII!AafgVgXQQt5j5B0dI6X20ywm3NwW4MfGamG0KlgSxPI)
3207 MPEG4 (https://mega.co.nz/#!6EUUFLxC!ErC12zvL6pWeekQlh8pWhUcR1KA2gnYEuWXX6bP22EQ)
4276 MPEG2 (https://mega.co.nz/#!bMdH3YaB!TElDtk064CQcHLq9CuFgA3yA5nk8aWlLUFVfL3eQ1QI)

BasketballDrive 1080p50
2807 HEVC (https://mega.co.nz/#!qFdWSIJT!e2J8Pz8cMVKGsGUXLfwUxg3clqwhXs_e3xl4PjBFPDo) playable*
4770 VP9 (https://mega.co.nz/#!aMcG2JyC!QnlXQmuOYgmc5sPyi014PySrvslNHxyEpNoYBfLTiso) playable*
5614 x264 (https://mega.co.nz/#!2d1xRapL!BSz4YQXIWjpQDkXNn5HYAVcDv7woENtrPMPGltY_TK4)
8421 MPEG4 (https://mega.co.nz/#!mQEGHRKb!VY34rDzCMb1lAt6qDOEjAFTDZvVEx7HWLhOU9W8KIto)
11228 MPEG2 (https://mega.co.nz/#!zBl1FYyJ!XTfZVyDyXU0cwr5bWKbNAjEAmRRsMouEDOLCux2LJ_U)

*You're gonna have to trust me that being reencoded with CRF12 x264 is transparent to the original :D. If not, HM10 bitstreams are in the usual place, and you can build specifically for the VP9 ones (https://mega.co.nz/#!rJNzEI6a!bAbF_TPvbKvrbP9JMq5GQUduxchmywWjvdEASX6U35Y).

My own impressions:
HEVC is by far the cleanest, and in my opinion the most natural looking, with noise I'd have to squint to see and almost no temporal artifacts, which is a killer for the others. Note that this does comes at a cost of lowered details in the background, but of course, this is by far the most naive and stupid of the encoders used here.

x264 is then the opposite of the above, where its image has the most detail at the cost of large distortions. Notice the flickering in the bush leaves' motion and the shimmering surfaces in the basketball court.

VP9 is a mixture and averaging of the above situations.

MPEG4 and MPEG2 perform roughly as expected, with MPEG4 doing a bit worse than MPEG2. I guess I now see why the industry stuck with MPEG2 for so long. Also of note is that I originally used ffmpeg's libXVID but then discovered that its internal MPEG4 library is visually superior with my settings.

Overall? With HEVC at 100%, VP9 should be bumped slightly lower to maybe 150% (Edit: on second thought, past experience tells me that VP9 does start to pick up lots of distortions; it's likely good as is, but we can do 167% to get nice ratios). x264 and MPEG2 are in good spots relative to each other (1:2), but MPEG4 needs to move a bit closer to MPEG2. The latter three all need to move farther away from HEVC. Maybe x264 can start at 250%.

adkalkan

22nd March 2013, 12:57

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)

geoyo

27th March 2013, 02:06

pieter3d

28th March 2013, 05:56

Kurtnoise

1st April 2013, 07:19

Found an optimized reference HEVC encoder (http://mnhevc.com/request/)...

http://mnhevc.com/wp-content/uploads/2012/09/IPPP-Time_130304.png

xooyoozoo

1st April 2013, 20:53

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

Those are the bitrates for each encoder.

posdnya

10th April 2013, 14:24

xooyoozoo

10th April 2013, 18:57

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 (http://media.xiph.org/video/derf/). 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

11th April 2013, 01:30

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 (http://media.xiph.org/video/derf/). 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

11th April 2013, 05:41

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

11th April 2013, 06:19

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 (http://media.xiph.org/video/derf/). 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

11th April 2013, 06:21

Here's a visually transparent (x264 10bit CRF10), arbitrarily chosen scene from BBB done in the style of the two snapshots above: (96 MB) (https://mega.co.nz/#!PJ8xxAhA!Xyyi7yaeCa-uFHqHG6VjrWZ6Rx0a6Y0VrabcLQKCHEw). The visual examples all used the "handicapped" x264 encode.

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

xooyoozoo

11th April 2013, 06:33

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 (http://forum.doom9.org/showpost.php?p=1620230&postcount=62) 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

12th April 2013, 11:01

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 (http://forum.doom9.org/showpost.php?p=1620230&postcount=62) 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

17th April 2013, 10:31

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 (https://mega.co.nz/#!bM1ihDYL!VJr1qV8HPtsQ7Rl-iNIZJBYwXlwD3z1saVagr9h9q4E)) (lupo (https://mega.co.nz/#!TI9GmBAa!Qe0x23kW19qaP2tgwYEigjl8utExPGJFsp8idYnX9fI)) (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

27th April 2013, 15:48

Some time ago HM 10.1 was released. I built a 32bit Windows binary, and it is available here (http://x264.fushizen.eu/builds/hevc-hm/hm_10.1_r3419_release.7z) (configuration file folder included).

sl1pkn07

27th April 2013, 16:34

any fix to build with gcc 4.8?

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

foxyshadis

4th May 2013, 03:24

Use -Wno-array-bounds?

sl1pkn07

4th May 2013, 03:53

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

thanks foxyshadis for giving me light

greetings :)

IgorC

4th May 2013, 23:24

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

14th May 2013, 11:03

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

thanks very much ~

JEEB

14th May 2013, 16:25

ITU-T's Last Call only takes a month so ITU-T Recommendation H.265 (http://www.itu.int/ITU-T/recommendations/rec.aspx?rec=11885) 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 (http://www.iso.org/iso/catalogue_detail.htm?csnumber=35424) (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.