Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Video Encoding > High Efficiency Video Coding (HEVC)

Reply
 
Thread Tools Search this Thread Display Modes
Old 29th January 2013, 21:24   #61  |  Link
sl1pkn07
Pajas Mentales...
 
Join Date: Dec 2004
Location: Spanishtán
Posts: 496
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
sl1pkn07 is offline   Reply With Quote
Old 29th January 2013, 21:32   #62  |  Link
paradoxical
Guest
 
Posts: n/a
With "d" means debug build. Without "d" means release build.
  Reply With Quote
Old 29th January 2013, 21:32   #63  |  Link
JEEB
もこたんインしたお!
 
JEEB's Avatar
 
Join Date: Jan 2008
Location: Finland / Japan
Posts: 512
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
__________________
[I'm human, no debug]
JEEB is offline   Reply With Quote
Old 29th January 2013, 21:59   #64  |  Link
sl1pkn07
Pajas Mentales...
 
Join Date: Dec 2004
Location: Spanishtán
Posts: 496
oks, thanks for all guys (the static is obious XD, but with D have doubts)
sl1pkn07 is offline   Reply With Quote
Old 30th January 2013, 01:12   #65  |  Link
mandarinka
Registered User
 
mandarinka's Avatar
 
Join Date: Jan 2007
Posts: 729
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
mandarinka is offline   Reply With Quote
Old 31st January 2013, 03:31   #66  |  Link
xooyoozoo
Registered User
 
Join Date: Dec 2012
Posts: 197
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.

Last edited by xooyoozoo; 31st January 2013 at 05:14.
xooyoozoo is offline   Reply With Quote
Old 2nd February 2013, 09:46   #67  |  Link
edison
Registered User
 
Join Date: Dec 2005
Posts: 106
Quote:
Originally Posted by xooyoozoo View Post
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 ?
edison is offline   Reply With Quote
Old 2nd February 2013, 21:54   #68  |  Link
xooyoozoo
Registered User
 
Join Date: Dec 2012
Posts: 197
Quote:
Originally Posted by edison View Post
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.

Last edited by xooyoozoo; 2nd February 2013 at 22:03.
xooyoozoo is offline   Reply With Quote
Old 5th February 2013, 04:34   #69  |  Link
edison
Registered User
 
Join Date: Dec 2005
Posts: 106
Quote:
Originally Posted by xooyoozoo View Post
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).

Last edited by edison; 5th February 2013 at 06:22.
edison is offline   Reply With Quote
Old 5th February 2013, 08:01   #70  |  Link
JEEB
もこたんインしたお!
 
JEEB's Avatar
 
Join Date: Jan 2008
Location: Finland / Japan
Posts: 512
HM 10.0 final was released last night, here 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).
__________________
[I'm human, no debug]
JEEB is offline   Reply With Quote
Old 10th February 2013, 19:19   #71  |  Link
MasterNobody
Registered User
 
Join Date: Jul 2007
Posts: 552
H.265/HEVC vs VP9 vs x264

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).

For comparison this versions of encoders was used (used_bin.zip or mirror):
Code:
HM-10.0 git-538e6fe
VP8/VP9 Encoder v1.2.0-1570-g7f5e4fd
x264 0.129.2245 bc13772
Encoding params: park_joy_params.txt
Encoded samples: encoded_samples.zip or mirror
Screenshots of frame #100: screenshots.zip or mirror

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:
Code:
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:
Code:
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:
Code:
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):
Code:
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.

Last edited by MasterNobody; 10th February 2013 at 20:25.
MasterNobody is offline   Reply With Quote
Old 10th February 2013, 19:59   #72  |  Link
Selur
Registered User
 
Selur's Avatar
 
Join Date: Oct 2001
Location: Germany
Posts: 7,259
the mediafire download of the used binary has been removed for violation
__________________
Hybrid here in the forum, homepage
Selur is offline   Reply With Quote
Old 10th February 2013, 20:13   #73  |  Link
Snowknight26
Registered User
 
Join Date: Aug 2007
Posts: 1,430
All of them have.
Snowknight26 is offline   Reply With Quote
Old 10th February 2013, 20:27   #74  |  Link
MasterNobody
Registered User
 
Join Date: Jul 2007
Posts: 552
Added sendspace mirrors. btw mediafire links work ok for me so dunno what wrong with them (may be something new in there sharing policy).
MasterNobody is offline   Reply With Quote
Old 10th February 2013, 21:51   #75  |  Link
easyfab
Registered User
 
Join Date: Jan 2002
Posts: 332
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
easyfab is offline   Reply With Quote
Old 11th February 2013, 03:28   #76  |  Link
edison
Registered User
 
Join Date: Dec 2005
Posts: 106
Quote:
Originally Posted by MasterNobody View Post
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).
hmm... why use HM10 QP32 vs x264 QP35 ?
edison is offline   Reply With Quote
Old 11th February 2013, 06:39   #77  |  Link
MasterNobody
Registered User
 
Join Date: Jul 2007
Posts: 552
Quote:
Originally Posted by edison View Post
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.
MasterNobody is offline   Reply With Quote
Old 11th February 2013, 13:19   #78  |  Link
iwod
Registered User
 
Join Date: Apr 2002
Posts: 756
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.
iwod is offline   Reply With Quote
Old 15th February 2013, 06:37   #79  |  Link
xooyoozoo
Registered User
 
Join Date: Dec 2012
Posts: 197
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, 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, 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 for everything else.

Code:
Kimono 1080p24
1068 HEVC playable*
1815 VP9  playable*
2138 x264
3207 MPEG4
4276 MPEG2
Code:
BasketballDrive 1080p50
 2807 HEVC playable*
 4770 VP9  playable*
 5614 x264
 8421 MPEG4
11228 MPEG2
*You're gonna have to trust me that being reencoded with CRF12 x264 is transparent to the original . If not, HM10 bitstreams are in the usual place, and you can build specifically for the VP9 ones.

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%.

Last edited by xooyoozoo; 15th February 2013 at 07:07.
xooyoozoo is offline   Reply With Quote
Old 22nd March 2013, 12:57   #80  |  Link
adkalkan
Registered User
 
Join Date: Feb 2013
Posts: 1
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)
adkalkan is offline   Reply With Quote
Reply

Tags
hevc. h.265

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 17:33.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.