x265 vs x264

[x265]

While it's interesting to compare 2 different video encoding standards (H.265 vs H.264), x265 is not competing with x264.

x264 is the best H.264 encoder implementation available. A big reason for this success is the open source business model.

The x265 project hopes to replicate this success, in part by leveraging as much of the x264 code (algorithms and features) as possible, and in part by utilizing the same open source business model.

There are vast differences. x265 implements a different video coding standard, and this standard (and our software) is relatively new. x264 is a highly mature, highly optimized software library.

While it's clear that more advanced video encoding techniques can provide greater encoding efficiency (lower bit rate for a desired level of quality), it's also clear that these advanced techniques require far greater compute resources. We want the higher quality video... but we want don't want to wait hours (or days) for it to encode, or drain our battery when we're trying to watch HEVC video on a mobile device.

We're calling x265 pre-alpha because it is not feature complete. This doesn't mean that it doesn't work... it just means that it doesn't have all of the features we expect in a full version 1.0.

To clarify the earlier concern - there are AVX and AVX2 optimizations, but none of these advance instruction sets are mandatory. x265 identifies and takes advantage of processors with SSE and AVX instructions, but x265 can run without them.

Tom
MulticoreWare

[deadrats]

I think that point is clear - there is no x265 vs x264 - x265 is in stage not even pre-alfa thus comparing it to x264 is simply unfair (for x265). We need more time, x265 need lot of work then perhaps thread like such can be reborn. For today x265 can't be compared to mature x264.

i take it you didn't read the article, not only can x265 be compared to x264 but in the comparison x265 won hands down, i'm not the one saying it, it's the testers that said that.

[deadrats]

@x265

allow me to begin by saying i appreciate both your company's attempts to being an open source h265 encoder to the average consumer as well as your participation in this forum.

having said that, allow me to offer you this opinion: you guys have screwed up royally with x265 and your project is barely off the ground.

first things first, x264 is not the best h264 encoder on the market, it's the most heavily promoted by a group of fanatical users that have a near religious devotion to Jason and anything he says is taken as sacrosanct.

his darkness, as i like to call it, along with the penguin, as the main developers, made a number of design decision from early days of x264 that pigeon holed x264 into a development path it should never have been taken down.

furthermore, DS and friends defended said decisions with near fanatical fervor. the biggest mistake ever made in the development of x264 was the extensive use of hand coded assembler, in an effort to extract maximum execution speed of the code. hand coded assembler should be used sparingly, to speed up critical portions of a program but the core of a program is best coded in an easily portable language, such as C/C++ and a well optimized compiler should be relied on for producing fast executing code.

DS and penguin spent years writing extremely targeted code, which makes portability extremely difficult and spent almost an equal amount of time spreading FUD as to why gpu acceleration was either not possible or required simple algorithms which result in degraded visual quality, depending on how he was feeling that day. he spent post after post saying it wasn't possible to use OCL to accelerate x264, he was proven wrong when an OCL patch was produced and released, as well as that university that managed to accelerated i believe it was motion search via OCL. then he said that avx "was float only, thus useless bunch of tripe" (i remember that quot like it was yesterday), then someone released an avx patch and Jason said "oh well, i always said the 3-operand capabilities of avx would be useful). then he was asked if it would be possible to build an h265 encoder using the x264 framework as a starting point, he again said no, it would be too difficult but that if someone wanted to try they would be free to give it a shot.

you guys come along and decide to do just that and what does he do? he insulted you and your company by actually saying, over at doom9, in a thread you posted in, that x265 exists as an open source project because he allows it!!! really? x264 is gpl'd code, anyone can use the code anyway they want as long as they release the code back as gpl code.

so my question to you is, and this is a serious question, not meant as flame bait, not meant as trolling, i would really like an answer: why would you and your company use the x264 code base as a starting point?

i know you have said that you would like to replicate x264's commercial success with it's dual licensing scheme via x264LLC for x265 but you must realize that DS and company would never allow you guys to take the food out of their mouths. x264 generates a bunch of dough for DS and friends via corporate sponsorship and licensing to sites like youtube and broadcasting companies; don't you realize that if x265 gets developed to the point where it would be a viable competitor to x264 for licensing dollars that DS and friends would do their best to discredit x265, either by starting an all encompassing FUD campaign or claiming that you are violating the gpl or maybe even suing you. Jason doesn't want to see you succeed, the success of x265 means the demise of x264, at the very least he would try to sue over some imagined trademark infringement claim.

then you can the technical obstacles, x264 is chock full of hand coded assembler, this makes porting, maintaining and expanding large portions of it that much more difficult, it forces you to have multiple code paths and optimizations for a wide range of processors and adds to code bloat.

