The fascinating quality of x265!1080p video with fast movements in 1300kb/

[Atak_Snajpera]

x264 rev 2345
x265 rev 0.6+89-55d99b6651f2 (UTC 11:21:27 AM) from https://x265.cc/

Sample: park_joy_1080p50.y4m (http://media.xiph.org/video/derf/)
x264 --preset veryslow --crf 32.4
https://mega.co.nz/#!9Z9C0JLZ!Y7GcCgWMehUgezvJhXb_qX6FIKRYrp2AEhxsm6s-6xQ
AVERAGE BITRATE: 6757 kbps

x265 --preset medium --crf 28 (default value) --fps 50
https://mega.co.nz/#!wE0SyRhA!RcDCBnXnEwvZCxbDymM9FxIzwCZ36Qs14vt3Rqrviyg
AVERAGE BITRATE: 6821 kbps

Use latest mpc-hc to play raw .265 files

Encoding time on Q6600@3Ghz
x264 : 2m:45s
x265 : 10m:03s

Screenshots
x264 -> http://s17.postimg.org/4r8nvo0wv/park_joy_1080p50_mkv_160.png
x265 -> http://s17.postimg.org/cy0nn8qzj/park_joy_1080p50_265_160.png

[pandy]

What statement are you disagreeing with ? Did you even read or understand what I said ?

My point was all tests have some value. Yes, we should use as non compressed sources as a large part of the testing - but you're missing the whole picture if you don't use an encoder under different usage scenarios . My point is all tests have at least some value.

Disagree where judging between quality is performed on already compressed in lossy way sources - during many years i've learned one thing - lossy compression of lossy compressed sources never gives you decent results. And as i agree that it can be important to evaluate quality based on lossy compressed source then also it can't be limited to this especially that many codecs is sensitive to various compression artifacts.

[Atak_Snajpera]

Sample: crowd_run_1080p50.y4m (http://media.xiph.org/video/derf/)
x264 --preset veryslow --crf 31.32
https://mega.co.nz/#!9EsDBbKS!DlWsrS3Net8Vt9MjZzSaJhvhJ3UhtKFLQ4HpUDriavA
AVERAGE BITRATE: 7049 kbps

x265 --preset medium --crf 28 (default value) --fps 50
https://mega.co.nz/#!RUc0QSpC!JY5mH3bALvcifyuo_uSC-hzIudNFGpPiPVi42PRN1Ro
AVERAGE BITRATE: 7047 kbps

Use latest mpc-hc to play raw .265 files

Encoding time on Q6600@3Ghz
x264 : 2m:50s
x265 : 10m:28s

Screenshots
x264 -> http://s17.postimg.org/nqcieh40v/crowd_run_1080p50_mkv_160.png
x265 -> http://s17.postimg.org/mzjs8p1nj/crowd_run_1080p50_265_160.png

[poisondeathray]

What statement are you disagreeing with ? Did you even read or understand what I said ?

My point was all tests have some value. Yes, we should use as non compressed sources as a large part of the testing - but you're missing the whole picture if you don't use an encoder under different usage scenarios . My point is all tests have at least some value.

Disagree where judging between quality is performed on already compressed in lossy way sources - during many years i've learned one thing - lossy compression of lossy compressed sources never gives you decent results. And as i agree that it can be important to evaluate quality based on lossy compressed source then also it can't be limited to this especially that many codecs is sensitive to various compression artifacts.

So ... you're agreeing, not disagreeing

The idea of "compressed" lies along a continuum. Blu-ray is lossy compressed. DVD is lossy compressed. Studio masters in ProRes and DNxHD are lossy compressed. Even redcode "raw" acquisition straight from the camera is lossy compressed. So is it impossible to get "decent results" from testing these ? Do they have zero value ?

Often you want to learn how a codec handles various compression artifacts, because they occur in normal usage scenarios

[poisondeathray]

Atak - thanks for posting results. All tests have some value

I think AQ is still disabled in x265 by default , at least with x265.cc builds - I suspect that would largely explain the results . Earlier it caused crashes , but it should be stable enough with recent builds. It makes a huge difference, just like it does with x264

rev 0.6+108-f25e60a2b62c
x265 -help

--aq-mode Mode for Adaptive Quantization - 0:none 1:aqVariance Default 0
--aq-strength Reduces blocking and blurring in flat and textured areas.(0 to 3.0)<double> . Default 1.000000

[Stears555]

As you can see, the Snajperas's h264 video was worse, (enormous trembling rude hyper-block pixels on the homogenous surface of the engine.)

Especially on the marked surfaces on the engine. Just compare his x264 videos, and my x265 version.

[Stears555]

The other test VIDEO:


I'm curious about the quality of the water droplets of the fountain.


http://diktafon.atw.hu/112.MTS


Please turn of the deinterlacer/automatic deinterlacer in your player. And uSE BT709 colors.

[El Heggunte]

"Down For Everyone Or Just Me" says:

It's not just you! http://diktafon.atw.hu looks down from here.

[Atak_Snajpera]

As you can see, the Snajperas's h264 video was worse, (enormous trembling rude hyper-block pixels on the homogenous surface of the engine.)

Especially on the marked surfaces on the engine. Just compare his x264 videos, and my x265 version.


[Attachment 21821 - Click to enlarge]

Ok I see You are just a 12 year old troll

[pandy]

So ... you're agreeing, not disagreeing

The idea of "compressed" lies along a continuum. Blu-ray is lossy compressed. DVD is lossy compressed. Studio masters in ProRes and DNxHD are lossy compressed. Even redcode "raw" acquisition straight from the camera is lossy compressed. So is it impossible to get "decent results" from testing these ? Do they have zero value ?

Often you want to learn how a codec handles various compression artifacts, because they occur in normal usage scenarios

I agree that under some condition some content can be used but only to particular point - this is same principle as using synthetic patterns to detect some limitations or perhaps using AWGN to test some functionality.
And yes, nowadays almost all sources are lossy but still there is big difference between 10 bit to 8 and 4k to 1080p - redundant (from perceived perspective) amount of data where each codec can show own strength.
So as i can agree for limited amount of tests where source can have limited quality then i disagree to use such content as universal way to describe codec quality.

[Stears555]

As you can see, the Snajperas's h264 video was worse, (enormous trembling rude hyper-block pixels on the homogenous surface of the engine.)

Especially on the marked surfaces on the engine. Just compare his x264 videos, and my x265 version.


[Attachment 21821 - Click to enlarge]

Ok I see You are just a 12 year old troll

I'm 33 years old.

The photo was taken from the original mts file.

(enormous trembling rude hyper-block pixels on the homogenous surface of the engine.)

Especially on the marked surfaces on the engine.

[Stears555]

"Down For Everyone Or Just Me" says:

It's not just you! http://diktafon.atw.hu/112.MTS looks down from here.

The URL is working well. The video is there.

TRY it: http://diktafon.atw.hu/112.MTS

[poisondeathray]

I agree that under some condition some content can be used but only to particular point - this is same principle as using synthetic patterns to detect some limitations or perhaps using AWGN to test some functionality.
And yes, nowadays almost all sources are lossy but still there is big difference between 10 bit to 8 and 4k to 1080p - redundant (from perceived perspective) amount of data where each codec can show own strength.
So as i can agree for limited amount of tests where source can have limited quality then i disagree to use such content as universal way to describe codec quality.

I never said anything remotely close to "use such content as a universal way to describe codec quality" .

A variety of sources , bitrate ranges and scenarios should be used for testing

[Atak_Snajpera]

Atak - thanks for posting results. All tests have some value

I think AQ is still disabled in x265 by default , at least with x265.cc builds - I suspect that would largely explain the results . Earlier it caused crashes , but it should be stable enough with recent builds. It makes a huge difference, just like it does with x264

rev 0.6+108-f25e60a2b62c
x265 -help

--aq-mode Mode for Adaptive Quantization - 0:none 1:aqVariance Default 0
--aq-strength Reduces blocking and blurring in flat and textured areas.(0 to 3.0)<double> . Default 1.000000

It still looks bad

x265 rev 0.6+110-c6c73ef24c97 (UTC 6:50:54 PM)
previous settings + --aq-mode 1 --aq-strength 1
https://mega.co.nz/#!VAFWzKKZ!EbXieQMnf1T6OpDAMfIMYQzU-O9kMEKP02sRcRC-zww
AVERAGE BITRATE: 5390 kbps

x264
previous settings but --crf 33.75
https://mega.co.nz/#!5MUzFIII!MmvljggQTpKTUKjzzOT7t184WI9RLFTeqXPPYpfHO8w
AVERAGE BITRATE: 5381 kbps

[poisondeathray]

Atak - I haven't look at your test, but in my tests as well, the early x265 AQ implementation isn't scaled properly yet. It needs higher values to produce similar results to x264 AQ scale . At least it doesn't crash anymore

[El Heggunte]

The URL is working well. The video is there.

TRY it: http://diktafon.atw.hu/112.MTS

The problem of course is, not everybody lives or works in Budapest

But nevermind, I will try to use a proxy server

[Stears555]

Atak - thanks for posting results. All tests have some value

I think AQ is still disabled in x265 by default , at least with x265.cc builds - I suspect that would largely explain the results . Earlier it caused crashes , but it should be stable enough with recent builds. It makes a huge difference, just like it does with x264

rev 0.6+108-f25e60a2b62c
x265 -help

--aq-mode Mode for Adaptive Quantization - 0:none 1:aqVariance Default 0
--aq-strength Reduces blocking and blurring in flat and textured areas.(0 to 3.0)<double> . Default 1.000000

It still looks bad

x265 rev 0.6+110-c6c73ef24c97 (UTC 6:50:54 PM)
--aq-mode 1 --aq-strength 1
https://mega.co.nz/#!VAFWzKKZ!EbXieQMnf1T6OpDAMfIMYQzU-O9kMEKP02sRcRC-zww
AVERAGE BITRATE: 5390 kbps

x264
https://mega.co.nz/#!5MUzFIII!MmvljggQTpKTUKjzzOT7t184WI9RLFTeqXPPYpfHO8w
AVERAGE BITRATE: 5381 kbps

Did you use bad quality camcorder?

[Atak_Snajpera]

Atak - thanks for posting results. All tests have some value

I think AQ is still disabled in x265 by default , at least with x265.cc builds - I suspect that would largely explain the results . Earlier it caused crashes , but it should be stable enough with recent builds. It makes a huge difference, just like it does with x264

rev 0.6+108-f25e60a2b62c
x265 -help

--aq-mode Mode for Adaptive Quantization - 0:none 1:aqVariance Default 0
--aq-strength Reduces blocking and blurring in flat and textured areas.(0 to 3.0)<double> . Default 1.000000

It still looks bad

x265 rev 0.6+110-c6c73ef24c97 (UTC 6:50:54 PM)
--aq-mode 1 --aq-strength 1
https://mega.co.nz/#!VAFWzKKZ!EbXieQMnf1T6OpDAMfIMYQzU-O9kMEKP02sRcRC-zww
AVERAGE BITRATE: 5390 kbps

x264
https://mega.co.nz/#!5MUzFIII!MmvljggQTpKTUKjzzOT7t184WI9RLFTeqXPPYpfHO8w
AVERAGE BITRATE: 5381 kbps

Did you use wrong quality camcorder?

LOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO OOOOOOOOOOOOOOOOOL

You are a true TROOOOOOOOLL

ftp://vqeg.its.bldrdoc.gov/HDTV/SVT_MultiFormat/SVT_MultiFormat_v10.pdf

[Stears555]

Atak - thanks for posting results. All tests have some value

I think AQ is still disabled in x265 by default , at least with x265.cc builds - I suspect that would largely explain the results . Earlier it caused crashes , but it should be stable enough with recent builds. It makes a huge difference, just like it does with x264

rev 0.6+108-f25e60a2b62c
x265 -help

--aq-mode Mode for Adaptive Quantization - 0:none 1:aqVariance Default 0
--aq-strength Reduces blocking and blurring in flat and textured areas.(0 to 3.0)<double> . Default 1.000000

It still looks bad

x265 rev 0.6+110-c6c73ef24c97 (UTC 6:50:54 PM)
--aq-mode 1 --aq-strength 1
https://mega.co.nz/#!VAFWzKKZ!EbXieQMnf1T6OpDAMfIMYQzU-O9kMEKP02sRcRC-zww
AVERAGE BITRATE: 5390 kbps

x264
https://mega.co.nz/#!5MUzFIII!MmvljggQTpKTUKjzzOT7t184WI9RLFTeqXPPYpfHO8w
AVERAGE BITRATE: 5381 kbps

Did you use wrong quality camcorder?

LOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO OOOOOOOOOOOOOOOOOL

You are a true TROOOOOOOOLL

ftp://vqeg.its.bldrdoc.gov/HDTV/SVT_MultiFormat/SVT_MultiFormat_v10.pdf

A camcorder from 2006

Are these teenagers your schoolmates?

[Stears555]

The URL is working well. The video is there.

TRY it: http://diktafon.atw.hu/112.MTS

The problem of course is, not everybody lives or works in Budapest

But nevermind, I will try to use a proxy server

Try it with www -tags:

http://www.diktafon.atw.hu/112.MTS


A snapshot from the fountain

[Brad]

ftp://vqeg.its.bldrdoc.gov/HDTV/SVT_MultiFormat/SVT_MultiFormat_v10.pdf

A camcorder from 2006

Are these teenagers your schoolmates?

You're making a fool of yourself.

[Mephesto]

ftp://vqeg.its.bldrdoc.gov/HDTV/SVT_MultiFormat/SVT_MultiFormat_v10.pdf

A camcorder from 2006

Are these teenagers your schoolmates?

You're making a fool of yourself.

Agreed.

I commend Atak Snajpera for conducting all these tests. Next time, take a screenshot from both codec outputs (without indicating which one is which), present it to the OP and let him objectively prove which is better quality by selecting the right one. If he selects a x264 frame, the gag's on him.

I stress how important it is for everyone to be completely impartial. Yes x265 will outclass x264 soon but that's not the case yet. Reality should always take precedence over fanboyish fantasies. Don't spread misguided propaganda in the hope that your lies will eventually become truth as development progresses. Never assume you're addressing illiterate morons who can't add two and two together.

People at hydrogenaudio are falsely advertising Opus as being the highest quality codec because they hope by the time the public starts questioning the validity of their bullshit that Opus' quality will progress enough for their premature propaganda to be justified.

This works on morons, not on pragmatic people who double-check their shit, pros and newbs alike.

In the end it's just a damn video format. Acquire some self-dignity and don't make your entire livelihood revolve around it.

[racer-x]

In the end it's just a damn video format. Acquire some self-dignity and don't make your entire free time revolve around it.

Perfect............couldn't have said it better myself.

[vhelp]

i suspect either a player/decoder issue for both those earlier x264 / x265 png's postings, or 0.6+89 build is borked for { --preset medium } unless you added other params not mentioned in those.

i received different results than the ones originally posted on page 1 or 2.

i used {x265 0.6+86 build } { --preset ultrafast --crf 17 } and encoded the clip. the results of that is represented below.

edit 1: wups, i copy/pasted/uploaded the sample clips from the posts. be right back with the correct ones.

edit 2: here is the correct sample.

[_Al_]

something is not right, that picture looks virtually identical on screen to that one Atack Snajpera x264 png, he posted on the top of this page

[vhelp]

i updated the sample in the previous post, sorry about the confusion. the correct version is now available in above post.

[Stears555]

When the windows Vista and Win7 appeared, many young people demanded the XP op system for their brand new PC and Laptop. I first used MS DOS than Windows 3.1 than Win95 Wing98 etc...
So XP was just an newer Op. system for me. However the XP means THE OP.SYSTEM for the young people, because when they started to use computer, the XP was THE FIRST op.system which they knew.


The same childish emotional prepossessions are true for video codecs too.
These forum members are teens or so-called junior aged (under 25years) x264 "fan-boys". When they started to edit / compress videos, the h264 (the x264) was the king of compression. When I started to edit / compress videos , the mpeg 1 mpeg II (DVD age) and h.263 (divx than xvid) became the king, the h264 based codecs were JUST A NEWER codec. For these young guys, the x264 IS THE CODEC.
That's why they are so emotionally and irrationally biased.



Now the young x264 fan-boys will say, that they are hundred years old, )))..and they started to experiment with early digital videos with Philo Taylor Farnsworth in the 1960s.

