X265 vs DivX265

[DarrellS]

@racer-x,
It would be interesting to see tests in original 4k, because HEVC directed to this side.
And do not hesitate to share the original file

Exactly! I'm tired of seeing all the 720p tests when hevc is meant for UHD.

People bitch about all my tests with X265 ultrafast but it is the only speed that you can realistically compare with DivX265.

I started to post this earlier today but got sidetacked...



I wish that someone would test using 4k resolution test files since that is what hevc was intended to be used for.

I'm not seeing encodes three times faster than the last build. Version 1.2.24 would not encode 4k video at the fastest preset but had to be encoded using the faster preset (2) instead which encoded at 3.8 fps with my Q6600 CPU. That is 1 fps slower than the new encoder at faster preset.

Here are the speeds I got from a 3840x2160 test file...

DivX265-fastest: 5.1 fps - 11.6 MB - 6371 Kbps
DivX265-faster: 4.8 fps - 11.4 MB - 6233 Kbps
DivX265-balanced: 3.5 fps - 11.8 MB - 6490 Kbps
DivX265-higher: 1.9 fps - 9.8 MB - 5348 Kbps

The highest quality preset was so slow that it was going to take almost two hours to encode 360 frames before I cancelled the encode.

X265-UF: (at 5000000Kbps) 2.6 fps - 24.8 MB - 13.6 Mbps
X265-UF: (at 40000 Kbps) 2.2 fps - 28.1 MB - 15.4 Mbps

