x264 vs x265??

[hello_hello]

I'm still waiting to learn where psy-rd made the Elephant's Dream encodes look a lot worse, yet no doubt deadrats expects answers to his questions.

@atak:
WHAT?!? "great job"? in what way? all the screenshots are too dark to see any real details....

Time for a new monitor?
The original video obviously contains a reasonable amount of noise. The x264 --crf 22 encode didn't seem to encode it particularly accurately, but a fair amount of the detail behind the noise was retained. The x264 --crf 20 --no-psy encode almost looks like a noise filter was applied. The noise seems to have been smoothed out along with the detail behind it.

the bit rate of the encodes is absurdly low....

If I didn't know better I'd find my self assuming you've never done any encoding. Please explain how your CRF 22 encode is somehow more valid than Atak_Snajpera's CRF 22 encode because yours resulted in a much higher bitrate.

one of the test encodes psy-rd used more bit rate than without.

Errr.... that's what happened when you ran your test encodes. What were you expecting?

this is the type of silly BS that the x264 faithful use to justify their idiotic beliefs, seriously who the F actually encodes their video with 900 kb/s? i can barely stand audio with 640 kb/s and you want to encode video with barely more?

Wow..... now we're heading into golden eared, lossy compression territory. That should be fun......
The whole point is to maximise the visual quality. It's fairly logical higher CRF values or lower bitrates should benefit more than low CRF values or high bitrates. No doubt there's a quality/bitrate point for a given video where psy won't improve things much, if at all...... and as you claimed, that'd probably be the type of quality/bitrate most of us would generally use anyway.....

Please show us an example of a h264 encoder which produces a similar/better quality than x264 does using "typical" CRF values. Just one will do. We all know pretty much any encoder will produce a high quality encode if you increase the bitrate enough, x264 included.

[jagabo]

I can't say I've compared every single frame of each encode, but they're obviously encoded slightly differently in places. Number 2 appears to have a little more fine detail at times, and the slightly higher bitrate seems to indicate that's the case. Which one was encoded more accurately compared to the original.... well I don't have the original to compare them to.

I believe he started with this file:

http://media.xiph.org/video/derf/y4m/elephants_dream_720p24.y4m

You can open that with RawSource() in AviSynth:

RawSource("elephants_dream_720p24.y4m") # YV12

Attached is a version encoded with x264 CLI via a simple batch file (drop the AVS script onto it):

x264.exe --preset=slow --crf=18 --deblock=-2:-1 --sar=1:1 --output %1.mkv %1

As you can see, it's about the same as deadrats' during still shots, much cleaner in motion shots.

[x265]

just to give you a sample of no-psy-rd vs psy-rd, i tested with the uncompressed 720p24 elephant's dream source, i used the latest Hybrid build as my gui front end and ran the tests with the following settings:

test 1: no-asm, no-mbtree, no-psy-rd, no-psy-trellis, no trellis, all psy disabled, 4mb/s, 3 b-frames, 3 reference frames, no deblock, scenecut 100, weighted b and p, optimal, automatic b, normal b pyramid, mixed refs, no fast skip, sub me 7, all partition types, dia

test 2: same as above, except psy-rd = 1

to my eyes test 1 looks closer to the source and cleaner overall, if one of you wants to download the source and the samples and compare yourselves, you're free to do it.

i also did an x265 test, here's the command line as copied from Hybrid:

x265 --preset fast --threads 8 --frame-threads 8 --input - --input-res 1280x720 --fps 24 --frames 15691 --me 0 --subme 0 --merange 16 --max-merge 1 --no-strong-intra-smoothing --keyint 100 --bframes 3 --weightb --b-adapt 0 --scenecut 100 --bitrate 4000 --rd 0 --no-signhide --aq-mode 2 --no-lft --no-psnr

i couldn't find an option to disable asm, so...

How could you possibly call this a valid test? Who uses --merange 16, or --rd 0? No one. These are ridiculous settings, unless your objective is to create the lowest possible visual quality.

[deadrats]

How could you possibly call this a valid test? Who uses --merange 16, or --rd 0? No one. These are ridiculous settings, unless your objective is to create the lowest possible visual quality.

i chose those settings in order to approximate the settings i used with my x264 encodes and compare the results.

besides, as you must be aware, x265 is currently way, way to slow to really test it thoroughly with more aggressive settings and in fact it will be years before x265 and cpu's are fast enough to test with slower settings.