[pandy]

I never said anything remotely close to "use such content as a universal way to describe codec quality" .

A variety of sources , bitrate ranges and scenarios should be used for testing

Yes but in this topic only one content was used and this where i disagree - trying to pretend that source is irrelevant from codec point of view (where for psycho-visually tuned codecs this can be extremely important)

And as a principle i have no doubts that H.265 will be superior to H.264 but i think that today is to early to do serious quality comparison - we need more time, H.265 need more time - to be mature and understood.

[pandy]

A camcorder from 2006

http://www.arricsc.com/camera/765.html

Try to buy one... not sure that your car will be sufficient for bank as a collateral but perhaps home will be enough...

People at hydrogenaudio are falsely advertising Opus as being the highest quality codec because they hope by the time the public starts questioning the validity of their bullshit that Opus' quality will progress enough for their premature propaganda to be justified.

Isn't MPC (Musepack) is highest quality audio lossy codec?

[Atak_Snajpera]

i suspect either a player/decoder issue for both those earlier x264 / x265 png's postings, or 0.6+89 build is borked for { --preset medium } unless you added other params not mentioned in those.

i received different results than the ones originally posted on page 1 or 2.

i used {x265 0.6+86 build } { --preset ultrafast --crf 17 } and encoded the clip. the results of that is represented below.