the Strongene h265 encoder doesn't feature anywhere near the amount of advanced features that the h265 spec allows for, but it produces excellent quality.

you guys should ditch the silly notion to create a x265 encoder based on the x264 code base and should instead take the bare bones reference h265 code base and concentrate on porting that C code to CUDA. you envision creating an h265 version of x264 and then marketing/licensing the resultant h265 encoder to current x264 licensees, making a ton of money and using the current x264 user base as a way of building market presence.

this business plan will be a failure, you are already late to the market, Strongene already has a cheaply licensed hevc encoder (they charge $2 per encoder license with a minimum of 20,000 licenses required, IIRC) and divx will soon be releasing a free to end users h265 encoder as well as a commercial license version via rovi/mainconcept sdk and the rovi people have promised a gpu accelerated hevc encoder soon.

if you guys hope to succeed you're going about it the wrong way, it took x264 years before it achieved any significant market penetration, despite corporate sponsorship since 2005. in the otehr thread you stated that you guys are engineers and understand gpu acceleration and multi-threading, etc.

i would argue that you guys should be hiring business consultants, people that know zip about writing software and coding an encoder but understand business concepts such as the life of money, ROI, market penetration and competitive advantage. you can't succeed when your product is based off a competitors frame work, regardless of whether you think you are in competition with x264.

you need to rethink your positioning of x265, your competitors are not just other h265 encoder vendors but in fact every other codec currently on the market, that includes all h264 encoders, including x264, vp8, vp9, vc-1, future codecs not yet released such as DAALA, everyone is a competitor.

you should decouple your firms success or failure from the strength and weaknesses of the x264 code base, as well as the whims of the major x264 users and developers and instead focus on establishing a niche that no one is currently competing in and has the technological potential to drive growth and sales of x265 for years to come. that's a CUDA powered version of the h265 reference encoder.

think of it this way, the encoding performance of x265 as it stands now, based on the x264 framework, is abysmal, at under 2 frames per second, even if off the shelf commodity cpu's double in performance each year it would take 4 years before we got to real time 1080p encoding on sub-$200 cpu's. but $200 graphics cards today have thousands of "cores" with substantial on board ram, if you guys released a CUDA powered hevc encoder that was capable of doing say 20fps at 1080p, enthusiasts would flock to it and you guys could make tons of money by licensing to broadcasting companies and VOD sites with the argument that with very cheap pc's they can stream HD h265 in real time.

i think you're missing a golden opportunity and if you guys stick on your current path your competitors will golden shower you.

thanks for reading, now go do exactly as you have been doing so far, ignore everything i just said and watch as x265 sputters and stalls.

-chris.

[x265]

@x265

allow me to begin by saying i appreciate both your company's attempts to being an open source h265 encoder to the average consumer as well as your participation in this forum.

Thanks!

having said that, allow me to offer you this opinion: you guys have screwed up royally with x265 and your project is barely off the ground.

Wait... what?!

first things first, x264 is not the best h264 encoder on the market, it's the most heavily promoted by a group of fanatical users that have a near religious devotion to Jason and anything he says is taken as sacrosanct.

Wherever I go, x264 is recognized as one of the best H.264 encoders available anywhere. The testing done by Moscow State University shows this to be true, but more importantly, experts that I speak with at commercial companies involved in video hardware, software and content acknowledge this nearly universally. Keep in mind that some commercial encoders were not available to Moscow State University, but these are also fairly expensive implementations.

his darkness, as i like to call it, along with the penguin, as the main developers, made a number of design decision from early days of x264 that pigeon holed x264 into a development path it should never have been taken down.

furthermore, DS and friends defended said decisions with near fanatical fervor. the biggest mistake ever made in the development of x264 was the extensive use of hand coded assembler, in an effort to extract maximum execution speed of the code. hand coded assembler should be used sparingly, to speed up critical portions of a program but the core of a program is best coded in an easily portable language, such as C/C++ and a well optimized compiler should be relied on for producing fast executing code.

DS and penguin spent years writing extremely targeted code, which makes portability extremely difficult and spent almost an equal amount of time spreading FUD as to why gpu acceleration was either not possible or required simple algorithms which result in degraded visual quality, depending on how he was feeling that day. he spent post after post saying it wasn't possible to use OCL to accelerate x264, he was proven wrong when an OCL patch was produced and released, as well as that university that managed to accelerated i believe it was motion search via OCL. then he said that avx "was float only, thus useless bunch of tripe" (i remember that quot like it was yesterday), then someone released an avx patch and Jason said "oh well, i always said the 3-operand capabilities of avx would be useful). then he was asked if it would be possible to build an h265 encoder using the x264 framework as a starting point, he again said no, it would be too difficult but that if someone wanted to try they would be free to give it a shot.

