Best h264 encoder

[spon901]

I want to know what is the best h264 encoder that can accept as input avisynth file. No matter if it is freeware/opensource or commercial software. I want best h264 encode. For MPEG2 CinemaCraft was considered the best. But for h264 ?

Thank You

[davexnet]

X264 is considered the best. You can find a number of GUI's, Ripbot264, StaxRip, Virtualdub2, etc.
Or you can use the X264 command line

[sophisticles]

Lol!

[hello_hello]

x264 is generally the encoder by which all other h264 encoders are compared. In fact x264 is often used as a baseline when comparing other types of encoders. http://www.compression.ru/video/codec_comparison/hevc_2019/#video_codecs

[sophisticles]

x264 is generally the encoder by which all other h264 encoders are compared. In fact x264 is often used as a baseline when comparing other types of encoders. http://www.compression.ru/video/codec_comparison/hevc_2019/#video_codecs

I wonder why that is? Could it have something to do with the fact that it's legally free and can be downloaded and used free of charge?

Meanwhile professional broadcaster pretty much ignore it:

https://www.ateme.com/ateme-provides-4k-uhd-hevc-encoding-major-european-football-tournament/

https://www.ateme.com/

Fox Sports, NBC Sports, European Football broadcasters, Korean TV, pros around the world ignore x264 and x265 and instead spend big money licensing expensive encoders.

http://www.siriuspixels.com/customers.php


The content industry at large uses Ateme, CCE or Main Concept, while YouTube, which everyone always complains about the quality, uses x264 for their avc encodes.

But feel free to keep propagating the myth that x264 is the best encoder.

I will throw you a bone, x264 is the best legally free, cross platform, avc encoder available and x265 is the best legally free, cross platform, hevc encoder available,

But if money is no object? No.

[KarMa]

At spon901. x264

But feel free to keep propagating the myth that x264 is the best encoder.

Back again to embarrass yourself and waste everyone's time?

[hello_hello]

x264 is generally the encoder by which all other h264 encoders are compared. In fact x264 is often used as a baseline when comparing other types of encoders. http://www.compression.ru/video/codec_comparison/hevc_2019/#video_codecs

I wonder why that is? Could it have something to do with the fact that it's legally free and can be downloaded and used free of charge?

Meanwhile professional broadcaster pretty much ignore it:

https://www.ateme.com/ateme-provides-4k-uhd-hevc-encoding-major-european-football-tournament/

https://www.ateme.com/

Fox Sports, NBC Sports, European Football broadcasters, Korean TV, pros around the world ignore x264 and x265 and instead spend big money licensing expensive encoders.

http://www.siriuspixels.com/customers.php


The content industry at large uses Ateme, CCE or Main Concept, while YouTube, which everyone always complains about the quality, uses x264 for their avc encodes.

But feel free to keep propagating the myth that x264 is the best encoder.

I will throw you a bone, x264 is the best legally free, cross platform, avc encoder available and x265 is the best legally free, cross platform, hevc encoder available,

But if money is no object? No.

And once again you've not offered the slightest evidence that x264 is an inferior encoder. Nothing in your post shows that's the case. Every time you've offered encoder comparisons you've ended up proving yourself wrong, despite your unwillingness to admit it, but do you think the siriuspixels encoder would sell for the type of money someone who's asking about encoders here would want to pay anyway? Can you encode an Avisynth script with it as the OP asked?

Why did you post a link referring to HEVC encoding in a h264 thread?

I'll confess I don't know anything about the encoders you linked to, but you've offered nothing to show x264 can't compete or do better at a given bitrate. The OP asked about quality, not encoding speed, and I suspect that's why companies fork out big money for encoders, and at Bluray type bitrates, it'd be a poor encoder that couldn't do a good job.

I'm sure I haven't seen x264 compared to every encoder out there, but then again I can't recall comparisons where it hasn't come out on top for quality at a given bitrate, at least when encoding speed isn't a factor.

You've been dining out on siriuspixels for a few years now without ever showing you have first hand experience using their encoder. At least not to the best of my recollection. https://forum.videohelp.com/threads/369438-Is-x264-the-best#post2366991

Along with some singer/songwriter, you gave MainConcept a plug in that old thread, but can you offer any reviews that don't look like this?
Upload the comparison encodes. Or even a third party review/comparison would be a start.

[sophisticles]

And once again you've not offered the slightest evidence that x264 is an inferior encoder

The burden of proof is not on me, the burden of proof is on the one making the claim, specifically the claim that x264 is the best encoder available.

My position has always been based on logic and reason, something the x264 faithful seem to not be able to bring to bear.

Here, in a nutshell, is my view:

1) The claim that x264 is the best encoder has not been substantiated because none of the available tests have ever included any of the high end, expensive, commercial encoders

They have not included CCE, Ateme, nor any other commercial grade encoder, consequently the tests are incomplete.