i have an i7 3770k and even with the above settings i was under 10 fps at 720p with an uncompressed source. by my calculations it would take one of the new upcoming octocore Haswell E processors to be able to approach real time encoding with a 720p source at medium settings.

it will be interesting to see what comes first, whether Intel includes hardware hevc encoding via QS into their cpu's, or they add 512bit integer and fp simd or move to octocore for all their consumer grade cpu's.

honestly, if intel decides to incorporate QS hevc first, as i suspect they will, i don't see any software based hevc encoder really gaining any traction.

i wish someone following this thread with a really beefy cpu, maybe with a dual xeon or an overclocked intel hexacore would run the elephants dream test with both DivX265 and x265 with the slowest settings for each so that we could see the difference in quality.

[deadrats]

x264.exe --preset=slow --crf=18 --deblock=-2:-1 --sar=1:1 --output %1.mkv %1

As you can see, it's about the same as deadrats' during still shots, much cleaner in motion shots.

of course, you used crf 18 and deblock with negative values, i used a higher crf and had deblock disabled to isolate the effects of psy-rd.

of course his darkness has complained against using sources like elephant's dream to test x264 because iirc according to him it unfairly biases against x264, at least that was what he b*tched about when people were using Big Buck Bunny for comparisons and his precious little encoder wasn't winning the comparisons.

i just checked the encoder settings you used:

cabac=1 / ref=5 / deblock=1:-2:-1 / analyse=0x3:0x113 / me=umh / subme=8 / psy=1 / fade_compensate=0.00 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=6 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=24 / scenecut=40 / intra_refresh=0 / rc_lookahead=50 / rc=crf / mbtree=1 / crf=18.0000 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00

wow, you used way more aggressive settings than i did and your encode barely looks any better than mine, if at all.

this just proves what i've been saying all along, more important than the encoder used or the settings is the quality of the source, with a clean enough source any encoder with any settings will produce a fine encode.

x264 is made for the crowd that got off on re-encoding stuff they downloaded from p2p and/or bit starving encodes because they have some sick fetish where they get their rocks off by using as little bit rate as possible.

[x265]

How could you possibly call this a valid test? Who uses --merange 16, or --rd 0? No one. These are ridiculous settings, unless your objective is to create the lowest possible visual quality.

i chose those settings in order to approximate the settings i used with my x264 encodes and compare the results.

Turning x265 into x264 isn't really a valid test of an HEVC encoder. If that's what you want to do, don't forget to limit the cu size to 16.

besides, as you must be aware, x265 is currently way, way to slow to really test it thoroughly with more aggressive settings and in fact it will be years before x265 and cpu's are fast enough to test with slower settings.

i have an i7 3770k and even with the above settings i was under 10 fps at 720p with an uncompressed source. by my calculations it would take one of the new upcoming octocore Haswell E processors to be able to approach real time encoding with a 720p source at medium settings.

On a Core i7 4770K, we hit 160 FPS on "Johnny" 720P using the Ultrafast preset. Try --preset ultrafast without all of the other options you're using (don't set --threads or --frame-threads manually). You won't match Haswell performance, but you should achieve much faster performance with much better quality and compression efficiency. For better visual quality, turn the loop filter back on (--lft), or just use the superfast preset.

[gonca]

i7 3930k @ 4.4 GHz
I'll use Hybrid as a frontend if some agreement is reached on settings for x264, x265.

P.S. There is a thread on Doom9 with comparative samples if somebody wishes to view them.
http://forum.doom9.org/showthread.php?t=170236

[jagabo]

x264.exe --preset=slow --crf=18 --deblock=-2:-1 --sar=1:1 --output %1.mkv %1

As you can see, it's about the same as deadrats' during still shots, much cleaner in motion shots.

of course, you used crf 18 and deblock with negative values, i used a higher crf and had deblock disabled to isolate the effects of psy-rd.

I thought you were presenting those as good encodings with and without psy-rd. I used the slow preset because that's where I usually start. The deblocking settings were there to give a sharpness similar to your files (but still reduce blocky artifacts during motion). CRF 18 was used because that gave a similar bitrate to your samples.

[deadrats]

i7 3930k @ 4.4 GHz
I'll use Hybrid as a frontend if some agreement is reached on settings for x264, x265.

P.S. There is a thread on Doom9 with comparative samples if somebody wishes to view them.
http://forum.doom9.org/showthread.php?t=170236