Q6600 CPU @ 2.4, 4 GB DDR2 1066 RAM (overclocking doesn't seem to be working. BIOS shows 333 FSB but CPUZ shows 266)

All my hevc encodes are at 40000 bitrate which is the limit for 3840x2160 hevc using DivX265.

DivX265-fastest: -i - -o "%(tempvideofile)" -br 40000 -aqo 1 -s %(width)x%(height) -v
DivX265-faster: -i - -o "%(tempvideofile)" -br 40000 -aqo 2 -s %(width)x%(height) -v
DivX265-balanced: -i - -o "%(tempvideofile)" -br 40000 -aqo 3 -s %(width)x%(height) -v
DivX265-higher quality: -i - -o "%(tempvideofile)" -br 40000 -aqo 4 -s %(width)x%(height) -v

Something I've noticed is that higher bitrate doesn't necessarily mean higher quality. Just that one preset is better at compression than another. IMO, since hevc is designed to create same quality at lower bitrates then the old thinking that higher bitrate means higher quality is thrown out the window. The eye is the judge when it comes to hevc. I believe where it will shine is photography and animations where there is not a lot of change from one frame to the next which is why all of my testing is on high resolution PSD files from Photoshop converted to uncompressed AVI files and compressed to hevc files in Virtualdub since I can edit and set framerate and use the external encoder feature for the CLI x265 encoders. This is nothing new to me since I've been creating these same types of high resolution animations for a few years now using x264.

[hello_hello]

1200kps for 1080p?!? of course divx265 had poor quality compared to x265, it would have poor quality compared to x264.

both x265 and x264 have deblocking filters, in the case of x265 a more advanced deblocking filter that work to mask artifacts so that the video becomes watchable but it loses loads of detail in the process, divx has no deblocking filter. for a fairer test rerun your encodes but disable the deblocking filter in x264 and x265 and then see which one did the better job at 1200kps for 1080p

Your logic never ceases to amaze me. Low bitrates mean compression artefacts, but apparently if an encoder produces less compression artefacts (ie blockiness) at low bitrates, if it's at the expense of picture detail instead, for some reason that makes it a bad encoder. Is that how it works?
I'll never understand why you keep claiming x264's ability to produce more watchable encodes at low bitrtates than other encoders somehow makes it a bad encoder.

DivX has no deblocking filter? I thought a deblocking filter was part of the spec for both h264 and h265?
http://en.wikipedia.org/wiki/Deblocking_filter#H.264_deblocking_filter
In contrast with older MPEG-1/2/4 standards, the H.264 deblocking filter is not an optional additional feature in the decoder. It is a feature on both the decoding path and on the encoding path, so that the in-loop effects of the filter are taken into account in reference macroblocks used for prediction. When a stream is encoded, the filter strength can be selected, or the filter can be switched off entirely. Otherwise, the filter strength is determined by coding modes of adjacent blocks, quantization step size, and the steepness of the luminance gradient between blocks.

http://en.wikipedia.org/wiki/High_Efficiency_Video_Coding#Loop_filters
HEVC specifies two loop filters that are applied sequentially, with the deblocking filter (DBF) applied first and the sample adaptive offset (SAO) filter applied afterwards. Both loop filters are applied in the inter-picture prediction loop, i.e. the filtered image is stored in the decoded picture buffer (DPB) as a reference for inter-picture prediction.

The DBF is similar to the one used by H.264/MPEG-4 AVC but with a simpler design and better support for parallel processing. In HEVC the DBF only applies to a 8x8 sample grid while with H.264/MPEG-4 AVC the DBF applies to a 4x4 sample grid. DBF uses a 8x8 sample grid since it causes no noticeable degradation and significantly improves parallel processing because the DBF no longer causes cascading interactions with other operations. Another change is that HEVC only allows for three DBF strengths of 0 to 2. HEVC also requires that the DBF first apply horizontal filtering for vertical edges to the picture and only after that does it apply vertical filtering for horizontal edges to the picture. This allows for multiple parallel threads to be used for the DBF.

I'll confess I don't know a lot about deblocking. All I really know is the potential effect on detail which comes from adjusting x264's deblocking filter.
So the DivX encoder..... did DivX choose to ignore part of the h265 specification with their encoder, or how does it work? The information above seems to indicate the deblocking filter can be disabled when encoding (at least for h264), but does the Divx encoder have no deblocking filter or is it just not adjustable as the x264 deblocking filter is?
I'm generally interested in learning more about it, so if you're able to shed some further light on the subject I'd appreciate it.
I couldn't find any info regarding Divx h265 deblocking but they do seem to think it's a good idea for h264 encoding.
http://labs.divx.com/book/export/html/127885
Could that be why the Divx h265 encoder is faster? No delocking filter?

[Gravitator]

I'm not seeing encodes three times faster than the last build.

+ No mention of improving the quality of the picture (you can see that was better).

DivX265 version 1.3.74
What's new:
Faster encoding, up to 3 times faster (balanced mode)
64 bit and 32 bit version
New options wrt signalling colorspace properties: -709, --colour-primaries, --transfer-characteristics, --matrix-coefficients
Note that this requires the VC 2013 runtime .
It is recommended to use the 32 bit version with AviSynth.

Known issues:

XP is not supported

[racer-x]

OK, you guys want 4k encodes? Both have the same bitrate. The Divx265 encodes twice as fast. You be the judge on quality:

I also encluded a 100% crop of the tongue for both encodes for detail purpose.

[Stears555]

Watch the tests! https://forum.videohelp.com/threads/365665-X-264-AVC-is-better-than-DIVX265-HEVC-A-TEST...t-DEAL-WITH-IT!

[Gravitator]

DivX265 (balanced) finished after 00:05:14.482 - Near the tree (on the left) and the lawn looks better than x265
x265 (medium) finished after 00:23:07.071 - Distant trees look better than DivX265
2-pass to make comparisons more parity / bitrate scatter (fascinating)

[Stears555]

Divx265 can't not even beat x264 2pass modes...

[Gravitator]

@racer-x,
Do not forget to indicate "--matrix-coefficients 709" for DivX (requires manual mode)

[Gravitator]

@Stears555,
let's discuss x264 vs x265/DivX265 in another topic.

[deadrats]

I'll never understand why you keep claiming x264's ability to produce more watchable encodes at low bit rates than other encoders somehow makes it a bad encoder.

because the "more watchable" part is a head fake, an illusion, it's kind of being served up rancid meat but slathered in bbq sauce so as to hide the rotting flavors.

the deblocking filters allow imbeciles to drop the bit rate to levels it should not have been dropped to and convince themselves that a) they know what they're doing and b) that somehow this is great.