2) x264 is open source, meaning anyone can look at the source code for the algorithms used. If x264 was in fact initially superior to other encoders, the developers of those other encoders would have simply copied the algorithms and brought their software up to par. The myth of the superiority of open source software always ignores this reality.

3) The claim that x264 is the best does not line up with reality, major broadcasters, around the world choose to spend significant amounts of money licensing commercial encoders for their use rather than use a legally free variant. Why is that?

4) The claim that x264 is the best does not line up with reality, as proven by the following parallel claims made by the x264 faithful:

a) x264 is the best encoder available.

b) YouTube uses x264 for its avc encodes.

c) YouTube quality sucks.

There is no way to logically reconcile these 3 claims, they lead to a logical fallacy, a contradiction, meaning one of them must be wrong; the most logical candidate is "a".

One last thing, read this:

https://software.intel.com/en-us/articles/evolution-of-hardware-hevc-encode-on-tenth-g...ore-processors

Intel claims that the QS encoder on their new 10th gen cpu's is capable of beating x265 with the very slow preset; if this is true, what do you think it does to x264?

Of course, I have not seen any independent tests, but it has convinced me to build a new system around one of those processors once this is all done.

[badyu17]

So this spon901 is another one of those dummy accounts our lovely troll sophisticles uses to open trolling threads? This guy knows about Avisynth and CinemaCraft being (supposedly) best for MPEG-2 but never heard of x264? Was he living under the rock all these years LOL? And he has 1 post, GTFO
Can some of the admins check this out and clean this up? I know sophi is little bored but c'mon?

[sophisticles]

So this spon901 is another one of those dummy accounts our lovely troll sophisticles uses to open trolling threads? This guy knows about Avisynth and CinemaCraft being (supposedly) best for MPEG-2 but never heard of x264? Was he living under the rock all these years LOL? And he has 1 post, GTFO
Can some of the admins check this out and clean this up? I know sophi is little bored but c'mon?

The mods are free to check the IP addresses of both accounts, I only use this account.

As for "bored", have the mods check the frequency of my posts, I work 6 days a week, Mon-Sat and I went back to night school to get a Bio-Chem degree, I've been taking 12 credits at night, doing numerous reports and papers for my classes.

The only reason I am able to even post today is because I have been working from home due to COVID and I am currently in the middle of a company wide emergency COVID phone meeting.

The reason I posted "LOL" above was because I assumed someone else was trolling and trying to start a discussion.

[poisondeathray]

I want to know what is the best h264 encoder that can accept as input avisynth file. No matter if it is freeware/opensource or commercial software. I want best h264 encode. For MPEG2 CinemaCraft was considered the best. But for h264 ?

"Best" by what criteria ? What scenario ?

1) The claim that x264 is the best encoder has not been substantiated because none of the available tests have ever included any of the high end, expensive, commercial encoders

They have not included CCE, Ateme, nor any other commercial grade encoder, consequently the tests are incomplete.

"best" in what way ? What scenario ?

Commercial encoders are meant for specific scenarios. For example, CCE-HD, Ateme do not have lossless profiles. They are meant for use in specific applications in a specific scenario. They are less flexible. They can't compete in all scenarios. eg. You can't use CCE-HD for low bitrates, 10bit encoding

It's true, that complete testing of all encoders have been lacking.

But other commercial grade encoders have been tested, Mainconcept Broadcast SDK.

2) x264 is open source, meaning anyone can look at the source code for the algorithms used. If x264 was in fact initially superior to other encoders, the developers of those other encoders would have simply copied the algorithms and brought their software up to par. The myth of the superiority of open source software always ignores this reality.

You can't just copy the code and use it in your own encoder, unless you make your source code available too . That's the reality of the current license. Not very many commerical software companies want to do that

Fox Sports, NBC Sports, European Football broadcasters, Korean TV, pros around the world ignore x264 and x265 and instead spend big money licensing expensive encoders.


3) The claim that x264 is the best does not line up with reality, major broadcasters, around the world choose to spend significant amounts of money licensing commercial encoders for their use rather than use a legally free variant. Why is that?

"best in what way ?

Who said anything about broadcast?

Because everyone just "rants and raves" about how "high" the quality is on their AVC broadcast channels all the time, right ? LOL! What planet do you get broadasts from !

Broadcasters choose based on other criteria . Equipment compatibility, hardware support, 24/7 support team. "Quality" often isn't 1st, 2nd or even 3rd on the list. You can't use "unrestricted" settings in a broadcast setting. There are specific buffer restrictions, GOP size, b-frames issues with some equipment . Do you think you can use some slow encode settings for a live broadcast stream or VOD setup ?

e.g BBC got in trouble for this, trying to increase compression (quality at a given bitrate) , stuffing in more b-frames a few years ago in their AVC streams, but some receivers started aborting and playing back with stutter . For broadcast, it' s more about making sure it works

