vp9 vs x265 vs DivX265

[deadrats]

ok, folks i just did a comprehensive encoding test with the above 3 encoders that will forever settle any doubts as to which is the absolute best to use in all circumstances.

the source was a 39 sec 720x480i clip from an adult dvd circa mid 1990's, there's no nudity or sex, just a chick talking on the phone.

i did 3 whole test encodes, one with vp9, one with x265 and one with DivX265, i used 128kb aac audio for all of them, the vp9 was muxed to mkv, the other two were muxed to mp4. i used Hybrid as the gui front end.

for deinterlacing i used qtgmc, set to very slow and bob; the bitrate used was 6400kb/s.

for vp9 i used 4 threads, sharpness was set to 0 which is equivalent to turning on the in-loop deblocking filter, aq was set to variance, gop was 60, vbr, profile was set to complex, speed control was set to best, tile columns/rows was set to 6/2.

for x265 used very slow preset, loop filter was set to sao lcu and non deblocked, gop was 60, aq was set to auto 1.00, wpp on, 64x64, threads and lookahead threads were set to 4 each.

DivX265 was set to gop 1 sec (works out to 60 frames), wpp on, aq highest quality.

i also tried x264, but it just kept crashing, so i gave up.

all encode times were absurdly slow, as an example, it took x265 more than 32 minutes to encode 39 secs worth of SD content with these settings. the lowest cpu usage during encode was vp9 easily as it's not well threaded at all yet funny enough the encode times were on par with the other 2.

i'm uploading the original as well as the test encodes, if anyone wants to try to get better results. the source was also auto cropped to 706x480 before being resized back to 720x480.

some of you may be wondering why i used so much bit rate, it's because the source also used that much bit rate and since i double the number of frames by bobbing, it stands to reason it would need double the bit rate, but if you assume that the new codecs are twice as efficient as the mpeg-2 that was used, then it works out to a push.

so what does this test tell us? absolutely nothing. i have a hard time seeing any difference between any of these codecs at their highest settings and all 3 are so slow as to be unusable at these settings. in fact, if anything it tells use that more important than the quality of the encoder is the quality of the filters used and how much bit rate you throw at the encode.

now some of you may be asking why you should give a rip about vp9 and the answer is simple: because it's open source, patent and royalty free (even though the mpeg-la is trying to claim it infringes on some of its patents), google is behind it, google owns youtube and google has announced that youtube will be supporting 4k and it will be moving away from h264 (it currently uses x264) and switching to vp9 and on the highest settings it seems to be on par, speed-wise, with the 2 major hevc encoders but unlike the 2 hevc encoders that either max out or come close to maxing out my i7 3770k, vp9 barely hits 15% usage during even the highest setting encode.

of course, as i mentioned it does take over half an hour with any of these to encode 39secs of SD content, which doesn't really bode well for mass adoption of any of these any time soon.

to put these pathetic speeds in perspective, in order to achieve real time encoding, either cpu's or the encoders themselves need to be more than 60 times faster than they are right now and that just for SD resolution content.

i think i'm going to do another round of testing using the fastest settings for each and upload those results as a quality comparison point to see how much quality you need to give up for a speed boost.

[deadrats]

update, i just did another vp9 test encode, this time i set the basic speed control to good, cpu modifier to 5 (which turns off rate distortion optimizations), profile to low tile columns/rows to 0/0 and aq to off. this sped up the encode to about 2 minutes (i would have to time it with a stop watch) and as far as i can tell i don't see any impact on quality, if anything it may even be better.

[Selur]

so what does this test tell us? absolutely nothing. i have a hard time seeing any difference between any of these codecs at their highest settings and all 3 are so slow as to be unusable at these settings.

this did not really surprise you, did it?

in fact, if anything it tells use that more important than the quality of the encoder is the quality of the filters used and how much bit rate you throw at the encode.

Yes, if you throw enough bit rate at it you can even use old compression formats like MPEG-1, but then why bother and not stick with lossless compression formats? Compression only does make sense if simply throwing bit rate at it isn't an option,...
Yes, filtering can help a lot.

or deinterlacing i used qtgmc, set to very slow
+
all encode times were absurdly slow,

yes, qtgmc with a slow preset is relatively slow,...

since i double the number of frames by bobbing, it stands to reason it would need double the bit rate,

sure, if motion compensation wasn't existing and only independent frame compression was possible this might be reasonable, otherwise: No