the job of an encoder is to reproduce the source as accurately as possible, with as much detail as possible, the job of the encoder is not to hide blemishes, not to enhance the image and not compensate for people that don't know what they are doing.

DivX has no deblocking filter? I thought a deblocking filter was part of the spec for both h264 and h265?

you ask this question then post links to articles where it talks about h264 deblocking within the decode and encode portion. divx has never included a deblocking filter for their encoder, not even for the h264 cli encoder, they implemented the deblocking filter the proper way, in their decoder, so if you wanted h264 deblocking you would enable it within the control panel for their divx player.

this is not to be confused with the separate h264 and h265 encoders by main concept that do in fact feature deblocking within the encoder itself.

Could that be why the Divx h265 encoder is faster? No deblocking filter?

no, because x265 ultra fast also disables the deblocking filter and divx still smokes it.

honestly, the deblocking filter for x264 was one of the many way over-rated features of the encoder, the x265 one seems to work a lot better, in fact for x265 i would almost go as far as to say that if you want a good encode at any bit rate you should seriously consider enabling it.

[racer-x]

Well since we are comparing this, that and the other thing. I thought I may as well do a 4k hevc encode using ffmpeg. I made the files small for easy downloading. The shallow DOF allows for lower bitrate. The Divx265 is fastest, the x265 is slowest and ffmpeg falls in the middle.

[poisondeathray]

DivX has no deblocking filter? I thought a deblocking filter was part of the spec for both h264 and h265?

you ask this question then post links to articles where it talks about h264 deblocking within the decode and encode portion. divx has never included a deblocking filter for their encoder, not even for the h264 cli encoder, they implemented the deblocking filter the proper way, in their decoder, so if you wanted h264 deblocking you would enable it within the control panel for their divx player.

this is not to be confused with the separate h264 and h265 encoders by main concept that do in fact feature deblocking within the encoder itself.

Yes, inloop deblocking is part of AVC spec as well. , not just x264. All AVC encoders have it because it's the main "selling point" of AVC. Don't let your biased views get in the way of the truth

Just because DivX h264 didn't allow end user access to settings, doesn't mean deblocking is disabled

-----------

FUNNY STORY: so I downloaded a DivX h264 sample from the DivX page to check if deblocking is enabled or disabled in the elementary stream, in case deadrats is actually right on this one

"To see the quality of DivX Plus HD video BLAH BLAH BLAH..."
http://www.divx.com/en/devices/solutions/high-definition/divx-plus-hd/video


The smallest one is GI Joe Trailer. Guess what? It's encoded with x264! WTF!!! LOL
http://divxtrailers.divx.com/GIJoeTheRiseOfCobraTrailer-DivXPlusHD.mkv

Format                                   : Matroska
Format version                           : Version 1
File size                                : 53.2 MiB
Duration                                 : 2mn 14s
Overall bit rate                         : 3 327 Kbps
Encoded date                             : UTC 2009-11-30 19:41:06
Writing application                      : mkvmerge v2.6.0 ('Kelly watch the Stars') built on Mar 24 2009 15:23:17
Writing library                          : libebml v0.7.7 + libmatroska v0.8.1
TITLE                                    : G.I. Joe - The Rise Of Cobra Trailer
TITLE/Url                                : http://www.gijoemovie.com
COPYRIGHT                                : 2009 by PARAMOUNT PICTURES. All rights reserved. G.I. JOE and related characters are trademarks of Hasbro and are used with permission. 2009 Hasbro. All Rights Reserved.
COMMENT                                  : Encoded in DivX Plus HD for the DivX Plus Web Player