The content industry at large uses Ateme, CCE or Main Concept, while YouTube, which everyone always complains about the quality, uses x264 for their avc encodes.


4) The claim that x264 is the best does not line up with reality, as proven by the following parallel claims made by the x264 faithful:

a) x264 is the best encoder available.

b) YouTube uses x264 for its avc encodes.

c) YouTube quality sucks.

There is no way to logically reconcile these 3 claims, they lead to a logical fallacy, a contradiction, meaning one of them must be wrong; the most logical candidate is "a".

LOL! What community college logic class did you fail ?

Why are you even comparing Youtube to broadcast? Completely different scenarios. YT AVC uses ~2x lower bitrates compared to AVC broadcast streams. Guess what happens when you use low bitrates (and distributed encoding) with any encoder?

I'm looking at a 1080i Sky HD stream right now (European Football ..."soccer" for us) , it's ~12.5 Mb/s . Do you think YT allocate that much bitrate for 1080p30 , or even 1080p60 ?



Is this a low bitrate scenario for the OP ? Maybe we should do a youtube bitrates scenario test ? Or maybe a very low bitrate test? With single node (not distributed encode like youtube), and unrestricted settings?

[Mr_khyron]

The content industry at large uses Ateme, CCE or Main Concept, while YouTube, which everyone always complains about the quality, uses x264 for their avc encodes.


4) The claim that x264 is the best does not line up with reality, as proven by the following parallel claims made by the x264 faithful:

a) x264 is the best encoder available.

b) YouTube uses x264 for its avc encodes.

c) YouTube quality sucks.

There is no way to logically reconcile these 3 claims, they lead to a logical fallacy, a contradiction, meaning one of them must be wrong; the most logical candidate is "a".

Vimeo use x264 on there h264 streams, Vimeo video quality is god.
x264 win

[sophisticles]

@pdr:

You can't just copy the code and use it in your own encoder, unless you make your source code available too . That's the reality of the current license. Not very many commerical software companies want to do that

Do not be naive, while technically the GPL does require you to release the source and any modifications you make to it, as a practical matter there is n way to prevent the copying of the code. If you worked as a programmer for Ateme, CCE, Main Concept, or someone else and you wanted to make a name for yourself, and you were absolutely convinced that x264 was superior to your company's encoder, even if the company didn't explicitly instruct you to copy the code, you wouldn't look at it to see what they were doing differently?

Moe importantly, you don;t even need to do that, because all of the stuff, with the exception of mbtree, that DS claimed credit for predates his involvement with x264 by at least a decade.

AQ was patented back in 1995:

https://patents.google.com/patent/US5650860A/en

Trellis was patented as far back as 1988:

https://patents.google.com/patent/US4980897A/en

https://patents.google.com/patent/US6937617B2/en

RDO was patented back in 2011:

https://patents.google.com/patent/US10602151B1/en

Psychovisual optimizations patents have existed since at least the 90's:

https://patents.google.com/patent/US5835627A/en

There's nothing special about x264, regardless of what the blind faithful would have us believe.

Because everyone just "rants and raves" about how "high" the quality is on their AVC broadcast channels all the time, right ? LOL! What planet do you get broadasts from !

The 1080p60 broadcast I see from my capable company vary based on the station, but the sports broadcasts from Fox and NBC are top notch.

LOL! What community college logic class did you fail ?

The funny thing is that this semester I did take a class in Propositional Logic, I got an A. And for the record, it's not a community college, it's a state college.

I'm looking at a 1080i Sky HD stream right now (European Football ..."soccer" for us) , it's ~12.5 Mb/s . Do you think YT allocate that much bitrate for 1080p30 , or even 1080p60 ?

You got me with this one, I had never bothered to check how much bit rate YT uses, but I just checked a couple of 1080p and 1080p60 videos, including some UFC and some Motor Trend and the bit rates varied between as low as 900 kb/s to as high as 3 mb/s. I'm really surprised by this.

[spon901]

Thanks for the answers.
Opensource is good until some point. Not necessary best in its class, and usually never best in its class. This is why I asked about best h264 encoder. The goal is to encode at around 10Mbit using High profile 8 bit. For DVD's the best considered was CIncemaCraft which was far supperior in quality ans peed compared to the opensource alternative TMPGENC. For h264 i never tried CinemaCraft, that's why I put this question. I am interested in best quality. I don't care about speed and also not about money.

[Cornucopia]

It was superior in quality. It was never superior in speed unless you threw quality out the window.

Soph actually did acqiesce and summed it up: for all low/no-cost, and all low-mid bitrate, and all varied-use and software-based encodes, x264 and x265 are the best in their class. I think that's usually enough for most users here.

Scott

[stonesfan99]

"Best" is a relative term. Best free encoder would probably be x264. I personally like NVENC because it's fast but it needs more bitrate to look as good as a similar x264 encode.

[poisondeathray]

@pdr:

