Log in

View Full Version : Overall what's the best H.264 encoder in 2021?


PCU
10th June 2021, 14:02
Overall what's the best H.264 encoder in 2021?
What H.264 encoders are used in BD & Netflix?

microchip8
10th June 2021, 14:18
Still x264

For BD, I think MainConcept is used (might be wrong)

PCU
10th June 2021, 15:26
Still x264

For BD, I think MainConcept is used (might be wrong)

So why does MSU say the Chinese version of these encoders is better?

microchip8
10th June 2021, 15:29
So why does MSU say the Chinese version of these encoders is better?

Because their testing is flawed and biased

PCU
10th June 2021, 16:11
Because their testing is flawed and biased

So why doesn't Doom9 itself make a comparison?

microchip8
10th June 2021, 16:37
So why doesn't Doom9 itself make a comparison?

Doom9 is not an official test entity. All tests are limited and done by users of the forum using different settings to find a balance between compression and speed. There are not many that can get all encoders like MC/Ateme/Chinese ones and do a thorough test, unbiased

PCU
10th June 2021, 17:08
Doom9 is not an official test entity. All tests are limited and done by users of the forum using different settings to find a balance between compression and speed. There are not many that can get all encoders like MC/Ateme/Chinese ones and do a thorough test, unbiased

Thanks for reply.
What about decoders? Is there a difference between them?

benwaggoner
10th June 2021, 19:27
I've seem some pretty impressive Beamr examples showing ~20% bitrate reduction versus x264. The genius features of x264 are CRF and mbtree. And Beamr's psychovisual optimization is now a lot more advanced than CRF.

microchip8
10th June 2021, 19:34
I've seem some pretty impressive Beamr examples showing ~20% bitrate reduction versus x264. The genius features of x264 are CRF and mbtree. And Beamr's psychovisual optimization is now a lot more advanced than CRF.

I disagree. Look at their example on their site where they compare a 1 Mbps source to a 0.6 Mbps encoded Beamr stream. It's pretty blurry to my eyes.

benwaggoner
10th June 2021, 22:44
I disagree. Look at their example on their site where they compare a 1 Mbps source to a 0.6 Mbps encoded Beamr stream. It's pretty blurry to my eyes.
I've not looked at Beamr for reencoding purposes for a long time. I'm speaking of the Beamr 4x encoder where combines the core Vanguard encoder with Beamr perceptual optimization.

PCU
10th June 2021, 22:59
YouTube encoded video benchmarking results with my eyes:
x264: best quality
Google's AV1: blurry comparing to x264
VP9: On2 Technology (now Google) is the worst codec dev company I ever saw in my life!
x264 is so good, see what happens to x266 in the future.

benwaggoner
10th June 2021, 23:09
YouTube encoded video benchmarking results with my eyes:
x264: best quality
Google's AV1: blurry comparing to x264
VP9: On2 Technology (now Google) is the worst codec dev company I ever saw in my life!
x264 is so good, see what happens to x266 in the future.
YouTube uses some quite performance-tuned instead of quality-tuned x264 settings last I looked.

VP9 and AV1 suffer from a lot of PSNR tuning, which tends to blur quite a bit due to poor adaptive quantization. Unfortunately the VMAF metric wasn't tested with a variety of adaptive quantization modes, so doesn't score different modes as having different quality even when they perceptually do.

And AV1 and aomenc were tuned against VMAF much more than subjective quality evaluations, which yields the results you describe. Other AV1 encoders are improving that, but YouTube doesn't use them.

But in general, YouTube isn't a great reference for codec comparisons, as they are very performance-tuned, do a whole lot of segmented encoding. And YouTube gives higher bitrates and encoding time for their politically preferred AV1 and VP9 codecs.

PCU
10th June 2021, 23:34
YouTube uses some quite performance-tuned instead of quality-tuned x264 settings last I looked.

VP9 and AV1 suffer from a lot of PSNR tuning, which tends to blur quite a bit due to poor adaptive quantization. Unfortunately the VMAF metric wasn't tested with a variety of adaptive quantization modes, so doesn't score different modes as having different quality even when they perceptually do.