Video
ID                                       : 1
Format                                   : AVC
Format/Info                              : Advanced Video Codec
Format profile                           : High@L4.0
Format settings, CABAC                   : Yes
Format settings, ReFrames                : 12 frames
Codec ID                                 : V_MPEG4/ISO/AVC
Duration                                 : 2mn 14s
Nominal bit rate                         : 3 200 Kbps
Width                                    : 1 280 pixels
Height                                   : 528 pixels
Display aspect ratio                     : 2.40:1
Frame rate mode                          : Constant
Frame rate                               : 23.976 fps
Color space                              : YUV
Chroma subsampling                       : 4:2:0
Bit depth                                : 8 bits
Scan type                                : Progressive
Bits/(Pixel*Frame)                       : 0.197
Title                                    : Main title
Writing library                          : x264 core 79 r1342 e8501ef
Encoding settings                        : cabac=1 / ref=12 / deblock=1:-1:-1 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / psy_rd=1.0:0.2 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / chroma_qp_offset=-3 / threads=8 / nr=0 / decimate=1 / mbaff=0 / constrained_intra=0 / bframes=3 / b_pyramid=0 / b_adapt=2 / b_bias=0 / direct=3 / wpredb=1 / wpredp=0 / keyint=95 / keyint_min=25 / scenecut=40 / rc_lookahead=60 / rc=2pass / mbtree=1 / bitrate=3200 / ratetol=1.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / vbv_maxrate=20000 / vbv_bufsize=25000 / ip_ratio=1.40 / aq=1:1.00

------------

Anyways, the IronMan2 is encoded by DivX264. Deblocking is enabled.
http://divxtrailers.divx.com/Iron_Man_2-DivXPlusHD.mkv

[deadrats]

Just because DivX h264 didn't allow end user access to settings, doesn't mean deblocking is disabled

i can find no proof whatsoever that divx h264 actually has an inloop deblocking filter, frankly this makes no sense, the divx player has had the option to enabled/disable deblocking on playback for years and this option is only available for h264 playback, which to me suggests that they implemented the filter for decode only.

what proof do you have that the samples linked to in fact have inloop deblocking enabled during the encode?

Anyways, the IronMan2 is encoded by DivX264. Deblocking is enabled.

how exactly did you arrive at the conclusion that a deblocking filter was used/enabled during the creation of the linked clip?

[hello_hello]

I'll never understand why you keep claiming x264's ability to produce more watchable encodes at low bit rates than other encoders somehow makes it a bad encoder.

because the "more watchable" part is a head fake, an illusion, it's kind of being served up rancid meat but slathered in bbq sauce so as to hide the rotting flavors.

Making the best of a bad thing doesn't make it a bad encoder. Too low a bitrate is bad. No argument there. All encoders produce nice output at high bitrates. No argument there.

the job of an encoder is to reproduce the source as accurately as possible, with as much detail as possible, the job of the encoder is not to hide blemishes, not to enhance the image and not compensate for people that don't know what they are doing.

You're contradicting yourself.
If the job of the encoder is solely to reproduce the source as accurately as possible the encoder wouldn't let you adjust the bitrate/quality at all, yet they do, so your premise is rejected. The job of the encoder is to reproduce the source as accurately as possible within any specified limitations..... ie generally bitrate. Just because one encoder might do a better image enhancing job at low bitrates or because it might compensate for people that don't know what they are doing better than another, doesn't make it a bad encoder.
If the job of the encoder is to reproduce the source as accurately as possible then an ability to hide blemishes while keeping as much detail as possible isn't a mutually exclusive goal. They go hand in hand. You can't have it both ways while encoders allow the user to choose the bitrate/quality.

Yes, inloop deblocking is part of AVC spec as well. , not just x264. All AVC encoders have it because it's the main "selling point" of AVC......
Just because DivX h264 didn't allow end user access to settings, doesn't mean deblocking is disabled.

Anyways, the IronMan2 is encoded by DivX264. Deblocking is enabled.
http://divxtrailers.divx.com/Iron_Man_2-DivXPlusHD.mkv

I take anything deadrats posts with a huge grain of salt, hence asking about deblocking. How do you determine if a deblocking filter was used? I don't know how to do that.