You can't just copy the code and use it in your own encoder, unless you make your source code available too . That's the reality of the current license. Not very many commerical software companies want to do that

Do not be naive, while technically the GPL does require you to release the source and any modifications you make to it, as a practical matter there is n way to prevent the copying of the code. If you worked as a programmer for Ateme, CCE, Main Concept, or someone else and you wanted to make a name for yourself, and you were absolutely convinced that x264 was superior to your company's encoder, even if the company didn't explicitly instruct you to copy the code, you wouldn't look at it to see what they were doing differently?

For sure, I would if I was a coder . I would look to see what I could improve. This is old stuff, 10-12 years. If nobody could improve on it, maybe there is no incentive or no market for it.

But on the business side - many companies have risk management policies, there are some risks they simply do not want to take. I don't know enough details about IP law, and what parts fall under what coverage

Moe importantly, you don;t even need to do that, because all of the stuff, with the exception of mbtree, that DS claimed credit for predates his involvement with x264 by at least a decade.

AQ was patented back in 1995:

https://patents.google.com/patent/US5650860A/en

Trellis was patented as far back as 1988:

https://patents.google.com/patent/US4980897A/en

https://patents.google.com/patent/US6937617B2/en

RDO was patented back in 2011:

https://patents.google.com/patent/US10602151B1/en

Psychovisual optimizations patents have existed since at least the 90's:

https://patents.google.com/patent/US5835627A/en

There's nothing special about x264, regardless of what the blind faithful would have us believe.

Those concepts are nothing new - but the specific implementation of AQ, fine tuning and weighting took time to refine back then. Lots of testing and feedback, many point releases. That's what set it apart. And the head to head testing demonstrated that.

If you recall, Mainconcept introduced AQ around the same time. If you look at those old comparisions, MC's implementation basically did nothing. Those were the years x264 dominated AVC comparisons, even against Ateme (who had psy opts and AQ long before x264 - Ateme really was the pioneer). x264's AQ implementation really was the turning point. Prior to that, it look like rmvb (basicallly oversmoothed mush). xvid looked better than x264 prior to that.

A Lada is a "car", but a Ferarri Enzo is a "car" too. A Ford Model T is a "car" too. Since they are all "cars" you come to the conclusion that the Lada, the Ferarri, The Model T are "nothing special" - What fallacy is that ?

[hello_hello]

And once again you've not offered the slightest evidence that x264 is an inferior encoder

The burden of proof is not on me, the burden of proof is on the one making the claim, specifically the claim that x264 is the best encoder available.

I never said it was the best. I said it's the encoder by which others are often measured in comparisons.
The burden of proof excuse is just that, an excuse. Even if I'd made a claim and you've stated otherwise, if you can't prove it then you're just as guilty of posting an unsubstantiated one.

My position has always been based on logic and reason, something the x264 faithful seem to not be able to bring to bear.
Here, in a nutshell, is my view:

1) The claim that x264 is the best encoder has not been substantiated because none of the available tests have ever included any of the high end, expensive, commercial encoders

They have not included CCE, Ateme, nor any other commercial grade encoder, consequently the tests are incomplete.

2) x264 is open source, meaning anyone can look at the source code for the algorithms used. If x264 was in fact initially superior to other encoders, the developers of those other encoders would have simply copied the algorithms and brought their software up to par. The myth of the superiority of open source software always ignores this reality.

3) The claim that x264 is the best does not line up with reality, major broadcasters, around the world choose to spend significant amounts of money licensing commercial encoders for their use rather than use a legally free variant. Why is that?

4) The claim that x264 is the best does not line up with reality, as proven by the following parallel claims made by the x264 faithful:

a) x264 is the best encoder available.

b) YouTube uses x264 for its avc encodes.

c) YouTube quality sucks.

There is no way to logically reconcile these 3 claims, they lead to a logical fallacy, a contradiction, meaning one of them must be wrong; the most logical candidate is "a".

So you have nothing but theories and conjecture?
The reality of it is, you can take almost any Bluray video, encode it at a decent quality with x264 (CRF18 or CRF16 etc) and the resulting bitrate will often be substantially lower without a noticeable loss of quality, so logically it should be as good as the original encoder when using an identical bitrate. That's about the closest I've come to comparing x264 with "industry" encoders, and it certainly doesn't show x264 is inferior.

I don't pay much attention to YouTube video, but if we're just basing arguments on theory and conjecture, I could argue that YouTube uses x264 because they encode at low bitrates and x264 results in the least sucky quality at those bitrates. It's more logical than your "lets use a bad encoder" theory, when Google could afford to use any encoder.

I've seen lots of iTunes video and I'm confident x264 can do just as well, if not better, at the sort of bitrates Apple uses for iTunes video with whatever encoder they're using.

One last thing, read this:

https://software.intel.com/en-us/articles/evolution-of-hardware-hevc-encode-on-tenth-g...ore-processors