And AV1 and aomenc were tuned against VMAF much more than subjective quality evaluations, which yields the results you describe. Other AV1 encoders are improving that, but YouTube doesn't use them.

But in general, YouTube isn't a great reference for codec comparisons, as they are very performance-tuned, do a whole lot of segmented encoding. And YouTube gives higher bitrates and encoding time for their politically preferred AV1 and VP9 codecs.

IDK much about AV1, But in 2004, I converted an original video of a game from Bink format to VP4, the quality of everything I did was very blurry, even all EA games using VP4 were blurry too.

mp3dom
11th June 2021, 15:03
Still x264

For BD, I think MainConcept is used (might be wrong)

For official BDs (I mean, pressed and made by authoring houses), MainConcept is still used by "cheap" companies and most of the times the MainConcept version is the old one that comes with old "CineVision for Bluray" encoder (something made years ago).

The encoder used for A+ blurays titles comes from SiriusPixels.
Anyway these are very specific encoders for bluray, you can't compare them with x264. x264 is a multi-purposes encoder that can be restricted to output valid BD streams. BD encoders, on the other side, are built to meet the BD specs and nothing more. Even the encoding engine is made to work better at high bitrates because nobody wants a bluray encoded at 8 mbps. If you encode a video at 4 Mbps with such BD encoders, you'll get total garbage as output.

benwaggoner
11th June 2021, 19:24
IDK much about AV1, But in 2004, I converted an original video of a game from Bink format to VP4, the quality of everything I did was very blurry, even all EA games using VP4 were blurry too.
Yep, none of the VPx series did a good job of adaptive quantization. On2 was very focused on the core encoder being highly tuned for PSNR, and then using advanced postprocessing to suppress defects.

Early Flash video used the VP6 codec, which was a pretty mediocre codec coupled with a really advanced postprocessor. It could do sharpening, smoothing, even synthesize noise. If those got turned off with a flag, the native quality wasn't good at all. And quality was unpredictable as the degree of postprocessing varied with CPU power.

VP3 was the ancient Ogg Theora codec, and VP4 was a mild update of that, without the VP6 postprocessing. VP4 and VP5 were only ever used in vertical products like games AFAIK.

I actually used the original TrueMotion and TrueMotion-S for some games in the 90's. Those were retroactively defined as VP1 and VP2.

Blue_MiSfit
13th June 2021, 08:02
Yeah x264 and Beamr 4x are tough to beat today for typical VOD streaming use cases. Ateme does a really good job in live encoding (to my eyes). Pretty tough to beat.

FranceBB
13th June 2021, 12:28
I've been using x264 for everything for years actually, from low bitrate consumer version in .TS to official Blu-ray encodes in .m2ts to even broadcast quality mezzanine files in AVC Intra Class. It's pretty hard to beat. I even made a comparison a while ago against the proprietary H.264 encoder included by Telestream in Vantage (https://forum.doom9.org/showpost.php?p=1879327&postcount=1), so something that some broadcasters (not us thanks God) use and pay a lot for and... surprise surprise, x264 scored higher even for AVC Intra Class 300 encodes in .mxf. Later on, Telestream guys were so pissed that they eventually included x264 in later versions so that now you can pick which encoder you want. Honestly, I would never swap x264 for anything else nowadays. After years of testing and improvements it's the de facto best H.264 encoder out there (unless you need some really weird and not much supported professional standards like some 12bit AVC flavours which it cannot do... :( )

mp3dom
13th June 2021, 13:10
x264 has some flaws, mainly when vbv is involved, that creates some visible artifacts and these were never fixed but need special tweaks to mitigate.

Blue_MiSfit
13th June 2021, 22:55
@FranceBB, I'd say it's worth doing a Beamr eval. I'm definitely impressed with their stuff. More than I thought I would be!

Sharc
13th June 2021, 23:31
x264 has some flaws, mainly when vbv is involved, that creates some visible artifacts and these were never fixed but need special tweaks to mitigate.
Like this one?
https://forum.doom9.org/showthread.php?t=175662

FranceBB
14th June 2021, 00:53
@FranceBB, I'd say it's worth doing a Beamr eval. I'm definitely impressed with their stuff. More than I thought I would be!

Noted.
I went to their website and I noticed that they're part of the streaming video alliance, a group I'm also part of.
Tomorrow I'll check whether I can find one of them in our Slack group and eventually ask for a trial to test the quality. I can't promise anything though 'cause right now I'm pretty busy trying to encode Dolby Atmos into DolbyED2 without using a Dolby Hardware Encoder

mp3dom
14th June 2021, 01:15
Like this one?
https://forum.doom9.org/showthread.php?t=175662

Yeah, that's one. Another one is when a movie is letterboxed (1:85:1/2.35:1/2.40:1 movie in a 1.78:1 frame for example).

Sharc
14th June 2021, 09:33
Yeah, that's one. Another one is when a movie is letterboxed (1:85:1/2.35:1/2.40:1 movie in a 1.78:1 frame for example).
You mean the first few blurry picture lines adjacent to the letterbox borders, unless it is all mod16?

jpsdr
14th June 2021, 17:50
I've made a quick search, Beamr doesn't seem to be free like x264, am i wrong ?

benwaggoner
14th June 2021, 18:36
I've made a quick search, Beamr doesn't seem to be free like x264, am i wrong ?
You are correct. It is a commercial encoder.

Blue_MiSfit
14th June 2021, 19:30
Yeah if you only want free / open source encoders then forget about anything other than x264 :)