So DivX offer a 1080p sample with an average bitrate of around 4375kbps to show off their encoder?? Obviously they didn't run that one by deadrats first.
Mind you I'm not sure it looks terribly special, but I don't have the original for comparison.

The smallest one is GI Joe Trailer. Guess what? It's encoded with x264! WTF!!! LOL

Wow. Now that's funny!

[poisondeathray]

Just because DivX h264 didn't allow end user access to settings, doesn't mean deblocking is disabled

i can find no proof whatsoever that divx h264 actually has an inloop deblocking filter, frankly this makes no sense, the divx player has had the option to enabled/disable deblocking on playback for years and this option is only available for h264 playback, which to me suggests that they implemented the filter for decode only.

what proof do you have that the samples linked to in fact have inloop deblocking enabled during the encode?

Anyways, the IronMan2 is encoded by DivX264. Deblocking is enabled.

how exactly did you arrive at the conclusion that a deblocking filter was used/enabled during the creation of the linked clip?

It's just a playback option in the divx player. Any software player can add post processing options, sharpen filter, brightness filter etc...

You can use a stream analyzer. A free one is h264_parse

1) demux to elementary avc stream e.g. mkvextract
2) h264_parse input.h264

It will say

   deblocking_filter_control_present_flag: 1

1 = enabled, 0= disabled


You can verify with other tools as well. For AVC, it's usually a safe bet that deblocking is enabled - that's almost the whole point of using AVC

Here is the text file for that IronMan 2 trailer if you have problems with commandline

[hello_hello]

I just finished reading this post, which I found interesting. http://forum.doom9.org/showthread.php?p=1540772#post1540772
Not that it probably effects this discussion much. I just found it interesting.

[poisondeathray]

yeah we're getting off topic yet again....

"x265 vs. Divx265"

[hello_hello]

I guess it's the price you pay for the necessary deadrats misinformation clarifications.

[El Heggunte]

   deblocking_filter_control_present_flag: 1

1 = enabled, 0= disabled

That's correct , I've just confirmed it with Elecard StreamAnalyzer.

[Gravitator]

DivX265 v1.3.74 - balanced/abr.
Scene change (flashlight shines on the receptacle) - Start keeps bad, then begins improving in the end.
I-B-B-B-P > The huge difference between the I > B frames.

x265 v1.1.0.225 - medium/abr.
Scene change (flashlight shines on the receptacle) - Start keeps well, then begins to deteriorate at the end.
I-B-B-B-P > Little difference between the I > B frames.

Original > prometheus(black).mkv

[Gravitator]

"C:\PROGRA~1\Hybrid\x265.exe" --preset ultrafast --input - --input-res 1920x800 --fps 23.976 --no-high-tier --no-strong-intra-smoothing --no-open-gop --bitrate 1500 --ipratio 1.7 --pbratio 1.7 --qpfile "K:\TEMP\x265-15-05(1717)_18_29_41_4410_01.qp" --psy-rd 0.5 --aq-mode 1 --aq-strength 1.5 --colormatrix bt470bg --output "K:\TEMP\x265-15-05(1717)_18_29_41_4410_02.265"
x265 [info]: HEVC encoder version 1.4+70-27d36c4b4a27
x265 [info]: build info [Windows][GCC 4.8.2][64 bit] 8bpp
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x265 [info]: Main profile, Level-4 (Main tier)
x265 [info]: WPP streams / frame threads / pool : 25 / 1 / 2
x265 [info]: CTU size / RQT depth inter / intra : 32 / 1 / 1
x265 [info]: ME / range / subpel / merge : dia / 25 / 0 / 2
x265 [info]: Keyframe min / max / scenecut : 23 / 250 / 0
x265 [info]: Lookahead / bframes / badapt : 10 / 4 / 0
x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 0 / 0 / 1
x265 [info]: Rate Control / AQ-Strength / CUTree : ABR-1500 kbps / 1.5 / 0
x265 [info]: tools: rd=2 psy-rd=0.50 early-skip fast-intra tmvp
x265 [info]: frame I: 2, Avg QP:18.20 kb/s: 12245.31
x265 [info]: frame P: 84, Avg QP:14.63 kb/s: 5986.86
x265 [info]: frame B: 331, Avg QP:18.75 kb/s: 308.94
x265 [info]: global : 417, Avg QP:17.92 kb/s: 1509.95
x265 [info]: consecutive B-frames: 3.5% 0.0% 0.0% 1.2% 95.3%
finished after 00:01:17.506
Created K:\TEMP\x265-15-05(1717)_18_29_41_4410_02.265 (3.13313 MB)