Intel claims that the QS encoder on their new 10th gen cpu's is capable of beating x265 with the very slow preset; if this is true, what do you think it does to x264?

Of course, I have not seen any independent tests, but it has convinced me to build a new system around one of those processors once this is all done.

When did we start comparing different types of encoders in order to prove x264 is inferior to other h264 encoders? It is however, typical of the logic and reasoning you were boasting about.

For the record, the x265 encoder doesn't excite me at all. Admittedly it's been a few years since I've tried it, but when I did it was obvious x264 was better for SD/HD at the same bitrate. At 1080p and CRF18 there wasn't much quality difference between the source and the original for x264, with a resulting bitrate of around 5000kbps. x265 might start to come into it's own for UHD, or it might have improved since then. I don't know.

[Anonymous5394]

[/QUOTE]For the record, the x265 encoder doesn't excite me at all. Admittedly it's been a few years since I've tried it, but when I did it was obvious x264 was better for SD/HD at the same bitrate. At 1080p and CRF18 there wasn't much quality difference between the source and the original for x264, with a resulting bitrate of around 5000kbps. x265 might start to come into it's own for UHD, or it might have improved since then. I don't know.[/QUOTE]

My sentiments too and many others I'm sure. You are always the voice of reason at Video help.

[zizouillette]

Lol!

+1
Because its free it makes sense that it is the best ... Lol again
It reminds me of the time when the same people said that HC encoder or QuEnc were the best mpg2 encoders ... Better than CCE, TMPGenc, CANOPUS PRO CODER .....
and even if x264 was the best .... what's the point, putting videos on youtube, is only useful

The same goes for free software that has become paid.
When they were free there was no better; Xvid4PSP, ConvertXtoDVD, TMPGenc ....
Since they became paid .... nothing is going right ... there is better for free ... too buggy ... developer sucks

[KarMa]

Here, in a nutshell, is my view:
1) The claim that x264 is the best encoder has not been substantiated because none of the available tests have ever included any of the high end, expensive, commercial encoders
They have not included CCE, Ateme, nor any other commercial grade encoder, consequently the tests are incomplete.

Well that certainly is convenient for you then, as you don't seem to want to spend the money to see if these encoders are any better. So the next best thing for you instead is to just spend your days looking for any thread about x264 to say it isn't the best, promptly provide no samples, and then move onto the next thread. Maybe the US Military has their own H.264 encoder that we can never get to, maybe China has a secret H.264 encoder, maybe I myself have made a H.264 encoder which will never see the light of day and is the best thing ever. So we will never truly known who has the best encoder, and anyone who says otherwise is just spouting unsubstantiated claims I guess.

2) x264 is open source, meaning anyone can look at the source code for the algorithms used. If x264 was in fact initially superior to other encoders, the developers of those other encoders would have simply copied the algorithms and brought their software up to par. The myth of the superiority of open source software always ignores this reality.

Because copyright isn't a concern? Along with the fact that if you use x264 code as part of your own encoder, then you are required to have the same GNU 2.0 (open source) license. Remember when Cisco tried to patent x264 code?

3) The claim that x264 is the best does not line up with reality, major broadcasters, around the world choose to spend significant amounts of money licensing commercial encoders for their use rather than use a legally free variant. Why is that?

They use hardware encoders, which are cheaper to run and probably many times more reliable over the years.

This also brings up questions of why doesn't Hollywood use FLAC for everything and dump Dolby TrueHD or DTS-HD. Why do American broadcasts still use AC3, when AAC existed at the swithover to digital. Why is ATSC 3.0 destined to use AC4 from Dolby, when we have OPUS and AAC which don't have any license fees. For ATSC 3.0 why not stick with AC3 (whose patent has finally run out), instead of going for Dolby's latest cash grab of AC4? This logical world that you think exists, doesn't.

b) YouTube uses x264 for its avc encodes.

Prove it. You are talking about a company that gets 300 hours of content uploaded every minute, to which they have to make a 1080p/720p/480p/360p/240p/144p versions of the same video. They are going to use standard CPUs? Youtube's AVC encodings don't even have that many B-Frames. I doubt much of any of Youtube's encodings are x86/x64 based but instead custom ASIC type hardware. Besides recent AV1 encodings which are limited to the most popular of content.

Looking through YT's AVC videos, I'm just not seeing x264 being used.

c) YouTube quality sucks.

AVC encodings are bad on YT, but you are not one that should be throwing stones with your history.

There is no way to logically reconcile these 3 claims, they lead to a logical fallacy, a contradiction, meaning one of them must be wrong; the most logical candidate is "a".

Prove B then

https://software.intel.com/en-us/articles/evolution-of-hardware-hevc-encode-on-tenth-g...ore-processors

Intel claims that the QS encoder on their new 10th gen cpu's is capable of beating x265 with the very slow preset; if this is true, what do you think it does to x264?
Of course, I have not seen any independent tests, but it has convinced me to build a new system around one of those processors once this is all done.