mp3dom
14th June 2021, 20:00
You mean the first few blurry picture lines adjacent to the letterbox borders, unless it is all mod16?

Yeah, exactly. Those AR never have perfect mod16 black bars, so on a bluray encode this means to have almost the whole movie to have blurred lines. Not so problematic when the image is clean, but if there's grain for artistic reasons or due to the filmprint, that's quite visible.

benwaggoner
14th June 2021, 20:20
Yeah, exactly. Those AR never have perfect mod16 black bars, so on a bluray encode this means to have almost the whole movie to have blurred lines. Not so problematic when the image is clean, but if there's grain for artistic reasons or due to the filmprint, that's quite visible.
This taps into my mid-aughts HD-DVD and Blu-ray authoring days.

A common mistake with those encodes was to center in the middle of the 1080 pixels. But 1080 is not mod16 - the mod16 encode is 1088 with the bottom 8 pixels removed. This was a problem with MPEG-2 and VC-1 as it only supported 16x16 macroblocks. Thus proper mod 16x16 framing of a 2.4 title in MPEG-2 or VC-1 isn't 280 top and bottom, but 272 top and 288 bottom.

With H.264, a 4x4 block is only 8x8 with chroma. So you can get away with mod8 from the top and bottom. 280x280 works for 2.4 in H.264.

With 1.85:1 you've got 1038 active pixels out of the 1080 lines, so 42 lines to crop. 42 isn't mod8; you need to round up to 48. Blanking out 24 pixels top and bottom means covering 6 lines of the source, which may be preferable to getting the edge artifacts. Alternatively you could scale the image up to 1040 active pixels and crop 16 top 24 bottom.

For 2.35:1 you've got 817 active pixels. One would mask 132 top and bottom if centering, but those aren't mod8. So, move the image up four pixels and mask 128 top and 136 bottom.

mp3dom
15th June 2021, 13:03
Yeah, but it's something that can't be done... I mean, there's no reason to "un-center" the image just to have mod16 black bars and help x264, because it's visible by naked eye that in that way the image is not centered anymore (which is bad aesthetically). Plus, other encoders doesn't exhibit this type of flaw and a comparison with the same movie made by another distributor will made the "trick" obvious.

The suggestion seems more or less a workaround to overcome the problem...

benwaggoner
15th June 2021, 17:29
Yeah, but it's something that can't be done... I mean, there's no reason to "un-center" the image just to have mod16 black bars and help x264, because it's visible by naked eye that in that way the image is not centered anymore (which is bad aesthetically). Plus, other encoders doesn't exhibit this type of flaw and a comparison with the same movie made by another distributor will made the "trick" obvious.

The suggestion seems more or less a workaround to overcome the problem...
Yes, it is exactly a workaround. Being able to be mod8 in H.264 is a big help compared to MPEG-2 and VC-1. And HEVC has even more flexible block sizing tricks, and can go down to at least mod4 safely.