awesome! how about using a really high quality source, like the elephant's dream i used (the download is like 4gb and 21 gb when unzipped) or whatever you like so long as we can see the source.

as for settings how about x264 + placebo, x265 + placebo and DivX265 + aq 5 (i.e. "slowest").

and choose the same bit rate for each.

thanks.

[deadrats]

I thought you were presenting those as good encodings with and without psy-rd. I used the slow preset because that's where I usually start. The deblocking settings were there to give a sharpness similar to your files (but still reduce blocky artifacts during motion). CRF 18 was used because that gave a similar bitrate to your samples.

no, no, no; i was trying to isolate the effects of psy-rd on visual quality, that's why i disabled everything including asm.

from what i have read x264 settings have dependency issues, i.e. psy-rd + psy-trellis + mb-tree + aq behaves differently than just psy-rd on it's own.

in fact Jason, aka DS, has said that psy-rd only has meaning in the context of subme>6 but he has also said that things like the deblocking filter and built in denoise filter have a cascading effect, where the effects propagate from frame to frame and get added up as the gop progresses. this tells me that for maximum quality you should be limited gop also and using a closed gop since frames can't make reference to any frame outside the gop sequence with closed gop.

i'm guessing the above is one of the reasons blu-rays use short closed gops.

[gonca]

Any suggestions for bit rate, hi / med / low?

[deadrats]

On a Core i7 4770K, we hit 160 FPS on "Johnny" 720P using the Ultrafast preset. Try --preset ultrafast without all of the other options you're using (don't set --threads or --frame-threads manually). You won't match Haswell performance, but you should achieve much faster performance with much better quality and compression efficiency. For better visual quality, turn the loop filter back on (--lft), or just use the superfast preset.

i don't see how that's possible, maybe it's this "Johnny" source you're using, you wouldn't happen to have a link to it, would you?

with the elephant's dream i have been testing with, following your suggestion it starts at 18 fps and drops to about 6-7 fps. i know a haswell has avx2 and that x265 makes use of those simd optimizations but i find it hard to believe that they result in a 10x speed up.

my guess is that the source you're using isn't complex enough to stress the encoder and it's having a much easier time encoding it.

download the elephant's dream source and rerun your test, i'm willing to be money your 4770k is lucky if it hits a sustained real time encoding speed.

http://media.xiph.org/

download the 4gb lossless, when unzipped it's 21gb, that's the source for my tests.

@Jagabo:

what kind of encoding speeds do you see with your 2500k when you did your tests with the same source i used?

[deadrats]

Any suggestions for bit rate, hi / med / low?

how about 4mb/s, that seems to be what Hulu HD uses, as well as the itunes HD i have seen and what most of the 720p stuff i see on torrent sites, also it low enough that we should be able to see any differences in quality quite easily.

[x265]

[QUOTE=deadrats;2326742]

i don't see how that's possible, maybe it's this "Johnny" source you're using, you wouldn't happen to have a link to it, would you?

The file is called Johnny_1280x720_60.yuv It's 829,440,000 bytes. I can't provide a link... but you may be able to find a copy somewhere.

[jagabo]

@Jagabo:

what kind of encoding speeds do you see with your 2500k when you did your tests with the same source i used?

With the 21 GB Y4M file,

RawSource("elephants_dream_720p24.y4m")

and

start /b /low x264.exe --preset=slow --crf=18 --deblock=-2:-1 --sar=1:1 --output %1.mkv %1

The final report from x264 was 26.80 fps.

With the veryfast preset it speeds up to 83 fps but reading the source has become a bottleneck (CPU usage bounces around 50 to 75 percent). Using a lossless UT compressed version (6.5 GB) instead speeds it up to ~122 fps.

[gonca]

ducks_take_off_1080p50.y4m

ABR 1500 Kbps

Elephants Dream at 4M coming up

[deadrats]

well with the "ducks" samples x264 looks like crap, my God it's awful. to my eyes DivX265 seems to produce the better encode overall but on the right side of the video i'm seeing some blocking, more so than the x265 encode, which seems to have more even quality throughout the screen, still has blocking on the right hand side and lower quality overall.

of course this isn't a conclusive test, but it's a nice start.

h264 as an encoding technology really shows it's age.

[deadrats]