--------------------------------

"C:\PROGRA~1\Hybrid\x265-16bit.exe" --preset ultrafast --input - --input-depth 10 --input-res 1920x800 --fps 23.976 --profile main10 --high-tier --no-strong-intra-smoothing --no-open-gop --bitrate 1500 --ipratio 1.7 --pbratio 1.7 --qpfile "K:\TEMP\x265-16bit-15-05(1717)_20_26_59_9610_01.qp" --psy-rd 0.5 --aq-mode 1 --aq-strength 1.5 --colormatrix bt709 --output "K:\TEMP\x265-16bit-15-05(1717)_20_26_59_9610_02.265"
x265 [info]: HEVC encoder version 1.4+70-27d36c4b4a27
x265 [info]: build info [Windows][GCC 4.8.2][64 bit] 16bpp
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x265 [info]: Main 10 profile, Level-4 (Main tier)
x265 [info]: WPP streams / frame threads / pool : 25 / 1 / 2
x265 [info]: Internal bit depth : 10
x265 [info]: CTU size / RQT depth inter / intra : 32 / 1 / 1
x265 [info]: ME / range / subpel / merge : dia / 25 / 0 / 2
x265 [info]: Keyframe min / max / scenecut : 23 / 250 / 0
x265 [info]: Lookahead / bframes / badapt : 10 / 4 / 0
x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 0 / 0 / 1
x265 [info]: Rate Control / AQ-Strength / CUTree : ABR-1500 kbps / 1.5 / 0
x265 [info]: tools: rd=2 psy-rd=0.50 early-skip fast-intra tmvp
x265 [info]: frame I: 2, Avg QP:18.98 kb/s: 14284.80
x265 [info]: frame P: 84, Avg QP:16.61 kb/s: 5025.65
x265 [info]: frame B: 331, Avg QP:20.71 kb/s: 548.63
x265 [info]: global : 417, Avg QP:19.88 kb/s: 1516.36
x265 [info]: consecutive B-frames: 3.5% 0.0% 0.0% 1.2% 95.3%
finished after 00:02:01.165
Created K:\TEMP\x265-16bit-15-05(1717)_20_26_59_9610_02.265 (3.14643 MB)

--------------------------------

"C:\PROGRA~1\Hybrid\DivX265.exe" --input - --size 1920x800 --format yuv420p --bitrate 1725 -aqo 4 --interval 5 --framerate 24000/1001 -o "K:\TEMP\DivX-8bit_20_00_02_5810_01.265"
finished after 00:02:45.876
Created K:\TEMP\DivX-8bit_20_00_02_5810_01.265 (3.26566 MB)

--------------------------------

"C:\PROGRA~1\Hybrid\DivX265.exe" --input - --size 1920x800 --format yuv420p10le --main10 --bitrate 1650 -aqo 4 --interval 5 --framerate 24000/1001 -o "K:\TEMP\DivX-10bit_19_22_46_3310_01.265"
finished after 00:09:07.461
Created K:\TEMP\DivX-10bit_19_22_46_3310_01.265 (3.20628 MB)

Original sample > prometheus(black).mkv

DivX265 v1.4.0.21 - higher/abr/8bit.
Sorrow
DivX265 v1.4.0.21 - higher/abr/10bit.
1/2 of sadness

x265 v1.4+70 - ultrafast (--no-strong-intra-smoothing --ipratio 1.7 --pbratio 1.7 --aq-mode 1 --aq-strength 1.5 --psy-rd 0.5)/abr/8bit.
looks very convincing (allows to manipulate the safety of grain).