And we're talking about shifting 6 pixels max out of 1080. I do not think most consumers would even notice it if you asked them if something was odd about the image.

jpsdr
15th June 2021, 18:48
You are correct. It is a commercial encoder.
And i've not been able to see a price on their web page (just out of curiosity). When price is not displayed, never a good thing... Often means it's high.

mp3dom
15th June 2021, 20:03
I do not think most consumers would even notice it if you asked them if something was odd about the image.
I think is just like the dead pixels on an LCD. Once you know they're there, you can't help but see them. :)

benwaggoner
15th June 2021, 22:16
I think is just like the dead pixels on an LCD. Once you know they're there, you can't help but see them. :)
How many customers never realize they have overscan on?

Blue_MiSfit
16th June 2021, 00:47
And i've not been able to see a price on their web page (just out of curiosity). When price is not displayed, never a good thing... Often means it's high.

It's a commercial encoder, so yes generally it's probably not cheap :)

Shoot them an email, there may be a usage model for individuals / small businesses that makes sense. They're good people (and very clever).

Balling
26th September 2021, 12:55
So why does MSU say the Chinese version of these encoders is better?

Where? For hevc Ticktock's hevc encoder is indeed better, just like Mainconcept.

If we are talking about 2012 tests of AVC those are wrong now.

x264 devs are still fixing in 2021 quite hillarious mistakes... https://code.videolan.org/videolan/x264/-/issues/28 So no surprises there.

No surprises about this about Beamr too is bad and is still based on x264 (what changed from 2013?). https://gist.github.com/Daiz/5043109

FranceBB
26th September 2021, 14:52
x264 devs are still fixing in 2021 quite hillarious mistakes...

https://i.imgur.com/NDUS1k0.png

lol >=

Yeah well, that happens...
It shouldn't but it does...

kolak
26th September 2021, 18:02
Where? For hevc Ticktock's hevc encoder is indeed better, just like Mainconcept.

If we are talking about 2012 tests of AVC those are wrong now.

x264 devs are still fixing in 2021 quite hillarious mistakes... https://code.videolan.org/videolan/x264/-/issues/28 So no surprises there.

No surprises about this about Beamr too is bad and is still based on x264 (what changed from 2013?). https://gist.github.com/Daiz/5043109


Same as Telestream GPU accelerated x264 in Vantage.
If you use no acceleration you get 2x slower encoding than x264 itself (one same machine).
If you use GPU acceleration (by buying crazy expensive Tesla card and burning 100s of extra watts) you get about same speed as vanilla x264 on CPU :)

Amazing technology...

rwill
27th September 2021, 08:23
lol >=

Yeah well, that happens...
It shouldn't but it does...

In my opinion using CAVLC with High Profile is somewhat retarded. Never understood AVCI reasoning...

FranceBB
27th September 2021, 08:27
Same as Telestream GPU accelerated x264 in Vantage.

Amazing technology...

Lightspeed or whatever they're called in Vantage are crap.
Seeing how bad and expensive Vantage was is the whole reason why I decided to contribute to FFAStrans in the first place.
And if it wasn't for closed source proprietary stuff like VANC OP47 .stl subtitles mux in mxf and DolbyE encoding we would have succeeded in recreating a better open source transcoder...

VoodooFX
27th September 2021, 15:05
Wait, that Beamr scam is still ongoing? Must be profitable business to scam the investors out of their money. I remember they were offering the infinite compression, not worded as such, but basically what they meant.

kolak
27th September 2021, 16:10
I can offer it today to EVERYONE.
Send me files and I will provide you infinitely compressed version, so nothing :)
Just 1$/minute of content :)

VoodooFX
27th September 2021, 17:09
Yeap, that's what they were selling: bitrate reduction on any video without loss of quality. So if you chain Beamr>Beamr>Beamr..., you are compressing to a singularity, maybe even to a negative bitrate. :D

EDIT:
Most of those wonder technology companies scams out few thousands of $ and disappear, I see this one succeeded in raising the few millions, now they have money to augment their wonders with new fata morganas and try to legitimize in some way, but for how long, time will tell (btw, not comparable, but DivX thing is still ongoing).

Anyone member Theranos? :)