Don't think anyone has uploaded a H264 QS encoding sample that can beat x264. Not even x264 Fast.

Vimeo use x264 on there h264 streams, Vimeo video quality is god.
x264 win

After downloading a Vimeo video they do seem to use x264. With the normal x264 parameters being visible in Mediainfo, along with the h264 stream being similar to my own x264 encodings. In contrast, nothing about Youtube's AVC video suggests they use x264.

[davexnet]

I have a 2010 release Mainconcept Reference on an XP install. For lower bitrates (I chose 2400 kbps for 1280x720),
it was clearly worse than today's X264, with noticeable difficulties in flat parts.

However, I also downloaded a new demo of MC Totalcode and this is much improved. Which one is better now is not so obvious.

The source is 1080p, movie preview, Bluray source. Resized in the encoders (MCTC 5.0 and Vidcoder X264 latest beta) to 720p.

[sneaker]

Why do companies subscribe to Red Hat Linux for $1,300 per year and server when they could just download the latest Ubuntu .iso for free?
When companies buy H.264 encoders from the big companies they are also buying support and a solution to integrate those into their workflows. x264 is free like the Ubuntu .iso but the broadcasters don't have the know-how to just download from the x264 git and integrate it into their broadcasting servers. You can't just drop x264.exe into your broadcasting workflow like you can drop it into a simple software like MeGUI.

You know who has the know-how to integrate x264? The top-software companies like Google and Netflix who also do actual research into improving encoding quality (e.g. VMAF). So Google and Netflix get the best quality H.264 encoder because they care and can. Broadcasters buy some other encoder that comes with more support and better integration into their workflows because they don't have the same kind of resources and know-how as Google and Netflix (or it's simply cheaper for them to buy such a solution than to hire and pay for software engineers who could integrate x264 for them).

[Mr_khyron]

After downloading a Vimeo video they do seem to use x264. With the normal x264 parameters being visible in Mediainfo, along with the h264 stream being similar to my own x264 encodings. In contrast, nothing about Youtube's AVC video suggests they use x264.

YouTube is using X264 https://www.youtube.com/watch?v=OiEqN-2zkjE

General
Complete name : J:\temp\youtube.com\Video\ASSASSIN'S CREED VALHALLA Trailer (2020) HD-OiEqN-2zkjE.mp4
Format : MPEG-4
Format profile : Base Media
Codec ID : isom (isom/iso2/avc1/mp41)
File size : 75.9 MiB
Duration : 4 min 40 s
Overall bit rate : 2 267 kb/s
Writing application : Lavf58.35.100

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4
Format settings : CABAC / 3 Ref Frames
Format settings, CABAC : Yes
Format settings, Reference frames : 3 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 4 min 40 s
Bit rate : 2 131 kb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 30.000 FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.034
Stream size : 71.3 MiB (94%)
Title : ISO Media file produced by Google Inc.
Writing library : x264 core 155 r2901 7d0ff22 <---------
Color range : Limited
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709
Codec configuration box : avcC

Audio
ID : 2
Format : AAC LC
Format/Info : Advanced Audio Codec Low Complexity
Codec ID : mp4a-40-2
Duration : 4 min 40 s
Bit rate mode : Constant
Bit rate : 128 kb/s
Channel(s) : 2 channels
Channel layout : L R
Sampling rate : 44.1 kHz
Frame rate : 43.066 FPS (1024 SPF)
Compression mode : Lossy
Stream size : 4.29 MiB (6%)
Title : ISO Media file produced by Google Inc.
Default : Yes
Alternate group : 1

Why do companies subscribe to Red Hat Linux for $1,300 per year and server when they could just download the latest Ubuntu .iso for free?
When companies buy H.264 encoders from the big companies they are also buying support and a solution to integrate those into their workflows. x264 is free like the Ubuntu .iso but the broadcasters don't have the know-how to just download from the x264 git and integrate it into their broadcasting servers. You can't just drop x264.exe into your broadcasting workflow like you can drop it into a simple software like MeGUI.

You know who has the know-how to integrate x264? The top-software companies like Google and Netflix who also do actual research into improving encoding quality (e.g. VMAF). So Google and Netflix get the best quality H.264 encoder because they care and can. Broadcasters buy some other encoder that comes with more support and better integration into their workflows because they don't have the same kind of resources and know-how as Google and Netflix (or it's simply cheaper for them to buy such a solution than to hire and pay for software engineers who could integrate x264 for them).

Broadcasters like sky is using X262, X264, Avisynt+, ffmpeg, FFAStrans etc a brodcaster only need an asic Mpeg2/h264 /H265 encoder when they send live event.

[Sharc]

I have a 2010 release Mainconcept Reference on an XP install. For lower bitrates (I chose 2400 kbps for 1280x720),
it was clearly worse than today's X264, with noticeable difficulties in flat parts.

