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. |
29th January 2013, 21:24 | #61 | Link |
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 |
29th January 2013, 21:32 | #63 | Link |
もこたんインしたお!
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]
|
30th January 2013, 01:12 | #65 | Link |
Registered User
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
|
31st January 2013, 03:31 | #66 | Link |
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. |
2nd February 2013, 09:46 | #67 | Link | |
Registered User
Join Date: Dec 2005
Posts: 106
|
Quote:
|
|
2nd February 2013, 21:54 | #68 | Link | |
Registered User
Join Date: Dec 2012
Posts: 197
|
Quote:
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. |
|
5th February 2013, 04:34 | #69 | Link | |
Registered User
Join Date: Dec 2005
Posts: 106
|
Quote:
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. |
|
5th February 2013, 08:01 | #70 | Link |
もこたんインしたお!
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]
|
10th February 2013, 19:19 | #71 | Link |
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 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 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 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 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 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. |
11th February 2013, 03:28 | #76 | Link | |
Registered User
Join Date: Dec 2005
Posts: 106
|
Quote:
|
|
11th February 2013, 13:19 | #78 | Link |
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. |
15th February 2013, 06:37 | #79 | Link |
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:
BasketballDrive 1080p50 2807 HEVC playable* 4770 VP9 playable* 5614 x264 8421 MPEG4 11228 MPEG2 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. |
22nd March 2013, 12:57 | #80 | Link |
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) |
Tags |
hevc. h.265 |
Thread Tools | Search this Thread |
Display Modes | |
|
|