Blue_MiSfit
28th September 2021, 00:34
Beamr is absolutely not nothing :)

I've tested their stuff and it's quite good. Of course you can't just chain it in a loop, that's not how it works. They actually started doing what you're talking about - essentially automated compressed domain transcoding - which wasn't super interesting to me. Then they integrated that IP in-loop with their own encoders (which they acquired from Vanguard). This is actually pretty awesome.

Their Beamr 4x and Beamr 5x encoders are H.264 and H.265 respectively with special rate control methods ("CABR") based on their optimization metrics.

I didn't have the time to do a thorough evaluation but the results are definitely impressive, especially in the OTT use case where you need to build an ABR encoding ladder and the effort involved to do anything more complex than a static ladder recipe is substantial. Being able to just use CABR and say "Spend up to this many bits per second but please use fewer where it makes sense" (kind of a better capped CRF) is pretty great.

Their people are generally really great too. Their technology is not cheap, but if you're in the market for a paid H.264 (or H.265) encoder their stuff is _absolutely_ worth looking at (as is Ateme at least and probably others).

TomV
28th September 2021, 07:38
Beamr is absolutely not nothing :)

I've tested their stuff and it's quite good. Of course you can't just chain it in a loop, that's not how it works. They actually started doing what you're talking about - essentially automated compressed domain transcoding - which wasn't super interesting to me. Then they integrated that IP in-loop with their own encoders (which they acquired from Vanguard). This is actually pretty awesome.

Their Beamr 4x and Beamr 5x encoders are H.264 and H.265 respectively with special rate control methods ("CABR") based on their optimization metrics.

I didn't have the time to do a thorough evaluation but the results are definitely impressive, especially in the OTT use case where you need to build an ABR encoding ladder and the effort involved to do anything more complex than a static ladder recipe is substantial. Being able to just use CABR and say "Spend up to this many bits per second but please use fewer where it makes sense" (kind of a better capped CRF) is pretty great.

Their people are generally really great too. Their technology is not cheap, but if you're in the market for a paid H.264 (or H.265) encoder their stuff is _absolutely_ worth looking at (as is Ateme at least and probably others).
It's funny to read opinions from people who have never actually tested the encoder they're commenting about. Derek (Blue_MiSfit), on the other hand, knows what he's talking about.

Beamr has encoder implementations (Beamr 4 for AVC, Beamr 5 for HEVC), and they have a patented compression technology that they have applied to still image compression as well as AVC, HEVC and other codecs (CABR). Their base encoders are very, very good. Their CABR technology works as advertised. If you haven't evaluated their encoders, I don't know why you would think you are qualified to comment on how they compare.

excellentswordfight
28th September 2021, 12:38
Lightspeed or whatever they're called in Vantage are crap.
Seeing how bad and expensive Vantage was is the whole reason why I decided to contribute to FFAStrans in the first place.
The most annoying part of GPU-encoding on Vantage is that they afaik only support it on their lightspeed hardware, dated hw with an huge markup price.

FranceBB
28th September 2021, 12:57
The most annoying part of GPU-encoding on Vantage is that they afaik only support it on their lightspeed hardware, dated hw with an huge markup price.

Yep. Lightspeed hardware only...

kolak
28th September 2021, 15:37
It's overpriced, but this is enterprise area where everything has huge markup. I'm more shocked by support fees and the way how slowly problems are fixed. This is a joke, real joke.

At least in terms of reliability it sort of works. In the same time any custom made cluster system running ffmpeg (x264/5) on few machines can easily be as reliable.
If you can do a bit of any scripting (Python etc.) then Vantage is a waste of money.

Btw... anyone has Manzanita muxer license to sell?

benwaggoner
29th September 2021, 19:59
Yeah, Beamr is definitely a lot of something! Some people may be thinking of their original business model and technology where they'd take an input file and retroactively apply an advanced flavor of CRF to reduce bitrate where it can be without reducing psychovisual quality significantly.

But then Beamr bought Vanguard a traditional (and very good) encoder company, and integrated their psychovisual tech in with the Vanguard encoders. So no second pass reduction involved, just a more psychovisually tuned encoder.

Balling
2nd October 2021, 01:18
Interesting, then I suppose Beamr should be tested. :)