ok, i decided to try a different source, namely the Sintel 720p y4m trailer, with this source my encoding speeds with x265 ultra fast were 22fps, i'm guessing my hard drives must really be bottlenecking my encodes. anyway, i also did a divx265 "fastest" test, here they are.

personally i don't see much difference between the divx and x265 encodes.

http://media.xiph.org/

i'm wondering if it would be wise to invest in a couple of hybrid hard drives, microcenter has 500gb 5400rpm with 8gb cache hard drives for $60 each, 2 of them in a raid 0 would give me a 1tb 10000rpm with 16gb cache harddrive equivalent, not bad for $120 bucks.

[hello_hello]

x264 is made for the crowd that got off on re-encoding stuff they downloaded from p2p and/or bit starving encodes because they have some sick fetish where they get their rocks off by using as little bit rate as possible.

Are you planning on ever explaining where psy destroyed the image in your sample encodes or is the plan to just keep ignoring the question while repeating brain-dead generalisations?

[deadrats]

Are you planning on ever explaining where psy destroyed the image in your sample encodes or is the plan to just keep ignoring the question while repeating brain-dead generalizations?

you need to download the source and compare it against the encodes i did.

[Gravitator]

@gonca,

No! DivX in Hybrid it is very bad! > example
(Use native DivX Converter)

@deadrats,

No! x265 obvious problem > psy

[LigH.de]

I can't provide a link... but you may be able to find a copy somewhere.

I found one on a finnish server. Is it not allowed to link it in public?
__

The three samples appear to be not very challenging, rather some "best case scenarios": Clean content, little and easily predictable movements.

[hello_hello]

Are you planning on ever explaining where psy destroyed the image in your sample encodes or is the plan to just keep ignoring the question while repeating brain-dead generalizations?

you need to download the source and compare it against the encodes i did.

No I don't. I'm asking where you think psy has destroyed the image. Given you've compared them to the source already and you're the one making the claim it does, it should be easy for you to point out where it has.

[hello_hello]

this just proves what i've been saying all along, more important than the encoder used or the settings is the quality of the source, with a clean enough source any encoder with any settings will produce a fine encode.

x264 is made for the crowd that got off on re-encoding stuff they downloaded from p2p and/or bit starving encodes because they have some sick fetish where they get their rocks off by using as little bit rate as possible.

So your anti-x264 rant is based on the fact it's better at lower bitrates than other h264 encoders?

[gonca]

(Use native DivX Converter)

Prefer not to use DivX installers. I've had issues with their software installation in the past

[Selur]

regarding DivX265 and Hybrid:
Problem is they do not distribute the encoder they use inside the DivX Converter on it's own.
Hybrid uses the encoder from the DivX HEVC Community Encoder, not the one which comes with the 'DivX Converter'.

So your anti-x264 rant is based on the fact it's better at lower bitrates than other h264 encoders?

To me deadrats position sound more like a philosophical point than anything else. (it's kind of natural that each project has 'lovers' and 'haters')

[hello_hello]

To me deadrats position sound more like a philosophical point than anything else. (it's kind of natural that each project has 'lovers' and 'haters')

Is "philosophical" a nice way of saying "not completely rational"?

[deadrats]

Is "philosophical" a nice way of saying "not completely rational"?

what's "irrational" is starting out with a high quality 20-30 mb/s source, cropping and resizing the crap out of it, dropping the bit rate to stupid low levels, i've seen encodes of Ghost Rider at 720p@1mb/s which was unwatchable, and thinking that it's ok because you enabled psy-rd, mb-tree, aq or whatever other "optimization" in the most over-rated half-assed encoder ever conceived.

even better are the "champions" that then decide that their pc is too slow and go buy a new cpu/mb/ram combo so that they can F up their videos even faster.

the way i see it is just buy another hard drive and save yourself the headaches.

seriously, if as has been reported by 2016 we have 16tb ssd's and they cost in the $500 range, would you even consider upgrading your processor/mb/ram or would you just say the hell with it, i can just keep the original as is.

[jagabo]

seriously, if as has been reported by 2016 we have 16tb ssd's and they cost in the $500 range

That is a fantasy.

[gonca]

elephants dream ABR 4000 Kbps

http://www.mediafire.com/download/ogebaokfc2e1czo/divx265.mkv
http://www.mediafire.com/download/9kh852re3kpgu7f/x265.mkv
http://www.mediafire.com/download/z09e0nbya12wvdd/x284.mkv

Should not have any ads