[quotte]i would have to time it with a stop watch[/quote]
Why not simply take the times the gui or encoder output reported?

vp9 barely hits 15% usage during even the highest setting encode.

missing multithreading is one of the 'Known Issues', see: http://wiki.webmproject.org/vp9/known-issues

-> Hope you had some fun doing the 'testing' you did.

ok, folks i just did a comprehensive encoding test with the above 3 encoders that will forever settle any doubts as to which is the absolute best to use in all circumstances.

a bit of a lame marketing text,..

Cu Selur

[deadrats]

yes, qtgmc with a slow preset is relatively slow,...

it's not the qtgmc that was the limiting factor with regards to encoding speed, it was the speed of the encoders themselves, proof is the massive difference in encoding speeds between the highest quality and lowest quality settings.

Why not simply take the times the gui or encoder output reported?

now why didn't i think of that? oh wait, maybe because Hybrid doesn't report encoding times, it will report encoding speed with x264 and x265 but not with vp9 or DivX265.

missing multithreading is one of the 'Known Issues', see: http://wiki.webmproject.org/vp9/known-issues

according to that 1 pass does not work yet it worked just fine in my tests.

anyway, i'm kind of surprised that the open source community hasn't jumped on the vp9 bandwagon, considering it's open source and patent/free free. part of me wonders if it's an anti-google bias.

i know that DS had complained about the vp8 code supposedly being a mess, i think he even claimed that it was purposely obfuscated as to make it almost impossible to know what it was doing, at least i think he was talking about vp8. but i also know he was behind a project known as xvp8, i wonder what ever became of it and if he and/or someone else had any intention of doing xvp9.

one has to assume that google will be threading vp9 soon, if they expect to use it for youtube.

a bit of a lame marketing text,..

it was supposed to be tongue-in-cheek; clearly no one test can ever be considered the final word on codec comparisons.

[Selur]

oh wait, maybe because Hybrid doesn't report encoding times, it will report encoding speed with x264 and x265 but not with vp9 or DivX265.

Hybrid reports the time each sub-job took in the log,...

Starting Main@12:00:44.790:
"G:\Hybrid\DivX265.exe" --input - --size 640x352 --bitrate 1500 -aqo 2 --interval 5 --framerate 25 -o "H:\Temp\test_new_12_00_42_3010_01.265"
finished after 00:02:01.628

[Marchand]

Hello people.

As it takes longer to encode, I still prefer to encode in Hevc/H265-10Bits through Hybrid as sample below. Video is perfect. This is just my simple opinion as an end user and could not help but opine about it .

Deadrats, Thanks for opening the discussion in the forum (vp9 vs x265 vs DivX265), which is very important at this time of adaptations and adjustments for all involved in these new codecs.

Link Sample Hevc/H265-10Bits:

https://mega.co.nz/#!kI9R3Soa!3ncWJOpd87qxqDgO61a6SGZ6R_eyIRuYiArKQKXslOs

or

https://shared.com/w4zsajgn8x?s=l

General
Complete name : E:\Videos\Test Hybrid 10bits.mp4
Format : hvc1
Codec ID : hvc1
File size : 168 MiB
Duration : 2mn 58s
Overall bit rate : 7 890 Kbps
Encoded date : UTC 2014-01-25 07:41:53
Tagged date : UTC 2014-01-25 07:41:53
Writing application : Hybrid 2013.12.02.1

Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L12.0
Codec ID : hvc1
Codec ID/Info : High Efficiency Video Coding
Duration : 2mn 58s
Bit rate : 7 760 Kbps
Maximum bit rate : 23.9 Mbps
Width : 1 920 pixels
Height : 816 pixels
Display aspect ratio : 2.35:1
Frame rate mode : Constant
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.207
Stream size : 165 MiB (98%)
Language : English
Encoded date : UTC 2014-01-25 07:41:53
Tagged date : UTC 2014-01-25 07:41:58

Audio
ID : 2
Format : AC-3
Format/Info : Audio Coding 3
Mode extension : CM (complete main)
Format settings, Endianness : Big
Codec ID : ac-3
Duration : 2mn 58s
Bit rate mode : Constant
Bit rate : 128 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 44.1 KHz
Bit depth : 16 bits
Compression mode : Lossy
Stream size : 2.73 MiB (2%)
Title : ac3#audio:lang=en@GPAC0.5.1-DEV-rev4922
Language : English
Encoded date : UTC 2014-01-25 07:41:57
Tagged date : UTC 2014-01-25 07:41:58

