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

qwddn

15th May 2013, 03:27

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.

First, thanks for your kindly help.
I go ITU HEVC website( http://www.itu.int/rec/T-REC-H.265-201304-P ), it seems that the pre-published spec is only available for TIES users and Subscribers... The newest version I have is JCTVC-L1003 (version 34), So could you please tell me where I can download HEVC-version-1 ? is it free to download now ?

thanks again~

JEEB

15th May 2013, 07:52

it seems that the pre-published spec is only available for TIES users and Subscribers...
Yes, because it's currently available for purchase? With AVC/H.264 the current spec was only available for one to buy for the first six or so months, after which it was released to be available for free. No idea if they will keep such an official free way of distribution with HEVC/H.265.
The newest version I have is JCTVC-L1003 (version 34)
That is what I noted as the "last draft (that) was uploaded onto JCT-VC's document tracker", that was pushed onto the ITU-T Last Call and ISO/IEC FDIS ballot.
So could you please tell me where I can download HEVC-version-1 ? is it free to download now ?
If you want the thing that came out of the ballots, and not the one that went into the ballots, I have already linked you the ITU-T page from which you can already buy it from. No, it is not free to download now, but might become in six months or so depending on if ITU-T and ISO/IEC will do the same thing they did with AVC/H.264 regarding free publication.

In any case, this is IMHO enough spec-specific talk on the "Available HEVC/H.265 test encoders" thread, there is a generic HEVC/H.265 thread (http://forum.doom9.org/showthread.php?t=165673) around as well :P

qwddn

15th May 2013, 15:20

Yes, because it's currently available for purchase? With AVC/H.264 the current spec was only available for one to buy for the first six or so months, after which it was released to be available for free. No idea if they will keep such an official free way of distribution with HEVC/H.265.

That is what I noted as the "last draft (that) was uploaded onto JCT-VC's document tracker", that was pushed onto the ITU-T Last Call and ISO/IEC FDIS ballot.

If you want the thing that came out of the ballots, and not the one that went into the ballots, I have already linked you the ITU-T page from which you can already buy it from. No, it is not free to download now, but might become in six months or so depending on if ITU-T and ISO/IEC will do the same thing they did with AVC/H.264 regarding free publication.

In any case, this is IMHO enough spec-specific talk on the "Available HEVC/H.265 test encoders" thread, there is a generic HEVC/H.265 thread (http://forum.doom9.org/showthread.php?t=165673) around as well :P

thank you for your info.
I will post my question in the right thread!soooorry~:D

SeeMoreDigital

15th May 2013, 16:55

Is there any information yet regarding container support for HEVC/H.265?

By-the-way, when it comes to the .MKV container. It looks as though Mosu could do with a hand (http://forum.doom9.org/showthread.php?p=1623148)...

JEEB

15th May 2013, 17:15

Is there any information yet regarding container support for HEVC/H.265?
GPAC is implementing HEVC-in-"mp4", which is an extension of 14496-15 (AVC File Format, the mapping of AVC in "mp4") as we speak, but they seem to be the only ones with the up-to-date specs. I've poked smarter about it since he seems to be in contact with those guys, and the response I've gotten via him is that the draft (http://x264.fushizen.eu/random/29n13120t.pdf) that used to be publicly available is by now outdated, and that only they have access to MPEG's "secret stashes" where the current version lies.

L-SMASH and libavformat are both interested in implementing it for obvious reasons, but this kind of "co-operation" doesn't work, because GPAC has always been known for at times not doing things "by the book". The HEVC addition to 14496-15 should be finalized by July 2013.

There's also "Transport of HEVC video over MPEG-2 systems", which is basically a HEVC mapping for MPEG-2 TS/PS. Also to be finalized in July.

By-the-way, when it comes to the .MKV container. It looks as though Mosu could do with a hand (http://forum.doom9.org/showthread.php?p=1623148)...
I did start a thread (http://lists.matroska.org/pipermail/matroska-devel/2013-April/004440.html) on matroska-devel about it... it should have plenty of references for people interested in these things.

SeeMoreDigital

15th May 2013, 17:29

Many thanks JEEB. Your information is most reassuring :)

Kurtnoise

16th May 2013, 17:20

The DivX labs (http://labs.divx.com/node/127884) has published a draft (http://labs.divx.com/system/files/DivX_HEVC_Video_Profiles_DRAFTMay2013.pdf) mentioned the new HEVC Video Profiles (4K, 1080p, 720p) from their next products...

mandarinka

24th May 2013, 02:52

Hmm, main profile...
Seamless resolution switching is great, however mod8 being mandatory is just sloppy.
I think it is shortsighted from them to ignore 48 Hz as a framerate. True, eventually that speed might not be adopted for real, but it seems that content is already being produced with it.

SubJunk

30th May 2013, 05:28

I think The Hobbit series will be the only films ever made with 48Hz. Other high framerate films will likely be 60Hz instead, like James Cameron has stated.

benwaggoner

30th May 2013, 18:59

I think The Hobbit series will be the only films ever made with 48Hz. Other high framerate films will likely be 60Hz instead, like James Cameron has stated.
Yes, the Lightstorm demos make an excellent case for 60 over 48. And 60 is certainly a lot more compatible with existing display hardware. I expect it'll become the dominant HFR standard over time.

But there is at least one other film announced to be in 48: Andy Serkis's adaption of Animal Farm.
http://www.hollywoodreporter.com/news/andy-serkis-animal-farm-381314

Also, AFAIK Unexpected Journey was the 2nd film shot at 48p, after the IMAX HD film Momentum. Which I remember being blown away by as a teenager at the Vancouver BC Expo '86.
http://en.wikipedia.org/wiki/Momentum_(IMAX_film)

Back to HEVC, we know that HEVC's bits-per-pixel requirements drop a lot more as frame size goes up compared to older codecs. I wonder if HEVC will be better than past formats at higher frame rates?

SeeMoreDigital

6th June 2013, 22:03

Yes, the Lightstorm demos make an excellent case for 60 over 48. And 60 is certainly a lot more compatible with existing display hardware. For North America (and Japan) maybe... But 50p already works perfectly in Euroland ;)

mandarinka

6th June 2013, 22:52

Hmm, 48 Hz also has the downside that it doesn't match properly on a 120 Hz screen, unlike 24, 30 and 60 fps. Aw (25/50 Hz are also trouble of course).

SubJunk

7th June 2013, 00:52

25p and 50p can't die soon enough! Thankfully it's being phased out.

benwaggoner

11th June 2013, 18:20

25p and 50p can't die soon enough! Thankfully it's being phased out.
For production, maybe. 24p, 60p, or higher are the only things anyone should be shooting for content with any meaningful lifespan.

But as long as people still watch Doctor Who or Top Gear, we'll still need 25/50 for playback. So, forever.

I get annoyed when 18 fps isn't explicitly supported for encoding, since that's what the first decades of pre-sound cinema are all in.

SeeMoreDigital

11th June 2013, 18:25

Thankfully it's being phased out.Says who?

SubJunk

11th June 2013, 22:28

For production, maybe. 24p, 60p, or higher are the only things anyone should be shooting for content with any meaningful lifespan.

But as long as people still watch Doctor Who or Top Gear, we'll still need 25/50 for playback. So, forever.Yeah you're right, Downton Abbey too. I just hope those shows can start being done at 24p instead in the future.

Says who?I live in a PAL country and all our DVDs are 25FPS but the blu-rays are at their native framerate (almost always 24p), as are all the web downloads and films at the cinema. Since a lot of stores are either stopping selling DVDs in favour of blu-rays, or shutting down because people are downloading/streaming everything, it seems to me that it's going to be hard to find 25FPS content for sale soon since 99.99+% of it was converted from NTSC. Real 25p content might not go anywhere though, I just hope it does.

benwaggoner

11th June 2013, 23:57

Yeah you're right, Downton Abbey too. I just hope those shows can start being done at 24p instead in the future.
Sure, but I'd still want to be able to watch the PAL content at its original frame rate, and thus its original speed.

I live in a PAL country and all our DVDs are 25FPS but the blu-rays are at their native framerate (almost always 24p), as are all the web downloads and films at the cinema.
Web downloads? Since almost all web/IP clients can support arbitrary frame rates, I'd expect a lot more content to remain in native frame rate.

We certainly deliver 25p content as 25p in NTSC countries, and 24/30 content as 24/30 in PAL countries.

SubJunk

12th June 2013, 00:22

Yeah same here, I agree with you. My main complaint about 25p is that it's almost always converted from 24p. Native 25p content should not be converted.

JEEB

14th June 2013, 11:43

HM 11.0 has been released. I built a 32bit Windows binary of the decoder and encoder, and they are available here (http://x264.fushizen.eu/builds/hevc-hm/hm_11.0_r3513_release.7z) (configuration file folder included).

The biggest change now is that the configuration files actually contain the profile and level. Before this, unless you actually remembered to add those two, your streams would be invalid.

Compared to the release candidate we decided to revert a patch that caused problems with conformance test bitstreams. We also made a change to only warn when profile and level are not set instead of failing.

Compared to HM 10.1, HM 11.0 contains changes for rate control and a number of bug fixes. Performance in the common test conditions is not changed. We will still provide updated anchors with valid profile/level values within the next days.

Please note, that there are still quite a few open issues in the bug tracker. Most of them are related to high level issues like parameter set handling and reference picture sets.

Any help with fixing these issues and reviewing patches, especially regarding conformance issues, are highly appreciated.

For details see:

https://hevc.hhi.fraunhofer.de/trac/hevc/report/16

RBF

3rd July 2013, 07:56

Strongene HEVC/H.265 Encoder (http://xhevc.com/en/downloads/downloadCenter.jsp)

fumoffu

4th July 2013, 05:11

Strongene HEVC/H.265 Encoder (http://xhevc.com/en/downloads/downloadCenter.jsp)

the readme.txt file in encoder wasn't displaying for me correctly, I fixed character set and google translated from Chinese. Result in attachment..

war59312

8th July 2013, 22:29

I really don't understand how to use it.

I successfully installed it and all three show up. See attachment please.

But MPC-HC simply states "Cannot render the file" when I try and play the sample H265 videos from http://xhevc.com/ .

Update: OK it's just FLV files that have this problem even though it says the current decoder supports them, it seems it does NOT.

afd_720p.hm10 and afd_1080p.hm10 play back just fine now in MPC-HC. :) Note: Resuming does NOT work yet.

afd_1080p.hm10 (full-screen), uses around 6.5% of my Intel Core i7 930 CPU. Not bad at all.

edison

9th July 2013, 18:23

Here is a guide for the encoder : http://www.cnbeta.com/articles/244065.htm.

Sagittaire

11th July 2013, 16:55

Well I test Strongene HEVC/H.265 Encoder and first result for this implementation is:
- H265 is unable to produce same quality than x264 at half bitrate (metric)
- H265 is able to produce same quality than xvid at half bitrate (metric)

It's already really impressive H265 implementation for a first test. H265 is really better visualy than x264 at same bitrate and by far. The most impressive is IMO the temporal stability for H265.

SeeMoreDigital

11th July 2013, 17:18

Sagittaire,

Out of interest... Did you view your HEVC test files using a dedicated HEVC decoder - if so, which one? Or did you convert your HEVC test files to a lossless video format before viewing?

Sagittaire

11th July 2013, 18:29

I use Strongene HEVC/H.265 decoder DSFilter with compatible DSFilter like MPC or WMP ...

fumoffu

11th July 2013, 18:45

Well I test Strongene HEVC/H.265 Encoder and first result for this implementation is:
- H265 is unable to produce same quality than x264 at half bitrate (metric)

I'm experimenting with this encoder too.
Did you compared it with x264 1pass?
also I suspect HEVC advantage is bigger if there is a lot of movement, like hand held camera (95% of porn ;p) or FPP game footage.

Sagittaire

11th July 2013, 19:15

I'm experimenting with this encoder too.
Did you compared it with x264 1pass?
also I suspect HEVC advantage is bigger if there is a lot of movement, like hand held camera (95% of porn ;p) or FPP game footage.

I use x264 10 bits in crf mode with placebo setting (extreme and best possible situation for x264)
I use H265 in quantizer mode.

At same bitrate H265 is clearly better in absolutly all the situations. I test with various trailer (slow motion, high motion, anime ...). Anyway H265 is really unable to approch x264 quality at half bitrate. H265 marketing say 50% for bitrate reduction ... but it's more something like 25 or 30% actualy with this implementation. The best H265 implementation will be (perhaps) able to make that in future but certainely after many years.

lainiwaku

12th July 2013, 11:28

Sagittaire

12th July 2013, 16:46

i hope so , because people said h265 is for 4k,
but when i see that most of people think x264 still too much big file for 1080p content
h265 will just be acceptable size for 1080p file, 4k will still too big even with h265

well H265 will be not only for 4k movie. Moreover x264 work really well for 1080p movie: I think that it's possible to encode 90% of movie in DVD5 with really high quality if you use good filtering and good profil for codec (adaptative avisynth filtering, aac 5.1 in vbr mode, good x264 profil).

benwaggoner

12th July 2013, 17:12

well H265 will be not only for 4k movie. Moreover x264 work verry well for 1080p movie: I think that it's possible to encode 90% of movie in DVD5 with really high quality if you use good filtering and good profil for codec (adaptative avisynth filtering, aac 5.1 in vbr mode, good x264 profil).
First, if I may be allowed a bit of pedantry.

4K (http://en.wikipedia.org/wiki/4K_resolution)is a film industry specification, for 4096 wide video in post and digital projection.
For TVs it is properly "Ultra high definition television (http://en.wikipedia.org/wiki/Ultra_High_Definition_Television)" - UHD or UHDTV. UHD today is 3840x2160. While the 14% difference in pixels isn't going to be material from a quality perspective, these are different formats. UHD also mandates support for Rec. 2020 color as well (although that requires 10-bit sources anyway).

People call UHD 4K often as a shorthand, but I think we're better off being more specific in what we're talking about.

But back to the point, as far as bitrates required go, UHD is going to need a lot fewer bits per pixel than 1080p. First, detail isn't fractally dense, and 4x the pixels doesn't make anywhere near 4x the detail or 4x the high frequencies.

Second, and a bigger deal, viewers simply aren't going to be close enough to the screen to keep pixels at the same portion of the visual field as they do today. And even today most people are a lot farther than the THX recommended distance from their displays. Encoded at the same bitrate, only a minority would even notice the difference in film/video moving image content between 720p and 1080p on their 1080p display. For a 1080p 55" display, optimal viewing distance is about six feet. For a 1080p 55" display, optimal viewing distance would be three feet. That's just uncomfortably close because it requires head movement to track motion at the corners of the screen.

UHD might need maybe twice the bitrate of 1080p in H.264 to provide the available quality improvement in real-world viewing environments.

Given HEVC's better compression efficiency, particularly at higher frame sizes, a mature HEVC encoder might well be able to deliver UHD content at today's H.264 1080p bitrates.

Sagittaire

12th July 2013, 18:41

But back to the point, as far as bitrates required go, UHD is going to need a lot fewer bits per pixel than 1080p. First, detail isn't fractally dense, and 4x the pixels doesn't make anywhere near 4x the detail or 4x the high frequencies.

I post a good model for calcul that many years ago on doom9:
http://forum.doom9.org/showthread.php?t=95122&highlight=quality%2Fpixel

with this model you can expect have the same quantizer encoding (aka same mathematical quality/pixel for the codec) in these situation:

|----------------|--------------------|--------------------|--------------------|
| | files sizes | bit/(pel*fps) | bit/(pel^0.75*fps) |
|----------------|--------------------|--------------------|--------------------|
| q20 3840*2160 | 11128 Kbps | 0.056 bpf | 3.00 sci |
| q20 2560*1440 | 6057 Kbps | 0.068 bpf | 3.00 sci |
| q20 1920*1080 | 3934 Kbps | 0.079 bpf | 3.00 sci |
| q20 1280*720 | 2141 Kbps | 0.097 bpf | 3.00 sci |
| q20 720*400 | 896 Kbps | 0.129 bpf | 3.00 sci |
| q20 640*360 | 757 Kbps | 0.137 bpf | 3.00 sci |
| q20 512*288 | 541 Kbps | 0.153 bpf | 3.00 sci |
| q20 480*270 | 491 Kbps | 0.158 bpf | 3.00 sci |
| q20 320*240 | 332 Kbps | 0.160 bpf | 3.00 sci |
|----------------|--------------------|--------------------|--------------------|

theorical exemple with x264 at constant quantizer q20

Second, and a bigger deal, viewers simply aren't going to be close enough to the screen to keep pixels at the same portion of the visual field as they do today. And even today most people are a lot farther than the THX recommended distance from their displays. Encoded at the same bitrate, only a minority would even notice the difference in film/video moving image content between 720p and 1080p on their 1080p display. For a 1080p 55" display, optimal viewing distance is about six feet. For a 1080p 55" display, optimal viewing distance would be three feet. That's just uncomfortably close because it requires head movement to track motion at the corners of the screen.

UHD might need maybe twice the bitrate of 1080p in H.264 to provide the available quality improvement in real-world viewing environments.

Given HEVC's better compression efficiency, particularly at higher frame sizes, a mature HEVC encoder might well be able to deliver UHD content at today's H.264 1080p bitrates.

Yes IMO 2160p will be not really big revolution for video. 1080p is already really high resolution for medium user. IMO in the futur the revolution will be (and must be) high temporal resolution (48p or 60p) with better space color than 4:2:0 YV12. IMO 1080p60 YUY mean really higher quality improvement than 2160p24 YV12. Anyway it's not a good deal for materiel constructor because the actual 1080p TV are potentialy compatible with this format.

benwaggoner

12th July 2013, 19:29

Yes IMO 2160p will be not really big revolution for video. 1080p is already really high resolution for medium user. IMO in the futur the revolution will be (and must be) high temporal resolution (48p or 60p) with better space color than 4:2:0 YV12. IMO 1080p60 YUY mean really higher quality improvement than 2160p24 YV12. Anyway it's not a good deal for materiel constructor because the actual 1080p TV are potentialy compatible with this format.
Yes, absolutely. 50/60p offers a huge quality improvement and is compatible with lots of existing devices. UHD will offer much smaller benefits with a lot more work.

I'm not sold on >4:2:0 being that helpful for 1080p, though. Chroma subsampling artifacts are really hard to see at high resolutions, and are essentially invisible with natural moving images.

>8-bit is good, because it reduces dithering.

Extra colors seem like they could be awesome if we had sources that actually did stuff with those colors. As it is I've not seem many real world examples. But Rec. 2020 is capable of doing a lot more than xvYCC in this category. I'm hoping and pushing for HEVC Main 10 to become the baseline for UHD devices so that Rec. 2020 support can be assumed.

It would be great to get 12-bit HEVC eventually so the high dynamic range (superbrights) feature of Rec. 2020 could be used. That is something that can really pop with the right sources and the right display technologies.

fumoffu

12th July 2013, 19:43

I use x264 10 bits in crf mode with placebo setting (extreme and best possible situation for x264)
I use H265 in quantizer mode.

At same bitrate H265 is clearly better in absolutly all the situations. I test with various trailer (slow motion, high motion, anime ...). Anyway H265 is really unable to approch x264 quality at half bitrate. H265 marketing say 50% for bitrate reduction ... but it's more something like 25 or 30% actualy with this implementation. The best H265 implementation will be (perhaps) able to make that in future but certainely after many years.

I have been reencoding some clips with Strongene encoder at Slow preset and bitrate 1200kbps for 720p and I must say I often prefered the output from what I have been getting from x264 at about 3000kbps (slow preset with subme 9 5-bframes and trellis disabled, crf20-21).
Yes, the some edges are a bit blurry but nice blurry, while x264 at low bitrates gives fuzzy edges. And I found that HEVC even at much lower bitrates better preserved delicate gradients. I guess perceived quality is a subjective thing...

I also have a quick question: I didn't try CQP mode yet - are the quantizer values the same as in x264 for given quality? (yes I know x264 uses CRF by default)

Sagittaire

12th July 2013, 20:02

I have been reencoding some clips with Strongene encoder at Slow preset and bitrate 1200kbps for 720p and I must say I often prefered the output from what I have been getting from x264 at about 3000kbps (slow preset with subme 9 5-bframes and trellis disabled, crf20-21).
Yes, the some edges are a bit blurry but nice blurry, while x264 at low bitrates gives fuzzy edges. And I found that HEVC even at much lower bitrates better preserved delicate gradients. I guess perceived quality is a subjective thing...

I also have a quick question: I didn't try CQP mode yet - are the quantizer values the same as in x264 for given quality? (yes I know x264 uses CRF by default)

well it's not valid comparison because you use really different RC for your test. Perhaps that your clip done better overall result with cbr. Use quantizer mode with H265 and compare with crf or quantizer mode with x264. I you want absolutly use cbr mode with H265 then use cbr mode with x264.

Sagittaire

13th July 2013, 09:31

I also have a quick question: I didn't try CQP mode yet - are the quantizer values the same as in x264 for given quality? (yes I know x264 uses CRF by default)

crf N for x264 and quantizer N for H265 produce similar bitrate ... ;-)

zerowalker

13th July 2013, 18:18

So does HEVC support 12bit?

I know 10bit can improve quality/size a lot in some cases where there are good gradients, and dark scenes etc.
Will 12bit be another leap?

I am guessing diminish returns.

sneaker_ger

13th July 2013, 19:10

So does HEVC support 12bit?

It's not standardized yet AFAIK, but it will probably come in the future (2014?). H.264 already supports up to 14 bit. I think the new BT.2020 directed at post-FullHD equipment even needs at least 10 or 12 bits to be fully used.

I know 10bit can improve quality/size a lot in some cases where there are good gradients, and dark scenes etc.
Will 12bit be another leap?

I am guessing diminish returns.

According to a post by Dark_Shikari that seems indeed to be the case. 10 bits would - compared to 8 bits - already reduce rounding errors by 75% (9 bits 50% - you get the idea...) and that also seems to be a sweet spot for speed optimizations. Plus H.265 has at least one additional tool against banding even at lower depths. (http://forum.doom9.org/showthread.php?p=1614299#post1614299)

Getting away from the numbers: just comparing 8 bit to 10 bit with the eyes, 10 bit encodings usually make the leap to transparency already. It can not get more than transparent. Maybe 12 to 16 bit can milk a few more percent quality/compression, but it will not be as astonishing as going from 8 to 10 bits.

JEEB

26th August 2013, 14:48

Whoops, seemingly didn't notice at all that HM 12.0 got released during the last two weeks. Not sure if there was an e-mail on the JCT-VC regarding it. In any case, 32bit Windows binaries of the decoder and encoder are available here (http://x264.fushizen.eu/builds/hevc-hm/hm_12.0_r3541_release.7z) (configuration file folder included).

filler56789

26th August 2013, 15:20

Thanks a lot, JEEB

:thanks:

xooyoozoo

5th September 2013, 20:27

"Rovi Launches DivX 10 (http://www.rovicorp.com/company/news-center/pressreleases/1434_17431.htm)" with HEVC decode/encode. The download link doesn't seem to be live yet?

JEEB

5th September 2013, 20:56

"Rovi Launches DivX 10 (http://www.rovicorp.com/company/news-center/pressreleases/1434_17431.htm)" with HEVC decode/encode. The download link doesn't seem to be live yet?
If you check the installer you get here (http://www.divx.com/downloads/divx/1), you will already get a DivX 10 installer, which also seems (http://puu.sh/4jMlD.png) to (http://puu.sh/4jMvJ.png) contain the HEVC plugin.

In other words, it indeed seems to be out :)

Too bad they're using their ad-hoc HEVC-in-Matroska thing specified here (http://labs.divx.com/node/127907). Matroska-devel more or less decided to wait for 14496-15 AMD2 (HEVC FF) to copy the extradata off of. And that still hasn't been pushed out for the last ballot :/ . Last I heard there really weren't any changes done to it for like over a month or so, either. It's just not being pushed out :s .

fumoffu

5th September 2013, 21:37

Thanks for the heads up. I'm testing it now. First thing I noticed is that the encoder uses only about 160MB of RAM (I'm re-encoding 720p wmv clip), which is pretty low and I'm not sure if this is a good sign... I'm guessing it must be using Wavefront Parallel Processing? Speed wise it's similar to Strongene encoder, and uses 90% of the CPU (4 cores), with rather small fluctuations. Quality - don't know I'm waiting for output...

Edit:
Quality is ok but I don't have time now to do serious x264 or Strongene HEVC comparison.
But the funny thing is that DivX player apparently needs over 800MB RAM for 720p playback... Memory leak? Bad optimization? Large decoder buffer? Might be the last one because CPU usage fluctuates between 0-10% (on 4 core i5 @4GHz).

xooyoozoo

6th September 2013, 09:22

Spent some time with the divx converter and its 'HEVC 1080p' preset on the astronaut Crew and Soccer (ftp://ftp.tnt.uni-hannover.de/pub/svc/testsequences/) clips. Note that the HEVC-MKV demuxer JEEB linked to only works when you compile it yourself. Currently, the prebuilt binary complains with divx's output.

There's definitely scene detection, though the detection is a bit too enthusiastic on the Crew clip. Keyints are at 5 secs, and the frame cadence resembles IBBBP (w/ fewer Bs when necessary). They also seem to have limited CTU size to 32x32, but that maybe that's automatic based on source resolution. At lower bitrates, the image sometimes has distinct block edges, which suggest they tweaked the loop filters.

Encoding speed is roughly half that of x264-veryslow. I wasn't impressed at all by visual quality, but I'll try testing the encoder with more clips some time later.