I understand your point about hand-coded assembly language optimization vs. C/C++ source code. While assembly language is harder to maintain, ultimately you can't beat the speed of hand-tuned assembly language code. The topic of developer productivity vs. performance portability is something that MulticoreWare has particular expertise in, and we have built a variety of tools that address these issues... (http://multicorewareinc.com/compiler.html

you guys come along and decide to do just that and what does he do? he insulted you and your company by actually saying, over at doom9, in a thread you posted in, that x265 exists as an open source project because he allows it!!! really? x264 is gpl'd code, anyone can use the code anyway they want as long as they release the code back as gpl code.

I didn't read that the same way that you did. Yes, anyone could fork x264 into another GPL project, including an HEVC encoder. But that doesn't provide us with a viable business model.

so my question to you is, and this is a serious question, not meant as flame bait, not meant as trolling, i would really like an answer: why would you and your company use the x264 code base as a starting point?

i know you have said that you would like to replicate x264's commercial success with it's dual licensing scheme via x264LLC for x265 but you must realize that DS and company would never allow you guys to take the food out of their mouths. x264 generates a bunch of dough for DS and friends via corporate sponsorship and licensing to sites like youtube and broadcasting companies; don't you realize that if x265 gets developed to the point where it would be a viable competitor to x264 for licensing dollars that DS and friends would do their best to discredit x265, either by starting an all encompassing FUD campaign or claiming that you are violating the gpl or maybe even suing you. Jason doesn't want to see you succeed, the success of x265 means the demise of x264, at the very least he would try to sue over some imagined trademark infringement claim.

then you can the technical obstacles, x264 is chock full of hand coded assembler, this makes porting, maintaining and expanding large portions of it that much more difficult, it forces you to have multiple code paths and optimizations for a wide range of processors and adds to code bloat.

the Strongene h265 encoder doesn't feature anywhere near the amount of advanced features that the h265 spec allows for, but it produces excellent quality.

you guys should ditch the silly notion to create a x265 encoder based on the x264 code base and should instead take the bare bones reference h265 code base and concentrate on porting that C code to CUDA. you envision creating an h265 version of x264 and then marketing/licensing the resultant h265 encoder to current x264 licensees, making a ton of money and using the current x264 user base as a way of building market presence.

this business plan will be a failure, you are already late to the market, Strongene already has a cheaply licensed hevc encoder (they charge $2 per encoder license with a minimum of 20,000 licenses required, IIRC) and divx will soon be releasing a free to end users h265 encoder as well as a commercial license version via rovi/mainconcept sdk and the rovi people have promised a gpu accelerated hevc encoder soon.

if you guys hope to succeed you're going about it the wrong way, it took x264 years before it achieved any significant market penetration, despite corporate sponsorship since 2005. in the otehr thread you stated that you guys are engineers and understand gpu acceleration and multi-threading, etc.

i would argue that you guys should be hiring business consultants, people that know zip about writing software and coding an encoder but understand business concepts such as the life of money, ROI, market penetration and competitive advantage. you can't succeed when your product is based off a competitors frame work, regardless of whether you think you are in competition with x264.

you need to rethink your positioning of x265, your competitors are not just other h265 encoder vendors but in fact every other codec currently on the market, that includes all h264 encoders, including x264, vp8, vp9, vc-1, future codecs not yet released such as DAALA, everyone is a competitor.

you should decouple your firms success or failure from the strength and weaknesses of the x264 code base, as well as the whims of the major x264 users and developers and instead focus on establishing a niche that no one is currently competing in and has the technological potential to drive growth and sales of x265 for years to come. that's a CUDA powered version of the h265 reference encoder.

think of it this way, the encoding performance of x265 as it stands now, based on the x264 framework, is abysmal, at under 2 frames per second, even if off the shelf commodity cpu's double in performance each year it would take 4 years before we got to real time 1080p encoding on sub-$200 cpu's. but $200 graphics cards today have thousands of "cores" with substantial on board ram, if you guys released a CUDA powered hevc encoder that was capable of doing say 20fps at 1080p, enthusiasts would flock to it and you guys could make tons of money by licensing to broadcasting companies and VOD sites with the argument that with very cheap pc's they can stream HD h265 in real time.

i think you're missing a golden opportunity and if you guys stick on your current path your competitors will golden shower you.