[deadrats]

i didn't realize hybrid reported how long each sub job took, i just redid the vp9 test with the much faster settings and it took just under 3 minutes 59 seconds, DivX265 took 7 minutes 25 seconds with the fastest settings and x265 using the ultra fast preset took 2 minutes flat.

a couple of notes, these times are only for the video portion of the job, it doesn't take into account muxing, demuxing, or audio conversion.

more importantly, since this was a 29.97 fps interlaced source going to a 59.94 fps progressive target, the encode times are doubled, for a regular 29.97 fps target the encode times would be half that reported above.

regardless, even the fastest among them, x265, with the fastest settings, can't achieve real time encoding with SD content.

that means if you're planning on doing a full 1080p movie, you better have a ton of patience and forget about 4k any time soon.

i'm uploading these test encodes also, i personally can't tell the difference between the ones done with the slowest settings and the ones done with the fastest settings. what this tells me, as i pointed out already is that the filters used and the bit rate used are more important than the codec and/or settings used.

it also reinforces my belief that codecs like x264 and x265 are way over engineered and over developed, i see no point in spending countless man hours writing and debugging code that doesn't result in any appreciable quality improvement.

all codec developers would be best served just coding their codec with a handful of options that give high quality encodes and then speed optimizing that code.

instead it seems, and this seems to be true of most open source projects, they get a case of the "everything and the kitchen sink" syndrome where they keep adding "features" for the sake of adding features,
just so they can show that development is still taking place, basically their software stays in a perpetually beta state that will never end.

[z-machine95]

hello everyone, i have already converted the lord of the ring the fellowship of the ring extended in x265 and it takes approximately 23 h, i use slow preset, 1500 kbps bitrate and not much more...
here is the final video:

here the mediainfo report:

General
Unique ID : 205421759749009432194401082860913477370 (0x9A8ACAB5902A81B5ABB3801C6306C6FA)
Complete name : F:\LOTR.I.The.Fellowship.of.the.Ring.ITA.ENG.AC3.B DRip.1080p.X265-ZMachine.mkv
Format : Matroska
Format version : Version 4 / Version 2
File size : 3.91 GiB
Duration : 3h 48mn
Overall bit rate : 2 451 Kbps
Movie name : LOTR I: The Fellowship of the Ring - ZMachine
Encoded date : UTC 2014-01-25 13:34:32
Writing application : mkvmerge v6.7.0 ('Back to the Ground') 64bit built on Jan 8 2014 15:10:52
Writing library : libebml v1.3.0 + libmatroska v1.4.1

Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Codec ID : V_MPEGH/ISO/HEVC
Duration : 3h 48mn
Bit rate : 1 506 Kbps
Width : 1 920 pixels
Height : 800 pixels
Display aspect ratio : 2.40:1
Frame rate mode : Constant
Frame rate : 23.976 fps
Bits/(Pixel*Frame) : 0.041
Stream size : 2.40 GiB (61%)
Title : Video H.265 (Encoded by ZMachine)
Default : Yes
Forced : No

now i have to convert the second lotr film and because of the encoding time i have split the source into 4 1 hours long parts. now i want to ask if there are some tweaking to do to speedup the process, i don't know, using fast preset with an higher bitrate or something else... i use Hybrid to encode and i set thread count to 8 (i have an i7 so 8 logical cores), while in "frame threads" i use 0:auto. the average encoding speed of my pc is 4 fps while with x264 at 5500 kbps is 35 fps... is it much ( i have a powerful cpu i7 2600K at 4.7 Ghz)? what's your encoding speed?

[deadrats]

if you're going to re-encode i would use much more bit rate and the ultra fast preset.

[z-machine95]

if you're going to re-encode i would use much more bit rate and the ultra fast preset.

i must have a < 4 Gb file... if i go with ultra fast at 5000 kbps how much space require? how is the quality?

[Jamaika]

