The fascinating quality of x265!1080p video with fast movements in 1300kb/s
40sec, and 4 Megabyte!!!!
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:
+ Reply to Thread
Results 1 to 30 of 77
Last edited by Stears555; 7th Dec 2013 at 08:44.
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.
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 )))
Last edited by Stears555; 7th Dec 2013 at 14:37.
I already did.
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?
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.Never argue with meaningless people over meaningless topics..............
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.
Last edited by Stears555; 8th Dec 2013 at 05:00.
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!
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 ...
Are you blind or just an x265 fanboy/troll ?
Last edited by Atak_Snajpera; 8th Dec 2013 at 11:34.
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.
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.
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
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...
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.
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.
there is no hardware with h.265 support on market...
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
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)
Last edited by El Heggunte; 8th Dec 2013 at 13:35. Reason: disambiguation
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.
I've tried to encode .mts with latest x265 but encoding speed is insanely slooooooooooow. ETA 1h:30min on my Q6600@3Ghz(?!?!).
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.............Never argue with meaningless people over meaningless topics..............
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
Do you have any widely available HW decoder?
Last edited by pandy; 9th Dec 2013 at 04:25.
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.