thanks for reading, now go do exactly as you have been doing so far, ignore everything i just said and watch as x265 sputters and stalls.

-chris.

We mentioned that we are able to utilize a some valuable features from x264, but it would be a big stretch to say that we're "basing x265 on x264". We've never said that. The features are porting from x264 represent a small portion of the overall code. Our source code is all publicly available on bitbucket, so I'll leave it as an exercise for the reader to determine the exact percentage.

I agree that HEVC encoding is extremely compute intensive, and that all things being equal the competition will be won or lost based on compute performance (i.e.; how efficiently can the software run on a particular hardware platform?). In this area, I like our chances.


Tom

[Selur]

@deadrats:
a. From my point of view, x264 is the best H.264 encoder out there if the goal is to archive maximum quality at a lower bit rate.
I really would like to test that encoder. I know some people think that x264 should offer a simpler UI, but that hardly is why I would say that x264 is lacking.
-> Which encoder do you think can offer a better quality at low bit rates?
Or do you base your statement on something else (which really doesn't concern the normal prosumer) ?

b. from what I read x265 is not based on x264, it's based on HM 10.
x264 is just salvaged for specific parts which hardly changed from H.265 to H.264 (like in example CABAC).
The MultiCoreWare folks are using, the HM10 codec as basis and swap out existing code with code they take from x264 and code they write on there own, aiming for an early usable code base which bit-by-bit can be optimized and at the end probably mainly consist of non-HM10 code.

@Tom: Thanks for posting and clearing up the whole AVX&Co thing.

Cu Selur

[enim]

Originally Posted by deadrats
first things first, x264 is not the best h264 encoder on the market, it's the most heavily promoted by a group of fanatical users that have a near religious devotion to Jason and anything he says is taken as sacrosanct.

- acquiesce 100%.

Originally posted by x265
Wherever I go, x264 is recognized as one of the best H.264 encoders available anywhere. The testing done by Moscow State University shows this to be true, but more importantly, experts that I speak with at commercial companies involved in video hardware, software and content acknowledge this nearly universally.

I guess your visit to wrong places and wrong people who never seen anything better than x264 yet. The Vodka Pegs University evaluators see everything beautiful after couple of pegs of vodka. You pick any of MSU most famous video filter and see how much it artifacts the video. While high grade and pro H264/AVC encoders remain highly over priced that any average person can ever afford. If you provide craftsman a shit-tool, what quality you expect out of his workmanship?

The most of video enthusiastics has only and the only x264 to play with, they never seen HiQ Pro Grade H264/AVC encoder. If x264 able to produce industry grade quality, most of the BiG B's might have saved lots of money in authoring pro-consumer blu-rays.

But, as a matter of fact, I never seen any blu-ray from BiG B's authored with x264. The x264 remains medocre just in internet media streaming addressing certain class of people to suck more and more. You can pick up/buy any HiQ blu-ray, rip it to HDD, take a small sample with lots of action/motion, and try to encode 8bit with x264 (q=1). See what you get.

Originally posted by x265
Keep in mind that some commercial encoders were not available to Moscow State University, but these are also fairly expensive implementations.

This is because high quality high-end commercial and closed source encoders do not want to undergo reverse engineering.

Originally Posted by deadrats
DS and penguin spent years writing extremely targeted code, which makes portability extremely difficult and spent almost an equal amount of time spreading FUD as to why gpu acceleration was either not possible or required simple algorithms which result in degraded visual quality, depending on how he was feeling that day....

... the biggest mistake ever made in the development of x264 was the extensive use of hand coded assembler, in an effort to extract maximum execution speed of the code. hand coded assembler should be used sparingly, to speed up critical portions of a program but the core of a program is best coded in an easily portable language, such as C/C++ and a well optimized compiler should be relied on for producing fast executing code...

What do you guys expect from the developers who do not know what kind of artifacts their baby is producing. They mis-named more than once.

They completely screwed it up, can not dare compre x264 FPS with pro grade encoders.
Further more x264 developers suggest to use 10bits to avoid grains, this means they agree 8bit encoder produces lots of grains to hide artifacts due to dithering. This is not a valid excuse.

The only reason x264 became popular due to online video content streaming at lower bitrate with reasonable - watchable quality. Still you can see some horrible (raped-n-abused) on line videos on many sites.

Originally posted by x265
While it's clear that more advanced video encoding techniques can provide greater encoding efficiency (lower bit rate for a desired level of quality), it's also clear that these advanced techniques require far greater compute resources. We want the higher quality video... but we want don't want to wait hours (or days) for it to encode, or drain our battery when we're trying to watch HEVC video on a mobile device.

It explains everything and completely contadicts with the HEVC standards. x264 model is the base for x265. We do not expect much here anyways.

Originally posted by x265
The topic of developer productivity vs. performance portability is something that MulticoreWare has particular expertise in, and we have built a variety of tools that address these issues...

We are really, I mean really proud of you guys, looking at Services and MulticoreWare's successful projects such as Android, FFMpeg, x264, HandBrake and VLC.

How many of you are really aware that pro-consumer-grade H265 hardware encoder already hit the market?
Please Do Not ask me like a stupid, or an idiot, Which one? Click HERE
The rest is nothing but a drama to suck in name of Open Source.
But I see lots of resistance to accept universal truth, or acceptance of being sucked.

I do not have to wish Best Luck to MulticoreWare and x265 Team over and over, I already did once before.

It's enough, I guess.

[Selur]

@enim: since you share the opinion that x264 isn't the best H.264 encoder around atm. to you care to share which is and why?

Further more x264 developers suggest to use 10bits to avoid grains, ...

I thought they suggested the use of 10 bit precision encoding to avoid/lessen banding. (sure you can use dithering, too avoid this too, but adding dithering isn't something that should be done by an encoder unless the underlying standard contains this step, like H.264 includes inloop deblocking)

[enim]

@Selur

you care to share which is and why?

Sure, I can, but better if it is left for personal experience.
I am sure that any search engine will pop up with at least 3 to 5 pro high end H264/AVC encoders, or more.

[Selur]

@enim: Sorry, but that answer doesn't help at all.

So let me rephrase my questions:
a. What encoder (encoding engines) would from your 'personal experience' be better than x264?
b. Why would you say ( 'personal experience') that encoder (encoding engine) X is better than x264?

Cu Selur

Ps.: Aside from x264 I'm only aware of Mainconcept (DivX based on it) and Ateme which offer competitive H.264 encoders.

[pandy]

While it's interesting to compare 2 different video encoding standards (H.265 vs H.264), x265 is not competing with x264.

But at some point competing with x264 is unavoidable for x265 - everyone agree that H.265 will be used more and more in next years, and we wish to x265 to compete very well with x264 as this is good for everyone.

x264 is the best H.264 encoder implementation available. A big reason for this success is the open source business model.

There is no doubts on this - x264 is best, widely available H.264 implementation.

The x265 project hopes to replicate this success, in part by leveraging as much of the x264 code (algorithms and features) as possible, and in part by utilizing the same open source business model.

Which is smart, logical and good.

We're calling x265 pre-alpha because it is not feature complete. This doesn't mean that it doesn't work... it just means that it doesn't have all of the features we expect in a full version 1.0.

I never claimed that it not work - i've said that it is unfair for x265 to compare it with mature x264 as it will be unfair to compare average adult person with 5 year kid on physical or intellectual capabilities - however it is almost sure that this 5 year old kid can compete and probably win such comparison later.

So Tom and rest of the x265 team, thanks for hard work and all the best in next steps! We (customers) wish you all the best.


PS

There are people that hardly accepting fact that codec can be not design to deal with massive parallel processing efficiently (h.264 is way less efficient than h.265 which was designed with MPP on mind) - also they have some problems to understand why compilers, even latest and most expensive can't produce very efficient code auto-magically and thus why we need hand coded assembly intrinsic, also to understand why other things can't be implemented in particular way.
As a effect such misconceptions, lack of knowledge such threads like this one are created - private war with x264 developers for group of people (dead rats with a few acolytes) - i've call this syndrome of the abandoned mistress.

[Trepack]

When you have a powerful tool in the hands and the work that sucks not the fault of the tool, the fault is his "alleged personal experience", which is the real trash. That you do not know how to work has nothing to do with your tool. IF so much experience and knowledge do you have a better tool and stop both Bla Bla Bla Bla ...

Thanks Tom and the whole team of Multicoreware for offering a free code tool

[DarrellS]

What kept x264 from taking off in the beginning was the average users hardware setup. I was interested in using it when it first came out but my old 64MB graphics card and P4 CPU kept me from using it until I could afford to build a better machine. Once I built the Q6600 machine with a modern graphics card, x264 is all I encode with now. I'm in the same boat now with x265. I'm interested in it and play around with it but until I can afford a new computer with better hardware (some which hasn't even been released to the public yet), I will continue to encode to x264 for my every day encoding since I'm lucky if I get 1fps encode speeds with x265 at 1080p.

In the near future (ASAP), I would really like to see stdin implemented into the x265 encoder like x264 has. I know a few people who have no desire to even test it until it does. Their only other option is to wait until ffmpeg implements the x265 encoder and that may not ever happen if you look at their record with some other encoders. There is a patched ffmpeg but it's based off of hm7 and does nobody any good.

[poisondeathray]

What kept x264 from taking off in the beginning was the average users hardware setup. I was interested in using it when it first came out but my old 64MB graphics card and P4 CPU kept me from using it until I could afford to build a better machine. Once I built the Q6600 machine with a modern graphics card, x264 is all I encode with now. I'm in the same boat now with x265. I'm interested in it and play around with it but until I can afford a new computer with better hardware (some which hasn't even been released to the public yet), I will continue to encode to x264 for my every day encoding since I'm lucky if I get 1fps encode speeds with x265 at 1080p.

1) Also the inclusion of speed optimizations and instruction sets .

From 2005 - 2013, x264 got about 13-15x faster on the same hardware today , and ~4-6x faster on the same hardware from back then. I expect other HEVC implementations to get similar treatment eventually, and new CPU instructions as they come out



2) People don't remember this, but quality was abysmal at first. Way worse than XviD. Slower and lower quality than XviD. The complaint at the time was the "Plastic doll" look, sort of like RM. No detail.

The biggest development quality wise was AQ (actually originally from Haali AQ) , and psy optimizations . They were the main things that separated x264 from other h.264 encoders .

If there is one quality "weakness" currently with HEVC reference encoder, it's lack of AQ ; otherwise it's very strong temporally, very clean encodes

[DarrellS]

Yeah, all the encodes I've done have looked very good except for the first one I did with the TAppencoder. The original file wasn't very good to begin with but it was the smallest file I had to test and it took almost two hours to encode a 300 frame file 320x240 file. The Lentoid encoder was the fastest encoder at 3-5 fps but the watermark turned me off and having to use graph studio and an flv container. I have three bat files made up to create x265 now with the new encoder which makes it a lot easier but with stdin support you could load a file in Virtualdub, do your editing and encode straight to a finished MP4/MKV with audio and video without having to create a 20GB intermediate file and all the extra steps. I do expect the encoder to get a lot faster when we see a finished product. I doubt it will be anywhere near as fast as x264 is now but I could live with it being half as fast or even 1/4 as fast with the video quality and low file size that it would produce.

[enim]

@x265
I just have surfed MultiCoreWare and Bitbucket-x265 website, but, I did not see any words mentioned towards HEVC decoder.

Are you guys at MultiCoreWare planning to bundle decoder with HEVC (x265) encoder?

[deadrats]

People don't remember this, but quality was abysmal at first. Way worse than XviD. Slower and lower quality than XviD. The complaint at the time was the "Plastic doll" look, sort of like RM. No detail.

i remember, but in all fairness the same held true for almost all the h264 encoders, including main concept's and apple's. it was almost like they hadn't figured out how to properly implement the inloop deblocking feature of the h264 spec.

@to all: because i have been working a long week and i'm too tired to address what x265, pandy, Selur and a few other have said individually. allow me to make the following points, some i have made before:

this is primarily aimed at pandy, but allow me to say i understand the use of hand coded assembler quite well and i consider it an example of poor programming technique to make use of extensive hand optimized assembler. it slows down development time, it makes portability more difficult, it requires multiple code paths for each every cpu architecture you wish to support and really doesn't offer that much speed improvement over properly structured C code compiled with a high quality optimizing compiler. intel's compiler does an excellent job optimizing code for intel processors and AMD has a special custom version of gcc designed specifically for compiling highly optimized code for AMD processors. there is no way an independent developer, like the x264 developers, can hand craft assembler better than the compilers designed by the companies that make the processors. intel and AMD spend millions on their compiler development, i would think their engineers would know how to produce binaries that run at maximum speed on their cpu's.

the notion that x264 is the best h264 encoder out there is easily disproved by the following application(s) of logical analysis:

x264 is open source, with any open source project the instructions that comprise the program are open to the public for inspection. if one were to create something that was truly unique and exceptional, the advantage wouldn't last long as competitors would be free to look at your code, see how you did it and either flat out copy your code or simply copy the basic algorithm. either way within a development cycle or two they would have caught up.

but more importantly is the methodology used to "prove" the superiority of x264. the most commonly cited "proof" is the tests done by MSU, but there are numerous problems with using MSU's tests as proof of the quality of the tested encoders. in the past, when MSU failed to show that x264 was the leader of the pack, Jason aka dark shakari aka an over grown baby, went on a diatribe denouncing using PSNR and or SSIM as quality measuring metrics because as he said PSNR and SSIM don't correlate to the way the human eyes measures quality and they unfairly bias against encoders that have psychovisual enhancements.

that's all fine and dandy, but then x264 proponents turn around and point to tests that use PSNR and/or SSIM as proof that x264 is the best, you can't have it both ways, either PSNR/SSIM are invalid metrics for measuring quality and thus MSU's tests are invalid or they are valid metrics for measuring quality and x264's psy optimizations, which by their nature reduce PSNR and SSIM don't improve quality but actually hurt it.

but the logical inconsistency doesn't end there. as i said DS and company in promoting psy-rd and psy-trellis claim that even though they decrease PSNR and SSIM they improve overall subjective quality and are great for keeping minute details. great. enter mb-tree. when mb-tree was first introduced, DS, in his introduction post at doom9 sold mb-tree with the claim that it increases PSNR by up to 70%. i see. so if DS adds a feature that by it's nature decreases PSNR it's a good thing because PSNR is a poor indicator of visual quality and if he adds something that increases PSNR it's also a good thing because PSNR is a metric that shows quality is improved.

making matters worse is that by default, x264 enables both mb-tree and psy-rd, because clearly it makes perfect sense to turn on a feature that increases PSNR by 70% while simultaneously turning on a feature that decreases PSNR and SSIM. and what of psy-trellis? well despite all the supposed benefits we're told not to use it under normal circumstances because it has a tendency to cause artifacts. and this is the encoder that many consider the best in class h264 encoder? one has to wonder just what the **** these people are smoking.

with regards to the extensive use of hand crafted assembler, in the past i speculated that DS and friends use it as a way of having a functional resume, a way to show a prospective employer that they know how to write assembler but one also has to wonder if they use it as a code obfuscation technique in an attempt to prevent competitors from stealing their code.

regardless, x264 doesn't offer any features that other encoders don't also have: ateme, used in nero recode, also has psy optimizations, as does divx; main concept has 3 different settings that independently and collectively behave like mb-tree and i suspect there are commercial encoders that offer similar features.

the best quality improvement x264 ever offered was 10bit encoding, that single handily offers the best quality improvement of any x264 feature but to answer the question of what i consider the best encoder they best quality i have ever seen is with main concepts 10 bit encoding, the resultant quality was amazing, though x264's 10 bit came close.

but the 8 bit x264 encoder? it's crap on a stick on a warm sunny day.

[lordsmurf]

You'll need an appliance to encode H.265 for years.
It's not a computer task anymore than encoding MPEG-2 on a PII way back when.

[deadrats]

You'll need an appliance to encode H.265 for years.
It's not a computer task anymore than encoding MPEG-2 on a PII way back when.

i don't know, there seems to be way more interest these days in h265 encoding than there was years ago in mpeg-2 or even h264.

a lot depends on whether or not nvidia stays true to form and releases a cuda version of the reference h265 encoder or another possibility is intel, in an effort to spur a sputtering pc market and improve it's own bottom lines updates quick sync with hardware h265 encoding and decoding capabilities. you know intel will do that eventually, maybe they will look at the rather disappointing haswell sales and partner up with MS to offer hevc in qs and as a favor to MS make it so that you need MS' latest and greatest OS in order to enjoy it...perhaps a Win 9 in a year or so?

[Selur]

So your points are:

a. x264 can't be the best since it's open source and others would have adopted
b. you don't like the coding style and project decisions
c. you find the settings non-optimal and the development non-consistent
d. you think the quality of the 8bit encoder is 'crap on a stick on a warm sunny day.'

Thanks, for clearing up why you don't like x264.
(Personally I even agree with some of them at least partially, but totally disagree on other points, but I won't argue against your points since they are highly subjective and can be easily seen in another subjective way. At least now I know where you are coming from when you mention stuff like point d .)

Cu Selur

Ps.: Wondering if enim also has the same reasons.

[Steve(MS)]

LS makes a valid point, so far, this encoder appears slow...real slow.
I only re-encode anymore when absolutely necessary--which since hard drives are relatively cheap and media players that can play various formats why re-encode?
Yeah, I know there are the special projects which I suppose this could fall under, then there are those (not that I care) who don't mind running their computers for endless hours re-encoding...isn't that a form of insanity?
Then there is the thing about upgrading to the most insanely priced high end computer components?...please..

This encoder isn't supported at all right now...maybe in 5 years...by then there will be another encoder to take its place...don't you reckon?

But back to the notion of hardware assist (PC-less would be better), real time decoding/encoding would make perfect sense to me.
Really this should be the future for encoding anyway but then they would stick a high price tag on the thing....

[enim]

@Selur

@enim: Sorry, but that answer doesn't help at all. So let me rephrase my questions: a. What encoder (encoding engines) would from your 'personal experience' be better than x264? b. Why would you say ( 'personal experience') that encoder (encoding engine) X is better than x264? Cu Selur Ps.: Aside from x264 I'm only aware of Mainconcept (DivX based on it) and Ateme which offer competitive H.264 encoders.

personal experience is strictly personal something i would restrict and like to keep as personal rather than public. Aside from x264 - L@@k HERE - There are many, But even some commercial H264/AVC encoders are not worth spending heavy money.

Ps.: Wondering if enim also has the same reasons.

I do not care much about coding style, compex codes, or BASIC, FORTRAN, C/C++, or python. In recent past the world already experenced that free fortran compiled tiny bugger outperformed all commercial and still maintained it's position on the top from the rest in it's family.

Only the matter with me is how much details can be preserved intact.
Only reasons I am interested in overall quality and artifacts to be compared with.

[deadrats]

@Selur

the main reason 8bit x264 is crap on a stick on a warm sunny day is because the encodes it produces look like crap, unless you're starting from a pristine source you get all sorts of artifacts, smearing, macroblocking, blurry images and the interface between a light colored object and a dark colored object or an object within a sunny scene but in a shadow tends to blend into the darkness.

the rest, with the PSNR logical inconsistencies, the coding style and development choices are just the cherry on top of the shit sundae that is 8bit x264.

and these guys want to copy that strategy. good luck with that.

[jagabo]

the main reason 8bit x264 is crap on a stick on a warm sunny day is because the encodes it produces look like crap

How about some samples? And the same sources encoded with a "better" h.264 encoder?

[enim]

How about some samples? And the same sources encoded with a "better" h.264 encoder?

Some guy (BiG B) @ DooM already did in past, but his work is not in public domain and copy righted.
Selur can make a request at least.

His exhaustive work supports the claim of deadrats and myself. He might decided not to make it public for some good reasons definitely.

[deadrats]

the main reason 8bit x264 is crap on a stick on a warm sunny day is because the encodes it produces look like crap

How about some samples? And the same sources encoded with a "better" h.264 encoder?

you got it, i'm going to do a small test encode from an adult video i have, i will use Xvid4PSP AND cut a very small sample of the file that features just the face of the actress and the upper torso of the actor in a bed, with no nudity, well within the rules of this forum. i am using this test clip because it is one of the hardest files i have to encode and is my usual go to for tough test material.

for this test i stuck with legally free software, in addition to XvidPSP i also used QS from with handbrake.

now can you recommend a good free file sharing site that will allow me to upload a 310mb file, i cut the 566 test frames and outputted them with x264 lossless so that you can see the source quality as well as experiment for yourself.

[deadrats]

btw, one of my predictions has already come to pass, the first hevc encoded file has already appeared on a torrent site, i can't provide the link because a) it's a xxx focused torrent site and b) linking to torrent sites adult or not is against this forums rules. but it's already started, i predicted 1 year before most of the content on "pirate" sites is h265, the flood is starting and x264's days are numbered.

and i couldn't be happier.

edit: i just checked a certain bay for pirates, hevc encoded files have popped up there as well.

[enim]

Originally posted by deadrats
btw, one of my predictions has already come to pass, the first hevc encoded file has already appeared on a torrent site, i can't provide the link because a) it's a xxx focused torrent site and b) linking to torrent sites adult or not is against this forums rules. but it's already started,

I would consider it a very... very... cheap effort to make HEVC popular.
Where is the free-decoder?
As decoder requires very less power at least Core2Duo would pick up decoding.

HEVC pre-alpha testers like El Heggunte, Vhelp, DarrellS and all others are still struggling hard for many.. many things to be sorted out.

[jagabo]

now can you recommend a good free file sharing site that will allow me to upload a 310mb file

Videohelp now accepts files up to 500MB.

[blud7]

Where is the free-decoder?

DivX player is capable with a plugin.

[DarrellS]

Where is the free-decoder?

DivX player is capable with a plugin.

I don't know. There isn't a multiplexor to mux the x265 video. It supposedly plays an mkv but mkvtoolnix doesn't support x265/HEVC. They have all the files to build your own mkvtoolnix but they don't have a working mkvtoolnix that supports x265.

You can install the latest MP4Box from GPAC and mux from command line to mp4 and playback using the Osmo4 player that comes with it or using MPC-HC.

There isn't a universal format yet so one decoder will want to see .265 while another will want to see .hvc while another wants to see .hm10 etc...