edit 1: wups, i copy/pasted/uploaded the sample clips from the posts. be right back with the correct ones.

edit 2: here is the correct sample.

Sorry mate but you made two serious mistakes!
According to screenshot you used 720p version (http://media.xiph.org/video/derf/y4m/park_joy_420_720p50.y4m) not 1080! (http://media.xiph.org/video/derf/y4m/park_joy_1080p50.y4m)

Another mistake is that you have lowered CRF value (--crf 17)!!! This means that encoder can spend more bits ! Higher bitrate means higher quality and FILE SIZE!

LOOK at my test with AQ on and with latest build . Remember bitrate/file size MUST be more or less the same!

http://media.xiph.org/video/derf/y4m/park_joy_1080p50.y4m
x265 rev 0.6+110-c6c73ef24c97 (UTC 6:50:54 PM)
x265 --preset medium --crf 28 (default value) --fps 50 --aq-mode 1 --aq-strength 1
https://mega.co.nz/#!VAFWzKKZ!EbXieQMnf1T6OpDAMfIMYQzU-O9kMEKP02sRcRC-zww
AVERAGE BITRATE: 5390 kbps

x264 --preset veryslow --crf 33.75
https://mega.co.nz/#!5MUzFIII!MmvljggQTpKTUKjzzOT7t184WI9RLFTeqXPPYpf HO8w
AVERAGE BITRATE: 5381 kbps

Screenshots for lazy people
x264 -> http://i.cubeupload.com/de2PZl.png
x265 -> http://i.cubeupload.com/pvx9Jh.png