[Sagittaire]

1200kps for 1080p?!? of course divx265 had poor quality compared to x265, it would have poor quality compared to x264.

both x265 and x264 have deblocking filters, in the case of x265 a more advanced deblocking filter that work to mask artifacts so that the video becomes watchable but it loses loads of detail in the process, divx has no deblocking filter. for a fairer test rerun your encodes but disable the deblocking filter in x264 and x265 and then see which one did the better job at 1200kps for 1080p

in all honesty though that's a ridiculous bit rate to use for 1080p, as far as i'm concerned, if i was preparing content to be sold over the net i would use a minimum of 12mbs for 1080p and 8mbs for 720p.

Well really amazing affirmation ...

I make test for Mainconcept in 2006 for their H264 beta encoder. Mainconcept encoder, from the beginning has always been the H264 inloop deblocking option. DivX H264 and DivX H265 are simply SDK software from Mainconcept.

Inloop deblocking is one of the best functionality introduce in H264 codec. As far I know all the H264 codec in the world have this option and recommand highly to use it.

Inloop deblocking is an option in HEVC codec. HEVC Mainconcept codec have this option and recommand to use it. And like for H264, DivX use the HEVC SDK encoder from Mainconcept. It's really easy to prove that all stream from DivX265.exe use the deblock and SAO option.

In conclusion, if you want access at all the option in the "DivX HEVC" encoder, the best way is to use the totalCode software from Mainconcept.

[Sagittaire]

last but not least,

It's actually impossible to compare really HEVC implementation from DivX (Mainconcept) and x265 because:

- DivX have a simple constant quantizer mode (I P B b frame) or ABR 1 pass mode. Crf mode or ABR N pass mode from x265 is by far better Rate Conctrol than ABR 1 pass and constant quantizer mode. x265 with fast preset and crf mode produce for exemple better metric than DivX265 in CQ in highest quality mode (aq5)

- x265 have really advanced psy control for detail preservation and grain retention. DivX265 is actually simply optimized for produce best possible psnr.

Actually x265 is by far a better HEVC implementation than DivX265, at least for the quality output.

[El Heggunte]

@Sagittaire: Welcome to Videohelp

[Gravitator]

- DivX have a simple constant quantizer mode (I P B b frame) or ABR 1 pass mode.

Hi,
Narrow ABR does not allow to unleash 10bit... Will be completely different with the realization of 2-pass More speed !!!

[sophisticles]

x265 is by far a better HEVC implementation than DivX265, at least for the quality output.

It really depends a lot on the source. I recently ran across these samples:

http://www.elementaltechnologies.com/resources/4k-test-sequences

Elemental has reproduced some classic test clips in 4k and put them up on their website in both ProRes and H264 format. I'm assuming that the H264 versions were created with their GPU powered encoder.

At any rate, I downloaded all the samples and ran numerous test encodes, with various parameters and some of the clips, like Suzie, are so easy to compress that all the test encodes looked identical, regardless of whether it was x264, x264 10bit, divx hevc, divx hevc 10 bit, x265 or x265 10 bit and it didn't matter whether any or all psy optimizations were enabled or not, there was no observable difference between what was done with their encoder or the encodes I did.

The Coastguard clip on the other hand was very difficult to compress, showing substantial benefit from turning up subme and turning up mb-tree, psy-rd and AQ, in fact I would say that even at 32mb/s without psy optimizations the clip was almost unwatchable. Of course, using more bit rate would not be unwarranted either.

[Sagittaire]

x265 is by far a better HEVC implementation than DivX265, at least for the quality output.

It really depends a lot on the source. I recently ran across these samples:

http://www.elementaltechnologies.com/resources/4k-test-sequences

Not really in fact:

These source are really short sequence with really constant complexity. With that you can't really compare Rate Control and ABR 1 pass will make really good job. Anyway it's really not the case for real source like Trailer, Movie, sport ... with really high various complexity sequence.