I renew the subject.
Subject maybe a little curious. You should live creatively. I want to learn from the world as we have other new codecs 2015. What are the results of quality and compression rate for nvencc? Does anyone know if stepped codec vp10? As it has Daala, and maybe some examples? Is it possible to create files 10bit codec Kvazaar?
I have done tests 10bit i422 movies GOP = 25, bitrate=2500kbps codecs three vp9 v1.4.200 / X265 v1.7.166 / divx265 v1.5
I have encountered problems in the player beta MPC-HC 1.7.9.14.
The codec VP9 preserves bitrate only for the size of HD. It has problems with smooth scrolling in the player. MKVmerge Muxer 7.9 VP9 8bit doesn't work with player MPC-HC. Is it possible to transfer to a container codec MOV? You can, but it does not work playback. Colorspace sRGB don't play.
DIVX265 v1.5 codec. It has a smooth GOP. It has damaged the function of yuv422p10le. You can only convert yuv420p10le. Colorspace bad work with the BT709 8bit files. Not retains bitrate.
Codec X265 v1.7.166. The problem of low GOP. Is the player can be set for a read notes from keyframe? Low GOP is with me sometimes local blur.
I put a samples:

http://www.sendspace.com/filegroup/Hah8imS6WKLA%2B33U8B9OTMGJHCSUFABo

[Selur]

s it possible to create files 10bit codec Kvazaar?

Not atm.

. What are the results of quality and compression rate for nvencc?

I don't even know that 'quality and compression rate' are.

VP9 8bit doesn't work with player MPC-HC.

That's strange it worked last time I encoded something to VP9.

Is it possible to transfer to a container codec MOV?

If you reencode the video and audio streams to mov compatible formats: yes

DIVX265 v1.5 codec. It has a smooth GOP. It has damaged the function of yuv422p10le.

I can confirm that. -> Someone should probably report it to the DivX Networks folks.

[newpball]

if you're going to re-encode i would use much more bit rate and the ultra fast preset.

i must have a < 4 Gb file...

No you don't.

In 2015 videos are not limited to 4GB!

[Jamaika]

VP9 8bit doesn't work with player MPC-HC.

That's strange it worked last time I encoded something to VP9.

Codec not works only with container MKVmerge 8.0 in FFmpeg I hast no problem. {installed codecs in the system MPC-BE}
http://sourceforge.net/projects/mpcbe/files/MPC-BE/Nightly%20Builds%20%28from%20svn%20...428%29%20beta/
Problem is with command mkvmerge.exe --cues 0:iframes
Decoder MPC-HC breaks the fast forward video VP9.

Is it possible to transfer to a container codec MOV?

If you reencode the video and audio streams to mov compatible formats: yes

True. I uninstalled MPC-BE decoders. I used the decoders MPC-HC which uses a player 1.7.9.14. The movie plays. My mistake.

[Jamaika]

I wonder what I'm doing wrong with muxer VP9 10bit codec.
One movie I'm used FFmpeg:

ffmpeg.exe -y -i "00324.mts" -s 1920x1080 -r 50.000 -sn -f webm -c:v libvpx-vp9 -c:a libopus -quality good -threads 4 -cpu-used 3 -g 25 -keyint_min 0 -aq-mode variance -vb 3500k -ab 192k -ac 2 -ar 48000 -pix_fmt yuv444p10le -colorspace bt2020_ncl "vp90_444p10le_1.webm"

We are constantly redirects me 8bit files, but in the movies, you can smoothly change the position realtime.
Incompatible pixel format 'yuv444p10le' for codec 'libvpx-vp9', auto-selecting format 'yuv444p'
The second film I'm doing by vpxenc:

ffmpeg.exe -y -loglevel warning -i "00324.mts" -s 1920x1080 -r 50.000 -an -sn -f rawvideo -pix_fmt yuv444p10le - | vpxenc.exe -v --bit-depth=10 --input-bit-depth=10 --i444 -w 1920 -h 1080 --profile=3 --threads=4 --passes=1 --pass=1 --good --codec=vp9 --fps=50000/1000 --cpu-used=3 --target-bitrate=3500 --color-space=bt2020 --kf-min-dist=0 --kf-max-dist=25 --drop-frame=0 --aq-mode=1 - -o "vp90_444p10le.webm"

The film works fine, but I can't properly connect to the audio track "opus". FFmpeg or MKVmerge 8.1 can't cope. They don't open in the frames I. The strange thing because the same codec in addition to Adobe Premiere is properly muxer.
Does anyone know how to deal with Windows?

Edit: I install a Hybrid Selur 2015.06 and converter FFmpeg use format yuv444p10le. Only codec vpxenc is for now useless.