However, I also downloaded a new demo of MC Totalcode and this is much improved. Which one is better now is not so obvious.

The source is 1080p, movie preview, Bluray source. Resized in the encoders (MCTC 5.0 and Vidcoder X264 latest beta) to 720p.

Both look good, but MC softens the picture and looses details more than x264. See for example the texture of the guy's shirt around frame 510 onwards. It seems still to be difficult to beat x264 with respect to preserving details.

[sophisticles]

I have a 2010 release Mainconcept Reference on an XP install. For lower bitrates (I chose 2400 kbps for 1280x720),
it was clearly worse than today's X264, with noticeable difficulties in flat parts.

However, I also downloaded a new demo of MC Totalcode and this is much improved. Which one is better now is not so obvious.

The source is 1080p, movie preview, Bluray source. Resized in the encoders (MCTC 5.0 and Vidcoder X264 latest beta) to 720p.

Thank you for this, if truth be told I am unable to see a difference between any of them in the environment I am now, sitting in my well lit office in front of an AIO with overhead lights on and plenty of sunshine, all three look very similar to me.

However as I have said before, x264 (and similar open source projects) have a significant advantage for the average user, because it is legally free and cross platform, one could build a cheap encoding server using a BSD based distro or a Linux based distro and open source tools and save a bunch of money, so in that sense, yes x264 would be the best software AVC encoder available.

But I have never seen any test that didn't use cherry picked samples, with limited participants and questionable testing methodologies that "proved" x264's superior quality, nearly all the tests suffered from confirmation bias and were carried out by people that had already made up their minds either on this or the doom9 forums and then they went out and created testing scenarios to support their beliefs.

[sophisticles]

Why do companies subscribe to Red Hat Linux for $1,300 per year and server when they could just download the latest Ubuntu .iso for free?
When companies buy H.264 encoders from the big companies they are also buying support and a solution to integrate those into their workflows. x264 is free like the Ubuntu .iso but the broadcasters don't have the know-how to just download from the x264 git and integrate it into their broadcasting servers. You can't just drop x264.exe into your broadcasting workflow like you can drop it into a simple software like MeGUI.

You know who has the know-how to integrate x264? The top-software companies like Google and Netflix who also do actual research into improving encoding quality (e.g. VMAF). So Google and Netflix get the best quality H.264 encoder because they care and can. Broadcasters buy some other encoder that comes with more support and better integration into their workflows because they don't have the same kind of resources and know-how as Google and Netflix (or it's simply cheaper for them to buy such a solution than to hire and pay for software engineers who could integrate x264 for them).

This is hysterical!!! You say "Netflix get the best quality H.264 encoder because they care and can" and you also say that NetFlix uses x264 so you have made my point, I have never seen anyone that doesn't complain about NetFlix quality, it sucks, everything looks soft as ice cream.

Have you ever seen a NetFlix stream that doesn't suck? That's why NetFlix partnered with Intel and are working on switching to Intel's SVT family of encoders, because NetFlix's avc offerings are so lousy,

Thank you.

[sophisticles]

Don't think anyone has uploaded a H264 QS encoding sample that can beat x264. Not even x264 Fast.

I agree with your Intel's QSV H264 encoder has been broken, since the Ivy Bridge days. I tried it when I had a 2600 and it was pretty good, with Ivy Bridge it had a well documented regression, I tried it with Haswell on Windows and it sucked, I have tried Sky Lake on Windows and it wasn't based, Kaby Lake on Linux is so bad I wonder if there's a bug in the SDK or if the drivers are broken, it macroblocks no matter what I do, it's unusable.

But Intel's HEVC and 10-bit HEVC QSV on Linux are very good, especially the 10-bit one, it's possible to beat them if you crank up the settings on x264 and x265 to the very slow presets but by then the encoding times become so long you're better off just upping the bit rate on QSV and calling it a day.

[poisondeathray]

Thank you for this, if truth be told I am unable to see a difference between any of them in the environment I am now, sitting in my well lit office in front of an AIO with overhead lights on and plenty of sunshine, all three look very similar to me.

This is meaningless, because you can't tell the difference between a low bitrate youtube encode , and one that uses offline encoding, slow settings with 2x higher bitrate. (And I'm going to hold that over your head forever )

But I have never seen any test that didn't use cherry picked samples, with limited participants and questionable testing methodologies that "proved" x264's superior quality, nearly all the tests suffered from confirmation bias and were carried out by people that had already made up their minds either on this or the doom9 forums and then they went out and created testing scenarios to support their beliefs.

Some test designs are poorly constructed, some sources are questionable. Many are incomplete or lacking . The problem is it takes a lot of time to do proper, comprehensive testing.

So point out the testing flaws and repeat them, and add other sources. Which types of sources does it tend to do poorly on ?

If some commercial encoder could make money from this, wouldn't they cherrypick their own tests? Wouldn't they shout from the rooftops? It's poor marketing otherwise. The fact that you didn't see any tests showing the opposite during the period where x264 dominated speaks volumes.

