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

[Stears555]

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

40sec, and 4 Megabyte!!!!

WOOOOW.




The original h264 source file is 70Mbyte: http://dictaphone.atw.hu/mozdony.MTS


(it is progressive segemneted frame, please switch off the deinterlacer/automatic deinterlace setting in your player.

The output x265 file is only 4Mbyte, and progressive.


Watch the attached x265 file, and share your opinion!

I must repeat myself:

[Mephesto]

1. That's not a "fast moving video" it's a video of a static scene where nothing except the camera is moving which compresses real easy with modern codecs.

2. It's 24 seconds, not 40.

3. The quality sucks. Details are all blurred and gone, edges are distorted. This is visible without even comparing to original.

4. The quality is exactly the same as x264 at exactly the same filesize. Both scored 0.95429 SSIM.

5. Only thing fascinating is your gullibility.

[Stears555]

1. That's not a "fast moving video" it's a video of a static scene where nothing except the camera is moving which compresses real easy with modern codecs.

2. It's 24 seconds, not 40.

3. The quality sucks. Details are all blurred and gone, edges are distorted. This is visible without even comparing to original.

4. The quality is exactly the same as x264 at exactly the same filesize. Both scored 0.95429 SSIM.

1. That's not a "fast moving video" it's a video of a static scene where nothing except the camera is moving which compresses real easy with modern codecs.

2. It's 24 seconds, not 40.

3. The quality sucks. Details are all blurred and gone, edges are distorted. This is visible without even comparing to original.

4. The quality is exactly the same as x264 at exactly the same filesize. Both scored 0.95429 SSIM.

Prove it!

You can download the original file and transform it

It was a simple average bitrate 1-pass x265 encoding.

Please upload your 4Mega 1 pass x264 1300 Kbit/s average bitrate video with medium preset...

I'm afraid, your video image (with similar presets) will be detonated like a puzzle with this bitrate )))

[Mephesto]

I already did.
http://www.sendspace.com/file/jtwnnh

I'm not sure what a medium preset is but I did use faster settings since the video was 1080p and I didn't want it to take forever. You can also use something besides ABR with x265, they have a QP. What H265 encoder was used?

[racer-x]

The only fascinating thing I notice is I only have 2 players that can play that x265.mp4 on my system, MPC-HC and FF-Play. It's a huge resource hog using about 60% to play at full 25 fps.....

This maybe interesting in a few years when hardware catches up, but for now it's just a yawn for me as I have no use for it right now.

[Stears555]

Mephesto's video is a scam. I tried to play his video with many video players (VLC , MPC-HC , Windows Media player, pot player, SM player, M player) but his video was choppier than a silent film from the 1890s.
Half of the temporal information is lacking in his video.
He dropped every second frame with a video editor, than he reduplicated the remained frames. So the temporal info is half of the original. Even with this primitive trickery, his video quality was worse. See the wavering super-macro blocks in the engine.

[Gomorrite]

There are duplicate frames in Mephesto's video, just not 1 every 2, it's more like a duplicate every 3 or 5 frames.

Smooth textures look better in x264, complex textures (trees) look better in x265. No winner!

[Stears555]

There are duplicate frames in Mephesto's video, just not 1 every 2, it's more like a duplicate every 3 or 5 frames.

Smooth textures look better in x264, complex textures (trees) look better in x265. No winner!

He hacked the framerate. It looks like an early silent film from the 1890s. (perhaps 12-15 FPS).
The original video was 25FPS.

[Atak_Snajpera]

x264 --preset medium -> http://www.mediafire.com/download/33845kaxvvc8u8i/mozdony-default.mkv
x264 --preset veryslow -> http://www.mediafire.com/download/s30vh42gnw9cac1/mozdony-veryslow.mkv
x264 --preset veryslow 10bit -> http://www.mediafire.com/download/0p7wrx35ar3dzmt/mozdony-veryslow-10bit.mkv

x264 has also no problem to achieve the same quality and whole encoding process is alot faster than on x265. Your sample is too easy to compress. flat sky and so on ...

[Stears555]

x264 --preset medium -> http://www.mediafire.com/download/33845kaxvvc8u8i/mozdony-default.mkv
x264 --preset veryslow -> http://www.mediafire.com/download/s30vh42gnw9cac1/mozdony-veryslow.mkv
x264 --preset veryslow 10bit -> http://www.mediafire.com/download/0p7wrx35ar3dzmt/mozdony-veryslow-10bit.mkv

x264 has also no problem to achieve the same quality and whole encoding process is alot faster than on x265. Your sample is too easy to compress. flat sky and so on ...

Sorry, but:
Blocky, waving, shaking huge superbocks on the homogenous surfaces of the engine even in "very slow mode".

You can't see such problems with x265.

[Atak_Snajpera]

Are you blind or just an x265 fanboy/troll ?

x264 veryslow
http://s23.postimg.org/pxxp60mqz/x264_frame_62.png

http://s23.postimg.org/5b4e6ydyj/x264_frame_330.png

x265

http://s23.postimg.org/csi6zwsvf/x265_frame_62.png

http://s23.postimg.org/c5jaadvzf/x265_frame_330.png

[deadrats]

@Atak_Snajpera

it's well known that you are a sux264 fanboy, i'm pretty sure i've seen your posts over at the dipshit9 forums being DS' butt buddy, like most of the x264 worshipers there's little to know objectivity and i predicted a long time ago that DS' followers would launch fud campaigns to discredit any h265 encoder.

having said that, the sample Stears may be easy to compress but there is no question that all the currently available h265 encoders, Strongene, Divx's and x265 beat x264 and there's no question that the HM reference encoder beats all of them.

my question is what are they doing in the name of "optimizations" via assembler and simd that results in lower quality, they have to be taking math shortcuts to get the calculations to finish faster.

i think everyone would have been better served if someone would just take the reference encoder and stick with pure C, optimize it as much as they can sans any assembler or simd, port it over to cuda and then thread the shit out of it.

[Atak_Snajpera]

I have nothing against x265 (HEVC) . x264 also had problems few years ago vs mpeg-4 asp (XviD). Lack of details. Surfaces looked like somebody applied photoshop's surface blur. But after implementation of AQ and Psy-RD things have changed. Competition was left behind. The bar was raised really high. It will take years before x265 will give ~40% smaller size at the same quality as x264.

[poisondeathray]

If you guys have done any recent tests, x265 is looking much much better now , and the AQ implementation is working semi-ok now . No longer produces turd results. Very impressive rate of development over the last few months

[pandy]

PNG's from Atak_Snajpera proved that currently x265 offer lower quality than x264.
x265 need lot of development before it will be comparable to x264 and there is no hardware with h.265 support on market...

[Stears555]

PNG's from Atak_Snajpera proved that currently x265 offer lower quality than x264.
x265 need lot of development before it will be comparable to x264 and there is no hardware with h.265 support on market...

Wrong, x264 is blocky.
Open your eyes and see the enormous trembling rude hyper-block pixels on the homogenous surface of the engine.

[Atak_Snajpera]

PNG's from Atak_Snajpera proved that currently x265 offer lower quality than x264.
x265 need lot of development before it will be comparable to x264 and there is no hardware with h.265 support on market...

Wrong, x264 is blocky.
Open your eyes and see the enormous trembling rude hyper-block pixels on the homogenous surface of the engine.

I guess you are addicted to photoshop's surface blur ? Sorry but what is the point of having 1920x1080 resolution if all fine details are destroyed ?

[_Al_]

Wrong, x264 is blocky.
Open your eyes and see the enormous trembling rude hyper-block pixels on the homogenous surface of the engine.

Stears555 - it might have spots that are moving but there is details in x264, now, if you have details gone, there is no point to encode it to HD in the first place.

x265 will success, from any direction - either Intel, x265, divX, other encoder, whatever or all of them, but now my PC stutters in one spot to play that x265 sample for me, so what good is it to me?
HVEC is in the process towards perfection, give it a time.

[Mephesto]

He dropped every second frame with a video editor, than he reduplicated the remained frames. So the temporal info is half of the original. Even with this primitive trickery, his video quality was worse. See the wavering super-macro blocks in the engine.

Yup, I also killed Kennedy and masterminded 9/11. Calm down.

I didn't do anything to the video. There's a duplicate every 3-5 frames I noticed but this was the output I got when I ffvideosource'd the .MTS in Avisynth because this always decodes videos frame-accurately and I don't trust directshow. Actually, directshow outputted twice the amount of frames and a very weird framerate (~5.2843839 fps) so for obvious reasons I wasn't gonna do that.

If we can come up with a consensus on a correctly-decoded output of the source video, I'll redo the test but honestly there's no amazing results except that the quality of both are equal. x265 does better in some areas, x264 does better in others and both do worse in different areas. They are tied for now, and incidentally they both scored the EXACT SAME SSIM, I never had that happen before.

racer-x, it takes 17% on my circa-2009 CPU, you need a new box.


Atak_Snajpera, you're wrong. Psy-RD wasn't implemented until mid-2008, that's not why x264 finally beat XviD. I still don't use psy-RD as we speak and the quality remains higher than one, two three or five years ago. As early as January 2006, x264 beat XviD by 50% and even more on animated videos.

Pandy,

there is no hardware with h.265 support on market...

There is hardware support but only in mobile devices.

[Atak_Snajpera]

I've tried to encode .mts with latest x265 but encoding speed is insanely slooooooooooow. ETA 1h:30min on my Q6600@3Ghz(?!?!). x264 with 2-passes and veryslow preset takes only 2min 30s! Without some serious OpenCL optimalization even multi core xenon cpus will be too slow.

BTW. Haali media splitter + ffdshow works the best with .MTS

[_Al_]

I have Intel i5 first generation, and video is not fluent, fascinating.mp4, using latest MPC-HC.
Original mozdony.MTS seems to be progressive, flagged as interlaced.

ffvideosource did not work correctly for me: ffvideosource("mozdony.MTS", threads=1), ffvideosource("mozdony.MTS") did not work at all

but directshow did work: directshowsource("mozdony.MTS", fps=25)

[Atak_Snajpera]

I have Intel i5 first generation, and video is not fluent, fascinating.mp4, using latest MPC-HC.

It works ok on my old Q6600@3Ghz. Keep in mind that this is only 25 fps with fast shutter speed (no motion blur which would hide lack of fps)

[El Heggunte]

I have Intel i5 first generation, and video is not fluent, fascinating.mp4, using latest MPC-HC.

Then use the Lentoid decoder instead of the built-in HEVC decompressor.

[_Al_]

It gives me obvious hiccups , one or two in the middle, .., I understand that this could be my bad, not optimal video setup, MPC-HC, ffdshow, Haali but this is kind of my point because who has it working 100%,

Lentoid, ok, thank you, will look into it

[deadrats]

Without some serious OpenCL optimalization even multi core xenon cpus will be too slow.

i wouldn't hold my breath for that to happen any time soon. tommy boy has made it clear that the corporate sponsors' feature requests and bug reports take priority and accoding to him they have little to no interest in gpu acceleration. of course he also claimed that the corporate sponsors had no interest in std::in support, so...

i think the funniest thing is his claim that multicoreware is comprised of over 200 engineers with vast experience in gpu acceleration and who are experts in gpgpu programming. so what path do they take with their h265 encoder? they embrace a development path that effectively eliminates the possibility of any sort of meaningful gpu acceleration by taking hand optimized assembler code from x264 and trying to shoehorn its algorithms into their encoder. so if they are successful we will end up with an encoder with lots of assembler code that can't be ported to open cl or cuda and at the most it will have gpu accelerated lookahead, probably one of the least intensive parts of the encoding process.

it's a shame, really, the h265 spec was designed from the ground up with heavy threading and gpu acceleration in mind and these guys are following a path that effectively slams the door shut on exploiting that aspect of the spec.

doesn't really matter, they're destined to be also-rans, a footnote in video codec history, much like x262 has ended up.

[racer-x]

I've tried to encode .mts with latest x265 but encoding speed is insanely slooooooooooow. ETA 1h:30min on my Q6600@3Ghz(?!?!).

Really???? Someone please explain why this is progress for encoding a 24 sec clip with crappy quality.........

Call me old fashioned, but I still create most of my HD blu-Rays with High Bitrate Mpeg-2 @ 35 mb/s. Quality is superb and encodes in faster than real-time on my system. I still use x264 for youtube uploads and such though to reduce upload times.............

[vhelp]

the argument is worthless to begin with because, in my opinion, the source video is the problem and a bad choice for such a test. it already has macroblocks or pixelations and other compression artifacts. each encoder x264 vs x265 vs divx vs xvid vs mpeg, etc., will handle them differently with different outcome results.

the best video to test against these encoders is one that has none of the issues i mentioned above. and so far, i only saw one video that met this criteria perfectly, the "tears of steel" but they took the orginal "lossless" .png files off and only offer compressed versions as masters.

[poisondeathray]

the argument is worthless to begin with because, in my opinion, the source video is the problem and a bad choice for such a test. it already has macroblocks or pixelations and other compression artifacts. each encoder x264 vs x265 vs divx vs xvid vs mpeg, etc., will handle them differently with different outcome results.

the best video to test against these encoders is one that has none of the issues i mentioned above. and so far, i only saw one video that met this criteria perfectly, the "tears of steel" but they took the orginal "lossless" .png files off and only offer compressed versions as masters.

I disagree - It's not "worthless", all tests have at least some value, that you can learn something from

Will everyone have a 4k clean master for their everyday use from an F65? No. This is a typical consumer camcorder video. That's what consumers will be expected to have and use.

Encoders are used in different scenarios. Only when you test them fully on different types of sources, bitrate ranges, different scenarios can you have a complete understanding of their strengths and weaknesses.

One test doesn't prove or disprove anything, it's just a data point or observation

[pandy]

Wrong, x264 is blocky.
Open your eyes and see the enormous trembling rude hyper-block pixels on the homogenous surface of the engine.

Nope - i disagree.

Pandy,

there is no hardware with h.265 support on market...

There is hardware support but only in mobile devices.

Nope - on mass, consumer market h.265 is not supported - most of today available TV's with 4k resolution just upscale incoming HD/SD to 4k resolution.
Do you have any widely available HW decoder?

I disagree - It's not "worthless", all tests have at least some value, that you can learn something from

Will everyone have a 4k clean master for their everyday use from an F65? No. This is a typical consumer camcorder video. That's what consumers will be expected to have and use.

Encoders are used in different scenarios. Only when you test them fully on different types of sources, bitrate ranges, different scenarios can you have a complete understanding of their strengths and weaknesses.

One test doesn't prove or disprove anything, it's just a data point or observation

Nope, i disagree - to compare encode efficiency and to avoid error accumulation non compressed sources should be used - if there is doubt then for example compressed source should resized 4- 8 times to reduce already existing errors.

[poisondeathray]

I disagree - It's not "worthless", all tests have at least some value, that you can learn something from

Will everyone have a 4k clean master for their everyday use from an F65? No. This is a typical consumer camcorder video. That's what consumers will be expected to have and use.

Encoders are used in different scenarios. Only when you test them fully on different types of sources, bitrate ranges, different scenarios can you have a complete understanding of their strengths and weaknesses.

One test doesn't prove or disprove anything, it's just a data point or observation

Nope, i disagree - to compare encode efficiency and to avoid error accumulation non compressed sources should be used - if there is doubt then for example compressed source should resized 4- 8 times to reduce already existing errors.

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.