VVC + xHE-AAC vs AV1 + OPUS at extremely low bitrates and resolution

[birdie]

Just for fun I decided to compare VVC with AV1 at extremely low bitrates given that Russia has throttled YouTube to impossible to use 128 kbps (that's kilobits per second, a popular bitrate for audio alone back in the 00s).

So, I thought let's test both codecs at 108kbps for 320x180 resolution at 30fps and then encode audio at 20kbps. That would give us nice 128kbps.

Alas, my plans were spoiled by the fact that an open source xHE-AAC encoder, exhale, has the lowest bitrate of 32kbps (I've not found anything lower for stereo). OK, the target bitrate will be then 140kbps which is still extremely low.

The source video is this one: Katy Perry - Roar (https://www.youtube.com/watch?v=CevxZvSJLk8) - it contains a ton of motion, fine details, everything to make the codec's life miserable.

You can check the results here (https://mega.nz/folder/apdm0LLa#mPapGbaCxMaFtl4Shdu-Lg). All the encoding settings and codec versions are provided.

You'll need a player that is based on ffmpeg 7.1 or something proprietary that supports VVC and xHE-AAC.

https://i.ibb.co/Lhx18Cg/comparison2.webp

Conclusions:


VVC beats AV1 by quite a lot.
xHE-AAC sounds a ton better than Opus at this bitrate.


108kbps is not feasible for either codec for this resolution but the results are certainly watchable, IOW you can make your videos take as much space as audios.

[GeoffreyA]

Good comparison. The VVC encode is noticeably better, concealing artefacts such as blocking and ringing more successfully, and looking sharper and more detailed on the whole. As for the audio, quite impressive showing by xHE-AAC; it sounds quite all right and smooth, with minimal artefacts reminiscent of MP3. All in all, not very different from early-encoded MP3s below 128 kbps; I would say better. Opus falls flat here, carrying its characteristic, low-bitrate distortion: metallic, synthetic, and difficult to describe, sounding as if the audio had passed through crumpled paper.

[birdie]

Sadly both of these video codecs suck in terms of retaining fine details - it looks like all/most of the new stuff in them was added to tackle very high resolutions (4K and higher).

When it comes to visually transparent encoding (i.e. no visible detail loss) x264 still reigns supreme.

I've now encoded this clip using vvenc --preset slow --bitrate 1172kbps --maxrate 2344kbps --passes 2 which is scarily close to x264's crf=10 tune=film at 1757kbps (and no one encodes at crf=10 because it's just too much) and vvenc still destroys fine details:

https://imgsli.com/MzE1NjAy/2/1

Look very closely at the face and its texture. x264 is very close to the original, vvcenc blurs out everything.

There are options (https://forum.doom9.org/showpost.php?p=2003160&postcount=1031) to disable SAO and ALF in vvenc, but it's said that by doing so bitrate will blow up.

[GeoffreyA]

I agree. Post-H.264 codecs tended to remove detail, and with AV1 and VVC, this trend was taken further. But they provide what the public regards as good quality: smooth, block-free, grain-free picture. I think we've got to give up the idea that we can easily achieve transparency with AV1 and VVC, and instead consider them in terms of their use case: excellent quality at lower bitrates.

It is regrettable, though, because there are lots of gains to be had over H.264, with all their complex, wide-searching tree algorithms and structures; but along with this, the filtering elements were mixed in.

Likely, the next generation will go further afield with neural networks, synthesising material on decode. The recent additions to Opus are already doing something like this for the speech regime when packets are lost.

[Sagittaire]

I agree. Post-H.264 codecs tended to remove detail, and with AV1 and VVC, this trend was taken further. But they provide what the public regards as good quality: smooth, block-free, grain-free picture. I think we've got to give up the idea that we can easily achieve transparency with AV1 and VVC, and instead consider them in terms of their use case: excellent quality at lower bitrates.

It is regrettable, though, because there are lots of gains to be had over H.264, with all their complex, wide-searching tree algorithms and structures; but along with this, the filtering elements were mixed in.

Likely, the next generation will go further afield with neural networks, synthesising material on decode. The recent additions to Opus are already doing something like this for the speech regime when packets are lost.

Well AV1 produce by far better quality than x264. And if you want grain, FGM work very well with SVT-AV1 and produce by far better noise reproduction at low or medium bitrate than x264.

And SAO or/and other inloop deblocking are not a problem for low quantizer simply bcause, by definition, these tools are adaptatives. At really low quantizer these tools are virtualy desactived.

If you want comparison for 1080p HDR at 2Mbps for x264, x265, AV1 and VCC, try my benchmark. And x264 can't fight with x265, AV1 or VCC.

[birdie]

If you want comparison for 1080p HDR at 2Mbps for x264, x265, AV1 and VCC, try my benchmark. And x264 can't fight with x265, AV1 or VCC.

2Mbps bitrate doesn't look nearly enough for visually transparent encoding for 1080p 30fps HDR content at which point your argument becomes moot.

Visually lossless for such content could probably require at the very least 15 to 20 Mbps for x264.

It's at the least 30Mbps average bitrate for Bluray disks though I'm not sure they use x264 and not some proprietary encoder.

[BlueSwordM]

Hey birdie, I'm curious to know why you tested with bitrate mode instead of CRF mode with aomenc.

I'd also be curious to know if you've tried the latest aomenc-av1 fork that is aom-av1-psy101, or the latest svt-av1-psy.

I'll test it out myself to see what I can truly get from it.

[Leo 69]

Well AV1 produce by far better quality than x264

I apologize, but this is not true. Better efficiency? No doubt. But better quality? Hell no, AV1 smoothes out just about all microdetails. That's been known for years and is still true to this day.

[Z2697]

OK but x265 (tuned, like disable SAO) is "better quality" than x264 actually. I put quotes on "better quality" because that not sound very scientific.
I think you mean low visible distortion in high bitrate, which is clearly a big issue or disappointment.
Dsiappoint because I do like the low bitrate quality and all, but I can't, I have to have a higher one to gain the peacefulness of my mind.

x265 is quite good at high bitrate, and with a bonus of better deblocking, whether it's the algorithm itself is improved, or the fact that blocks can be larger, so there're less block boundaries.
So I think the "older codec is better" is not true. That's depends on the "design choice" of the encoder.
Why don't you use H.261 otherwise?

AV1 encoders I used, libaom and svt-av1, still produces noticeable blurs at high bitrate to this day (I'm using presets and tune 0 for svt only. I haven't put svt-av1-psy to the same kind of test).
The metrics are high, higher than x264/5, (sadly) even VMAF, but at the end of day it's your eyes that watch the video.
Compare the frames I can notice the distortion.

Watch the video, you might argue, who's gonna notice the difference in all of that motion?
Well I, as who encodes the video, gonna know the difference. Maybe not able to notice it, but I know it's there. And whenever I see a high bitrate AV1 encode in the wild, I'll assume it's there.
Besides, what's the point of wasting bitrate on an encoder that's bad at preserving details?

[Z2697]

Please do a better job at controling the final bitrate next time?
Opus encoding with matching file size produces slightly more annoying artifacts, that's all, not ton worse.
Oh, compare after matching VVC with AV1? I'm not gonna do that. Too time consuming. Besides, that's 3.7% difference compared to 18% difference of audios.
https://files.catbox.moe/t5qcap.png

[GeoffreyA]

Well AV1 produce by far better quality than x264. And if you want grain, FGM work very well with SVT-AV1 and produce by far better noise reproduction at low or medium bitrate than x264.

And SAO or/and other inloop deblocking are not a problem for low quantizer simply bcause, by definition, these tools are adaptatives. At really low quantizer these tools are virtualy desactived.

If you want comparison for 1080p HDR at 2Mbps for x264, x265, AV1 and VCC, try my benchmark. And x264 can't fight with x265, AV1 or VCC.

Agreed that SVT-AV1, especially Gianni Rosato's psy fork, handles high-frequency detail well, perhaps matching x264's calibre in this regard. Unfortunately, aom has set the public perception of what AV1 is and it's difficult to change that.

I don't think the issue is SAO and in-loop deblocking but rather temporal filtering in both AV1 and VVC, closely tied to their working. Certainly, TF can be turned off, and SVT-AV1-PSY has added a range of parameters to tune it.

If we needed to encode a clip at visual transparency straight away, the safest way would be either x264 or x265 with some tuning (in effect, emulating x264). With aom and vvenc, I have found it more challenging to reach visual transparency; the bent of their codecs is towards a different use case; but SVT-AV1 can do it. However, given enough bitrate, any production codec ought to reach transparency; the question is, at what bitrate, and how does that compare to the legacy x264/5?

[Z2697]

Sadly both of these video codecs suck in terms of retaining fine details - it looks like all/most of the new stuff in them was added to tackle very high resolutions (4K and higher).

When it comes to visually transparent encoding (i.e. no visible detail loss) x264 still reigns supreme.

I've now encoded this clip using vvenc --preset slow --bitrate 1172kbps --maxrate 2344kbps --passes 2 which is scarily close to x264's crf=10 tune=film at 1757kbps (and no one encodes at crf=10 because it's just too much) and vvenc still destroys fine details:

https://imgsli.com/MzE1NjAy/2/1

Look very closely at the face and its texture. x264 is very close to the original, vvcenc blurs out everything.

There are options (https://forum.doom9.org/showpost.php?p=2003160&postcount=1031) to disable SAO and ALF in vvenc, but it's said that by doing so bitrate will blow up.

If you want to convince people, don't let the bitrate be so different

[birdie]

If you want to convince people, don't let the bitrate be so different

H.265 promised a 50% better compression ratio than H.264, H.266 now promises the same with respect to H.265.

In theory, this would mean that H.266 should be as good as H.264 at only 25% of the latter's bitrate, but in reality it cannot beat H.264 even at 67% of the latter's bitrate when it comes to visually lossless encoding.

[Z2697]

So you are giving up any basic control of variable?

[Leo 69]

Agreed that SVT-AV1, especially Gianni Rosato's psy fork, handles high-frequency detail well, perhaps matching x264's calibre in this regard. Unfortunately, aom has set the public perception of what AV1 is and it's difficult to change that.

I don't think the issue is SAO and in-loop deblocking but rather temporal filtering in both AV1 and VVC, closely tied to their working. Certainly, TF can be turned off, and SVT-AV1-PSY has added a range of parameters to tune it.

If we needed to encode a clip at visual transparency straight away, the safest way would be either x264 or x265 with some tuning (in effect, emulating x264). With aom and vvenc, I have found it more challenging to reach visual transparency; the bent of their codecs is towards a different use case; but SVT-AV1 can do it. However, given enough bitrate, any production codec ought to reach transparency; the question is, at what bitrate, and how does that compare to the legacy x264/5?

No, that psy fork doesn't match the x264 quality. In fact, it's not even close to the ability of x264 to retain microdetails, no matter how you tune it. Even rav1e encoder provides a better picture than the SVT-AV1-PSY (at the expense of slower encoding speeds). The very essence of any SVT encoder is to be FAST, at the expense of output quality.

[GeoffreyA]

No, that psy fork doesn't match the x264 quality. In fact, it's not even close to the ability of x264 to retain microdetails, no matter how you tune it. Even rav1e encoder provides a better picture than the SVT-AV1-PSY (at the expense of longer encoding speeds). The very essence of any SVT encoder is to be FAST, at the expense of output quality.

Fair enough. Last time I checked, using "Lost Highway," either the fork or mainline preserved the abundant grain well, without FGS. Of course, bitrate shoots up considerably. In any case, I've given up the idea of encoding live action with AV1. It's better for anime. I think what this thread needs is a multi-encoder/codec contest.

[birdie]

So you are giving up any basic control of variable?

I'm not sure what you're getting at.

Can you just say what you think without being too cryptic?

[Z2697]

Please do a better job at controling the final bitrate next time?
Opus encoding with matching file size produces slightly more annoying artifacts, that's all, not ton worse.
Oh, compare after matching VVC with AV1? I'm not gonna do that. Too time consuming. Besides, that's 3.7% difference compared to 18% difference of audios.
https://files.catbox.moe/t5qcap.png

This and that.

Was it really cryptic?

Gave xHE-AAC 18% more bitrate and call it ton better than Opus. Does this comparison has any value?

Compare vvenc 1172kps with x264 1757kbps, well they do claim 50% "generational improvement" but this is still not conclusive.

[birdie]

This and that.

Was it really cryptic?

Gave xHE-AAC 18% more bitrate and call it ton better than Opus. Does this comparison has any value?

Compare vvenc 1172kps with x264 1757kbps, well they do claim 50% "generational improvement" but this is still not conclusive.

Check the "New" folder.

Made the opus audio file slightly larger than the xHE-AAC encode. Hope you're happy. The latter still sounds better.

[Z2697]

Check the "New" folder.

Made the opus audio file slightly larger than the xHE-AAC encode. Hope you're happy. The latter still sounds better.

I have said that. The point isn't to defense Opus or anything, but to improve methodology.

[birdie]

I have said that. The point isn't to defense Opus or anything, but to improve methodology.

You could have been more transparent from the get go and thank you for pointing out the mistakes! I didn't intend to make any, I just didn't realize both exhale and opus don't stick to the specified bitrate well enough.

[a.ok.in]

Heh I found the source of the idea of using that video xD : https://www.xataka.com/streaming/vp10-el-codec-con-el-que-google-quiere-que-los-videos-4k-no-se-coman-tu-tarifa-de-datos

Now, actually Exhale is unable to do 32 kbps. Preset A is CVBR at 40kbps.
VVC and AV1... yeah they can lose detail as any modern codec, but AVC will not be better at such low bitrate. However, I consider AVC enough for low resolution :D. Using less bitrate isn't reasonable at this point, and decoding cost is higher (not to mention encoding). At least AV1 is decent for higher resolution, and has already good support. VVC... who actually cares about it? (And who remembers MPEG-5 EVC and LC-EVC?)

At the end, we slowly improve quality for the same size, but people insists on reducing more than necessary and we get worse things.

[Sagittaire]

AV1 encoders I used, libaom and svt-av1, still produces noticeable blurs at high bitrate to this day (I'm using presets and tune 0 for svt only. I haven't put svt-av1-psy to the same kind of test).
The metrics are high, higher than x264/5, (sadly) even VMAF, but at the end of day it's your eyes that watch the video.
Compare the frames I can notice the distortion.


"My eyes don't like" is really not scientific approch too. In fact, to affirm that, the only way is make double blind test with a large sample of observers.

If metric score indicate really small distortion (PSNR > 50 dB or SSIM, VMAF > 0.99), We are in an almost lossless situation, and the eyes are unable to really see the difference between source and encoding.

And ALL moderns codecs (VP9, H264, H265, H266, AV1) will produce quasi-lossless for 1080p at 40 Mbps or for 2160p at 80 Mbps. Even old MPEG4 ASP will make that very well. Perhaps even modern MPEG2 implementation.

[Z2697]

"My eyes don't like" is really not scientific approch too. In fact, to affirm that, the only way is make double blind test with a large sample of observers.

If metric score indicate really small distortion (PSNR > 50 dB or SSIM, VMAF > 0.99), We are in an almost lossless situation, and the eyes are unable to really see the difference between source and encoding.

And ALL moderns codecs (VP9, H264, H265, H266, AV1) will produce quasi-lossless for 1080p at 40 Mbps or for 2160p at 80 Mbps. Even old MPEG4 ASP will make that very well. Perhaps even modern MPEG2 implementation.

A few people in this thread saying similar things surely not enough for a large sample, but we can't help with that.

Metrics can relatively easily be "fooled". You can apply mild gaussian blur to entire image and still get SSIM > 0.99 or PSNR > 50dB, VMAF is margianlly better at this but still gives 91+ score.

I'd think the term "codec" refers to the actual specifications, while "encoder" refers to the implementation of that specification.
If you can freely use any technology / encoding tool in a codec, using most optimal quantization algorithm, of course you can do "quasi-lossless with any codec" as you said, you can even disable all the advanced features and let them mimic old codec (I assume).
But does the encoder let you do that?

[GeoffreyA]

"My eyes don't like" is really not scientific approch too. In fact, to affirm that, the only way is make double blind test with a large sample of observers.

If metric score indicate really small distortion (PSNR > 50 dB or SSIM, VMAF > 0.99), We are in an almost lossless situation, and the eyes are unable to really see the difference between source and encoding.

And ALL moderns codecs (VP9, H264, H265, H266, AV1) will produce quasi-lossless for 1080p at 40 Mbps or for 2160p at 80 Mbps. Even old MPEG4 ASP will make that very well. Perhaps even modern MPEG2 implementation.

Double-blind testing is the proper way. These metrics are more of a guide because what they say doesn't always square with what the eye sees.

[a.ok.in]

Double-blind testing is the proper way. These metrics are more of a guide because what they say doesn't always square with what the eye sees.

Yeah, but video testing is harder than audio.
An example of the problem with metrics in audio is ADC, an interesting project but quite useless. Some metrics that the author used claim that his codec is good, but it is actually bad compared to Opus or MP3. Even QOA is better, as it is simple and we have source code of it.

[FranceBB]

And ALL moderns codecs (VP9, H264, H265, H266, AV1) will produce quasi-lossless for 1080p at 40 Mbps. Even old MPEG4 ASP will make that very well. Perhaps even modern MPEG2 implementation.

Oh no no no, not MPEG-2, definitely not MPEG-2.
I have to produce 50 Mbit/s Long GOP M=3 N=12 yv16 8bit planar clips at 25fps on a daily basis and let me tell you, any MPEG-2 encoder (x262, lavc, HCEnc) will struggle at FULL HD whenever you have artificial film grain or true camera noise and any kind of dark setting. Even as recently as this June with the second season of House of the Dragon it's been a shit show. I remember a scene in which there was a guy holding a torch: the scene was dark, you had very low luma with a spike in the proximity of the torch which was illuminating the surrounding area and of course you had plenty of grain. Not only the grain was completely destroyed but the amount of banding you had in the background was obscene. Obviously the source was a UHD SDR BT709 4:4:4 12bit Apple ProRes from HBO at a whopping 1.4 Gbit/s and it was perfect, so was the downscale to FULL HD via SinPowerResize(), the chroma downscale to 4:2:2 via ConverttoYUV422() and the Floyd Steinberg dithering to 8bit via ConvertBits(), but as soon as you encoded the Avisynth output in MPEG-2, boom, disaster. At the end, I had to settle on 85 Mbit/s to achieve something decent and luckily that's the maximum that Omneon hardware playback ports in playout can read (i.e XDCAM-85), so we have basically overcome the issue of XDCAM-50 by using once again a version with more bitrate. All the very important movies and tv series are manually encoded in XDCAM-85 instead of the normal XDCAM-50 for FULL HD.

Anyway this is a very convoluted way of saying: "no, MPEG-2 encoders cannot produce something decent at 40 Mbit/s for FULL HD, they need 85 Mbit/s".

[kurkosdr]

Oh no no no, not MPEG-2, definitely not MPEG-2.
I have to produce 50 Mbit/s Long GOP M=3 N=12 yv16 8bit planar clips at 25fps on a daily basis and let me tell you, any MPEG-2 encoder (x262, lavc, HCEnc) will struggle at FULL HD whenever you have artificial film grain or true camera noise and any kind of dark setting
[...]
Anyway this is a very convoluted way of saying: "no, MPEG-2 encoders cannot produce something decent at 40 Mbit/s for FULL HD, they need 85 Mbit/s".
Huh? Then how did ATSC 1.0 manage to do FullHD with MPEG2? Also, some DVB-T broadcasters did FullHD with MPEG2 in the past. IMO, FullHD encoded with MPEG-2 should be fine at 20-22Mbps (which is around what ATSC 1.0 supports and around what DVB-T supports at reasonable FEC values - for example 64QAM, FEC 2/3).

Also, out of sheer curiosity: Why do you need to encode FullHD with MPEG-2 in 2024?

[GeoffreyA]

Yesterday, I made a comparison of a couple of our star encoders, but when I tried to post the comment here, it failed several times, saying HTTPS links are forbidden, etc. It was WeTransfer.

[GeoffreyA]

Yeah, but video testing is harder than audio.
An example of the problem with metrics in audio is ADC, an interesting project but quite useless. Some metrics that the author used claim that his codec is good, but it is actually bad compared to Opus or MP3. Even QOA is better, as it is simple and we have source code of it.

Interesting. So a sort of VMAF for audio? I agree that testing video is far more challenging, and think that's simply a reflection of nature, our eyes and visual system being quite advanced and our hearing somewhat rudimentary. Imagine if some more advanced creature were to hear our MP3s :)

[Z2697]

Yesterday, I made a comparison of a couple of our star encoders, but when I tried to post the comment here, it failed several times, saying HTTPS links are forbidden, etc. It was WeTransfer.

That's weird, my register date is after yours and I can post links (so it's not some new user limit I suppose)

Oh, and the guy in #22 literally posted a https link in his first ever post

[FranceBB]

Yesterday, I made a comparison of a couple of our star encoders, but when I tried to post the comment here, it failed several times, saying HTTPS links are forbidden, etc. It was WeTransfer.

Please let Swede know here: https://forum.doom9.org/showthread.php?p=2009529
I've been able to post wetransfer links for a while but they now seem to be stopped by the anti spam filter he has just introduced the other day.

Huh? Then how did ATSC 1.0 manage to do FullHD with MPEG2?

They did so with lots of compromises.


FullHD encoded with MPEG-2 should be fine at 20-22Mbps


Fine is a big word. Acceptable? Sure, but when I saw what it has done to that poor file master I cried.
I mean, sure, this is a particularly bad and difficult scene and the source, but still...

Avisynth 1920x1080 25fps yv16 8bit planar BT709 https://i.imgur.com/MFC0W7Z.png
MPEG-2 50 Mbit/s M=3 N=12 Closed GOP https://i.imgur.com/OJEQskI.png

I had to get to 85 Mbit/s to preserve all the grain without introducing banding.


Also, out of sheer curiosity: Why do you need to encode FullHD with MPEG-2 in 2024?

Well, back when the migration from SD to HD and later FULL HD occurred, the world was migrating away from MPEG-2. After the not-quite-successful xvid, people were not very prone in migrating to a new codec and back then H.264 AVC was the new kid in town. All very exciting, all very risky. New standards were finalized, the likes of Panasonic's AVC Intra classes and Sony's XAVC Intra classes, along with their Long GOP counterparts. Given that many were skeptical due to the flop that MPEG-4 Part2 made (i.e xvid) and not everyone was willing to take the gamble and go for MPEG-4 Part 10 (i.e H.264 AVC), new MPEG-2 standards were finalized as MPEG-2 itself was deemed to be safe, well known and advanced enough to allow its use on higher resolutions. Sony's XDCAM was born. From there, the rest is history: some companies took the gamble and moved to H.264 while some other decided to stay on MPEG-2. This was long before my days, but we were one such company that decided to stick with MPEG-2 as the people who came before me considered it to be safe. Fast forward to 2024 and that's still the standard for plenty of companies when it comes to FULL HD TX Ready files (i.e conformed mezzanine files that are sent to hardware playback ports to be played back via SDI and then re-encoded live via an hardware encoder before the signal is multiplexed, beamed to Hotbird and it comes back down to the set top boxes). Those kind of things are like "one in a generation" things: companies choose a standard and keep it forever for that particular resolution. By the way, history tends to repeat itself, in fact H.264 standards are now widely widespread for UHD (once again, Sony's XAVC Intra classes and Panasonic's AVC Ultra) instead of the H.265 HEVC ones (Sony's HS).

[GeoffreyA]

That's weird, my register date is after yours and I can post links (so it's not some new user limit I suppose)

Oh, and the guy in #22 literally posted a https link in his first ever post

Yes, it's strange. Seemingly, there's a new filter, as FranceBB points out. I'll try again today. Failing that, perhaps Mega, which I haven't got an account on.

[GeoffreyA]

I made a quick set of encodings at 5 Mbps to see how various encoders stack up against each other. I stuck to basic settings and tunings. For AV1, aom-psy101 and SVT-AV1-PSY were used, along with a mainline encode. For VVC, there seems to be a problem with the two-pass mode: it is either ill tuned or interacting poorly with temporal filtering. The two-pass x264 encode exhibits some artefacts in the beginning that are eliminated in CRF mode. I think Xvid's two-pass in FFmpeg is broken, so I used the quality mode, which undershot the 5 Mbps target.

https://we.tl/t-qAxc1tVT1P


set br=5000k

ffmpeg -i ref.mp4 -c:v mpeg2video -b:v %br% -pass 1 -f null -
ffmpeg -i ref.mp4 -c:v mpeg2video -b:v %br% -pass 2 mpeg2.mp4

ffmpeg -i ref.mp4 -c:v libx264 -b:v %br% -preset veryslow -tune film -pass 1 -f null -
ffmpeg -i ref.mp4 -c:v libx264 -b:v %br% -preset veryslow -tune film -pass 2 x264.mp4

ffmpeg -i ref.mp4 -c:v libx265 -b:v %br% -preset slower -x265-params pass=1:deblock=-1,-1 -f null -
ffmpeg -i ref.mp4 -c:v libx265 -b:v %br% -preset slower -x265-params pass=2:deblock=-1,-1 x265.mp4

ffmpeg -i ref.mp4 -c:v libx265 -b:v %br% -preset slower -x265-params pass=1:deblock=-1,-1:no-sao=1 -f null -
ffmpeg -i ref.mp4 -c:v libx265 -b:v %br% -preset slower -x265-params pass=2:deblock=-1,-1:no-sao=1 x265-no-sao.mp4

ffmpeg -i ref.mp4 -c:v libvvenc -b:v %br% -preset medium -pass 1 -f null -
ffmpeg -i ref.mp4 -c:v libvvenc -b:v %br% -preset medium -pass 2 vvenc.mp4

ffmpeg -i ref.mp4 -c:v libvvenc -b:v %br% -preset medium -vvenc-params SAO=0 -pass 1 -f null -
ffmpeg -i ref.mp4 -c:v libvvenc -b:v %br% -preset medium -vvenc-params SAO=0 -pass 2 vvenc-no-sao.mp4

ffmpeg -i ref.mp4 -c:v libaom-av1 -b:v %br% -cpu-used 4 -arnr-strength 1 -pass 1 -f null -
ffmpeg -i ref.mp4 -c:v libaom-av1 -b:v %br% -cpu-used 4 -arnr-strength 1 -pass 2 aom.mp4

ffmpeg -i ref.mp4 -c:v libaom-av1 -b:v %br% -cpu-used 4 -pass 1 -f null -
ffmpeg -i ref.mp4 -c:v libaom-av1 -b:v %br% -cpu-used 4 -pass 2 aom-psy101.mp4

ffmpeg -i ref.mp4 -c:v libsvtav1 -b:v %br% -preset 4 -svtav1-params tune=0 -pass 1 -f null -
ffmpeg -i ref.mp4 -c:v libsvtav1 -b:v %br% -preset 4 -svtav1-params tune=0 -pass 2 svtav1-psy.mp4

ffmpeg -i ref.mp4 -c:v libvpx-vp9 -quality good -cpu-used 2 -b:v %br% -pass 1 -f null -
ffmpeg -i ref.mp4 -c:v libvpx-vp9 -quality good -cpu-used 2 -b:v %br% -pass 2 vp9.mp4

ffmpeg -i ref.mp4 -c:v libxvid -q:v 6 xvid.mp4

[ksec]

Yesterday, I made a comparison of a couple of our star encoders, but when I tried to post the comment here, it failed several times, saying HTTPS links are forbidden, etc. It was WeTransfer.

This forum still uses vBulletin® Version 3.8.11. Which IIRC was released in 2016 and EOL in 2019. We are coming close to 2025.

I dont mind sending some money to have this whole forum software upgraded or transfer everything to Open Source solution.

[GeoffreyA]

This forum still uses vBulletin® Version 3.8.11. Which IIRC was released in 2016 and EOL in 2019. We are coming close to 2025.

I dont mind sending some money to have this whole forum software upgraded or transfer everything to Open Source solution.

While it is dated and perhaps could use a slight update, I think there is a certain charm to the classical, low-fidelity approach to the forum. I remember on Anandtech, there used to be a recurring complaint about the article comment system, which one user described as "straight out of the '90s." However, it was different in today's age and had a classic simplicity to it. Even the much-lamented lack of an edit button caused a poster to think before pressing.

[Sagittaire]

Oh no no no, not MPEG-2, definitely not MPEG-2.
I have to produce 50 Mbit/s Long GOP M=3 N=12 yv16 8bit planar clips at 25fps on a daily basis and let me tell you, any MPEG-2 encoder (x262, lavc, HCEnc) will struggle at FULL HD whenever you have artificial film grain or true camera noise and any kind of dark setting. Even as recently as this June with the second season of House of the Dragon it's been a shit show. I remember a scene in which there was a guy holding a torch: the scene was dark, you had very low luma with a spike in the proximity of the torch which was illuminating the surrounding area and of course you had plenty of grain. Not only the grain was completely destroyed but the amount of banding you had in the background was obscene. Obviously the source was a UHD SDR BT709 4:4:4 12bit Apple ProRes from HBO at a whopping 1.4 Gbit/s and it was perfect, so was the downscale to FULL HD via SinPowerResize(), the chroma downscale to 4:2:2 via ConverttoYUV422() and the Floyd Steinberg dithering to 8bit via ConvertBits(), but as soon as you encoded the Avisynth output in MPEG-2, boom, disaster. At the end, I had to settle on 85 Mbit/s to achieve something decent and luckily that's the maximum that Omneon hardware playback ports in playout can read (i.e XDCAM-85), so we have basically overcome the issue of XDCAM-50 by using once again a version with more bitrate. All the very important movies and tv series are manually encoded in XDCAM-85 instead of the normal XDCAM-50 for FULL HD.

Anyway this is a very convoluted way of saying: "no, MPEG-2 encoders cannot produce something decent at 40 Mbit/s for FULL HD, they need 85 Mbit/s".


Well first BD movie use MPEG2 at 40 Mbps for 1080p with really good result.
https://forum.blu-ray.com/showthread.php?t=159640

And x262, lavc or HCEnc are really not good MPEG2 implementation for make that. CCE was the best for make that. CCE was historicaly the encoder use for all DVD production at 8 Mbps for 480/576p with really good result. If you have good result at 8 Mbps for 576p, you have at least same quality by pixel (and certainely really higher quality) for 40 Mbps at 1080p.

[modus-ms325c]

And x262, lavc or HCEnc are really not good MPEG2 implementation for make that. CCE was the best for make that. CCE was historicaly the encoder use for all DVD production at 8 Mbps for 480/576p with really good result. If you have good result at 8 Mbps for 576p, you have at least same quality by pixel (and certainely really higher quality) for 40 Mbps at 1080p.
but nobody uses CCE because CCE was killed off circa 2011, plus its successor software (Sirius Pixels SDe) is *insanely* inaccessible.

[MoSal]

Alas, my plans were spoiled by the fact that an open source xHE-AAC encoder, exhale, has the lowest bitrate of 32kbps (I've not found anything lower for stereo).


If we are byte pinching, one can resample to 32KHz or 24KHz to save a few quid, I mean a few bytes.

Encoding from a lossless version (not YouTube):


42.8457kbps 225.3200(3:45) ./roar.m4a
32.7401kbps 225.3200(3:45) ./roar24k.m4a
39.3174kbps 225.3200(3:45) ./roar32k.m4a


I don't have the time to look now, but the encoder can probably be trivially modified to output a bitrate in between the 24KHz and 32KHz bitrates above. I did such a modification at the other end (highest settings) a few months ago (https://github.com/MoSal/exhale/commit/433082bcea7e72fab354a350817d732b70ba29d1) (EDIT: I meant selectively encoding bands >12KHz and <16KHz. I'm assuming this is possible. But I didn't check) (EDIT2: Okay, roar32K.m4a doesn't have bands above 12KHz encoded already, so it would be between 9KHz and 12KHz).

There is also a Fraunhofer encoder that is supposedly better at low bit-rates. But I don't think it's available in the open-source SDK (yet), and I don't care enough to check if it's usable via the usual DLL wrappers.

Also, the codec couplings are not a hard requirement anymore. One can do AV1+xHE-AAC, or H266+Opus.

I'm also wondering if going that low with the video resolution was really necessary. I never indulged in byte pinching myself, but my guess would have been that 360p may fare better.

And finally, different AQ modes/settings may make a big difference here. I'm interested in knowing how AOM in particular would do in that regard (not enough to test it myself), but it would probably be equally relevant in the VVC encodes too.

[GeoffreyA]

I'm also wondering if going that low with the video resolution was really necessary. I never indulged in byte pinching myself, but my guess would have been that 360p may fare better.

And finally, different AQ modes/settings may make a big difference here. I'm interested in knowing how AOM in particular would do in that regard (not enough to test it myself), but it would probably be equally relevant in the VVC encodes too.

I think one can go substantially higher on the resolution and still get watchable results. As for AQ, it seems a confusing mess on AOM, and if I remember correctly, some modes are broken, according to BlueSwordM's guide. After some time, it gets tiring having to tune and tune an encoder's settings to get serviceable results, and that's what one's life becomes with AV1. Or, the cargo-culting command lines.

[Z2697]

SVT-AV1 have an "AQ" setting which in reality enables "CRF", and they later implemented (merged from PSY fork) "variance-boost" which is actually similar to aq-mode 1 in x264 if I read the docs correctly. Confusing as well.

[GeoffreyA]

I was under the impression that variance boost was similar to aq-mode 3, distributing more bits to darker patches in the frame.

[benwaggoner]

There is also a Fraunhofer encoder that is supposedly better at low bit-rates. But I don't think it's available in the open-source SDK (yet), and I don't care enough to check if it's usable via the usual DLL wrappers.
Yeah, it can go down to 8 Kbps, and sounds surprisingly good at 20 Kbps.

I'm also wondering if going that low with the video resolution was really necessary. I never indulged in byte pinching myself, but my guess would have been that 360p may fare better.
Yeah, the more advanced the codec, the more it just gets softer at high QP, and so the less need there is to use a lower resolution to maintain lower QP. I've been surprised how high a resolution/low bits-per-pixel we can go today. Back in the MPEG-2/VC-1 days, one QP got too high on a P-frame, the rest of the GOP was ruined, and so resolution management became a big deal. The original Xbox 360 video service had really sophisticated adaptive bitrate system where each GOP/fragment was encoded at an optimal horizontal and vertical width (so a pan would got more horizontal compression). That allowed the QPs to stay low enough.

A clever idea, but not something we really have to sweat so much anymore.

And finally, different AQ modes/settings may make a big difference here. I'm interested in knowing how AOM in particular would do in that regard (not enough to test it myself), but it would probably be equally relevant in the VVC encodes too.
Yeah. Although it gets interesting at very low bitrates, as the signaling overhead for different block types and QP can wind up using a lot of bits. The inefficient RLE mask that VC-1 used for delta QP wound up being a serious deficit compared to H.264 at low bitrates. With 8100 macroblocks in a 1920x1080p24 frame, 4 bits of signaling per macroblock could top out at 778 Kbps worst case. Some optimization had to be done to reduce variability so the same QP would be used sequentially more often so the RLE would help.

[Qljo]

Just for fun I decided to compare VVC with AV1 at extremely low bitrates given that Russia has throttled YouTube to impossible to use 128 kbps (that's kilobits per second, a popular bitrate for audio alone back in the 00s).

So, I thought let's test both codecs at 108kbps for 320x180 resolution at 30fps and then encode audio at 20kbps. That would give us nice 128kbps.

Alas, my plans were spoiled by the fact that an open source xHE-AAC encoder, exhale, has the lowest bitrate of 32kbps (I've not found anything lower for stereo). OK, the target bitrate will be then 140kbps which is still extremely low.

The source video is this one: Katy Perry - Roar (https://www.youtube.com/watch?v=CevxZvSJLk8) - it contains a ton of motion, fine details, everything to make the codec's life miserable.

You can check the results here (https://mega.nz/folder/apdm0LLa#mPapGbaCxMaFtl4Shdu-Lg). All the encoding settings and codec versions are provided.

You'll need a player that is based on ffmpeg 7.1 or something proprietary that supports VVC and xHE-AAC.

https://i.ibb.co/Lhx18Cg/comparison2.webp

Conclusions:


VVC beats AV1 by quite a lot.
xHE-AAC sounds a ton better than Opus at this bitrate.


108kbps is not feasible for either codec for this resolution but the results are certainly watchable, IOW you can make your videos take as much space as audios.

Please can anyone here tell me what I must do to include the VVC Codec in my VLC or send a link to any player that will playback that VVC sample file? I did not manage to do it! Thanks a lot in advance.

[GeoffreyA]

Please can anyone here tell me what I must do to include the VVC Codec in my VLC or send a link to any player that will playback that VVC sample file? I did not manage to do it! Thanks a lot in advance.

Try MPC-HC (https://github.com/clsid2/mpc-hc/releases), which plays VVC.

[mooms]

MPC-HC (the one bundled in K-Lite Codec Pack (https://codecguide.com/)) can play VVC, but it's very choppy, at least the file posted in the FP.

[a.ok.in]

MPC-HC (the one bundled in K-Lite Codec Pack (https://codecguide.com/)) can play VVC, but it's very choppy, at least the file posted in the FP.

There's some MPC-HC build from VVCEasy that should work better as it's specifically intended for play VVC/H.266 and xHE-AAC/USAC. Last release tag of VVCEasy from just two weeks ago here (https://github.com/MartinEesmaa/VVCEasy/releases/tag/v3.0.0). It has much more things than just MPC-HC.

[nevcairiel]

MPC-HC (the one bundled in K-Lite Codec Pack (https://codecguide.com/)) can play VVC, but it's very choppy, at least the file posted in the FP.

The choppyness is from a timestamp problem. It looks like the file in the first post does not have a CTTS atom.

[VoodooFX]

xHE-AAC sounds a ton better than Opus at this bitrate.


Yes, even HE-AACv2 is much better than Opus at low bitrates.
I wouldn't use Opus for lower than ~64 kbps.

[MoSal]

I wouldn't use Opus for lower than ~64 kbps.

Wrong. Maybe lower than ~32kbps would be more convincing. Opus is still king (or joint king), even at ~48kbps.

https://listening-test.coresv.net/img2/28tsac-en2x2.png
source (https://hydrogenaudio.org/index.php/topic,127980.0.html)

Note: Results from the listening test above use NoLace when decoding Opus@20kbps, which is a new (libopus v1.5) ML decoding post-filter that helps a little at low bitrates.