So cherrypick your own tests in the opposite direction - to show how "bad" x264 is. I have, to expose the various flaws. I would cherrypick sources and tests where x264 would "fail". I have a bunch of sources saved. Sources with skies, fades, prone to banding. That's the most common complaint. But the problem is other AVC encoders perform even worse in those tests

You can structure a test design how ever you like. If you prefer to test PSNR for your scenario or purposes , then you can test for PSNR . I believe we did this recently where you picked the source. Pick another if you want

This is hysterical!!! You say "Netflix get the best quality H.264 encoder because they care and can" and you also say that NetFlix uses x264 so you have made my point, I have never seen anyone that doesn't complain about NetFlix quality, it sucks, everything looks soft as ice cream.

Have you ever seen a NetFlix stream that doesn't suck? That's why NetFlix partnered with Intel and are working on switching to Intel's SVT family of encoders, because NetFlix's avc offerings are so lousy,

Compared to what ?

Netflix uses adaptive bitrates , but what "average" bitrate do you think they used for a 1080p24 AVC "movie" on a broadband home connection (in the pre-COVID era, they use lower bitrates now)

Did you test AVC encoder "B" or "C" or "D" with the same source, same bitrate ?

Netflix is switching to Intel SVT AV1. We are talking about AVC. Is it any wonder that a last generation (really a 1.5 generation old) encoder performs worse ?

Don't think anyone has uploaded a H264 QS encoding sample that can beat x264. Not even x264 Fast.

But Intel's HEVC and 10-bit HEVC QSV on Linux are very good, especially the 10-bit one, it's possible to beat them if you crank up the settings on x264 and x265 to the very slow presets but by then the encoding times become so long you're better off just upping the bit rate on QSV and calling it a day.

But Intel needs to shrink their process node . You typically use a CPU for other tasks as well. Nvidia makes more sense for most people, also very good , very fast encodes. We need AMD to step up their game for encoding

[sophisticles]

If some commercial encoder could make money from this, wouldn't they cherrypick their own tests? Wouldn't they shout from the rooftops? It's poor marketing otherwise. The fact that you didn't see any tests showing the opposite during the period where x264 dominated speaks volumes.

It does speak volumes, it says that x264 and the clown show behind their development don't amount to a pimple on the ass of the major commercial offerings.

DivX bought Main Concept for 22 million bucks plus another 6 million for reaching certain goals about 13 years ago, then Rovi sold both DivX and MC for 75 million, I can't find how much Silicon Philosophies, the people that own CCE are worth as a company but I think they have to be generating a pretty decent buck considering how many major broadcasters use their encoder, Ateme has a market cap rate of just under 130 million dollars, these guys have no desire to compare their software to a free alternative; it's kind of like why Ford, Dodge and Toyota will compare their vehicles to Ferrari, Porsche and Maserati but the opposite is not the case.

So cherrypick your own tests in the opposite direction - to show how "bad" x264 is.

I don't believe I have ever said it's bad. I have said that it has a reputation for being the best that is unjustified, I have said that the developers and users have been disingenuous and ruthless promoters without regards to the truth, I have said there are issues with the encodes it produces but I never said it was bad. In fact, I have repeatedly said that all encoders are pretty much the same so long as someone doesn't bit rate starve their encodes.

But Intel needs to shrink their process node . You typically use a CPU for other tasks as well. Nvidia makes more sense for most people, also very good , very fast encodes. We need AMD to step up their game for encoding

AMD is in a very weird position and to a lesser extent so is Intel; on the desktop there are only a few "killer apps" or workloads that drive cpu sales and the demand for faster CPUs, gaming, 3d rendering, DAW, and video related work.

AMD has decided that it would attack Intel by having a core count advantage at every price point and they have been able to achieve that thanks to their superior manufacturing process.

For 3d rendering, video work and gaming, if we're being honest with ourselves, a video card is more important than a CPU but AMD has decided to flip that on it's head and push the limit as to how many CPU cores can effectively be used on the desktop; AMD has admitted that they are running into I/O bottlenecks with their 64C/128T generosity.

AMD has committed to the CPU portion of their business being the revenue generator and they will not do anything that will poach sales from their CPU division and that includes a hardware encoder, the only reason they have one is because Intel and NVIDIA have them.

Intel is in a similar position, the difference is that AMD has them beat in process node and core count and so they can't out CPU AMD so they have more motivation to develop a solution that can steal sales from AMD.

NVIDIA is the one that has the most motivation to bring to market a great hardware encoder, they do not make CPU's (despite the fact that they would love to) so they do not have a division from which to cannibalize sales, and they have the most to gain. If they bring a hardware AV1 encoder to market either with Ampere or with whatever follows it, they effectively control the narrative, because AV1 encoding is ridiculously slow on even the fastest CPU's.