Versatile Video Coding (VVC) / H.266: HEVC successor

[FranceBB]

What were people doing instead of AAC-LC?

They mentioned USAC, so I guess xHE-AAC, Netflix style, instead of a standard AAC-LC?
I don't know, though, just a wild guess, but for what it's worth I'm also a supporter of the good old AAC-LC.




Side note:
I'm an AAC-LC supporter for my personal stuff, but at work on linear we're using E-AC3 which I'm not proud of.

[modus-ms325c]

Off Topic on Doom9 but I am happy to see appreciation of AAC-LC. The Scene, people who are actually doing lots of encoding ( I want to say professional but I guess that is not the right word ) has made the right choice. It is just unfortunate most people dont get this and as AAC-LC is now fully patent free.
let me help

there are various reasons AAC-LC has fully gone under the radar in recent years, but what i think is chief among them is because we've been fed if not outright gaslit into new audio coding technologies that (no exceptions) promise "higher quality at lower bitrates" but when comes time to deliver, we just get diminishing returns instead

spectograms aren't the be-all-end-all of how sound actually sounds like when put to a lossy audio codec but insane frequency cutoffs are EVERYWHERE now and not a single soul cares about letting sound "breathe" anymore, it's now all about "sounding good" rather than "letting sound speak for itself", it's why you seem to like AAC-LC even more it seems!

[kurkosdr]

H.266 VVC has entered the evaluation phase for ATSC 3.0, which means that ATSC members will have to vote on that. It is difficult to predict exactly when the membership might vote to make it part of the standard, but the candidate standard period is typically less than a year, so just a few months. Given that DVB has already accepted it, chances are that it might get approved by the end of the year. :)
Sure, but what happens to all those existing UHD TVs sold the past 8 years that only decode HEVC UHD content?

Don't get me wrong, I want to see HEVC go away for 4K UHD broadcasts and be replaced by VVC, but unfortunately, I don't see it happening. For example, VVC is already part of the DVB toolset but it's used nowhere (there was a short trial of VVC-encoded 8K UHD by SES and that was it).

[kurkosdr]

They mentioned USAC, so I guess xHE-AAC, Netflix style, instead of a standard AAC-LC?
I don't know, though, just a wild guess, but for what it's worth I'm also a supporter of the good old AAC-LC.
I can see the utility of xHE-AAC for stuff like digital shortwave radio where most of the content is audio so there are savings to be had, but for video streaming? How much bitrate are you saving anyway to make it worth both the royalties cost and the compatibility breakage? Even video broadcasters don't use xHE-AAC, they use AAC-LC or HE-AAC (which I understand for channels with multiple audio tracks (languages), HE-AAC is backwards compatible with AAC-LC and offers some nice bitrate savings on multi-audio channels).

They mentioned USAC, so I

Side note:
I'm an AAC-LC supporter for my personal stuff, but at work on linear we're using E-AC3 which I'm not proud of.
I never understood why some countries (including France) use E-AC3 for stereo content instead of AAC-LC. The whole point of AC3 and E-AC3 is that 5.1 audio content encoded in these formats is compatible with every AVR/home cinema system ever made (note: E-AC3 receivers can transcode E-AC3 to AC3), but for stereo content? Use AAC-LC and it will exit the SPDIF hole as stereo LPCM. Broadcasters work in mysterious ways.

The only good thing about stereo E-AC3 is that it usually acts as a compatibility stream next to AC4, so it's a small annoyance that relieves us from a much bigger annoyance (AC4). But why won't they use AAC-LC for the stereo compatibility stream next to AC4? Guess I'll never know. I would guess Blu-Ray compatibility (since E-AC3 is transcodable to AC3), but they also use E-AC3 on HLG10 channels which aren't Blu-Ray-compatible as a matter of fact. As I said, broadcasters work in mysterious ways.

[kurkosdr]

The scene has started experimenting with VVC. Won't post a link but you can easily Google it up: Oppenheimer (2023) IMAX 2160p UHD HDR BluRay VVenC H.266 VVC AAC 5.1 [RAV1NE]
Do we know what AAC encoder they used?

They appear to be using "qaac" (which I guess is this one (https://github.com/nu774/qaac) but not sure) with "TVBR". What is TVBR?

[lvqcl]

True VBR
See https://github.com/nu774/qaac/wiki/Command-Line-Options

[FranceBB]

I never understood why some countries (including France) use E-AC3 for stereo content instead of AAC-LC. The whole point of AC3 and E-AC3 is that 5.1 audio content encoded in these formats is compatible with every AVR/home cinema system ever made (note: E-AC3 receivers can transcode E-AC3 to AC3), but for stereo content?

I don't know, but my wild guess is to keep things consistent and stick a -24 dialnorm value in there (i.e DRC). I don't know for sure, though, as my job ends once I've delivered the TX Ready file (i.e the one the video server plays before it gets re-encoded for distribution), then it's all in the end of the distribution guys. Funnily enough when I pass them a DolbyE 5.1 I also include a dialnorm value of -24 but when it comes to stereo it's always PCM anyway...



I can see the utility of xHE-AAC for stuff like digital shortwave radio where most of the content is audio so there are savings to be had


Well, we're currently stuck with HE-AAC 64 kbits which is honestly fine for dialogues but absolutely appalling for music. Then again, the fact that we're generally listening to music in the car with a lot of background noise makes the whole thing more forgiving but when I listen to the radio at home on my headsets the artifacts are pretty bad. And sure one could listen to the radio via internet, but the problem is that most companies (like global which handles a huge variety of radio stations) reuse the DAB+ HE-AAC live encode for the web, so...

These are just two examples:

Stream 1 HE-AAC 64 kbits Capital (Music) (http://media-the.musicradio.com/Capital?type=.flv)
Stream 2 HE-AAC 64 kbits LBC (Dialogues) (http://media-the.musicradio.com/LBCLondon?type=.flv)


Sure, but what happens to all those existing UHD TVs sold the past 8 years that only decode HEVC UHD content?


Nothing 'cause my mind was more oriented towards 8K.
I mean, DTT is a very different world, but currently on satellite we have SD channels still in MPEG-2, FULL HD channels still in H.264 and UHD channels in H.265. It's just natural to think that 8K channels will likely be H.266.

[Selur]

What is TVBR?
'AAC True VBR mode' https://github.com/nu774/qaac/wiki/Command-Line-Options
https://wiki.hydrogenaud.io/index.php?title=Apple_AAC#afconvert
There have been some discussions over at HydrogenAudio about whether vbr or tvbr are better.

[kurkosdr]

Well, we're currently stuck with HE-AAC 64 kbits which is honestly fine for dialogues but absolutely appalling for music. Then again, the fact that we're generally listening to music in the car with a lot of background noise makes the whole thing more forgiving but when I listen to the radio at home on my headsets the artifacts are pretty bad. And sure one could listen to the radio via internet, but the problem is that most companies (like global which handles a huge variety of radio stations) reuse the DAB+ HE-AAC live encode for the web, so...

These are just two examples:

Stream 1 HE-AAC 64 kbits Capital (Music) (http://media-the.musicradio.com/Capital?type=.flv)
Stream 2 HE-AAC 64 kbits LBC (Dialogues) (http://media-the.musicradio.com/LBCLondon?type=.flv)
Yes, in radio broadcasting xHE-AAC might make sense because most of your content is audio. But in video broadcasting, even if we assume xHE-AAC saves you 30kbps per audio stream (a generous estimate), and even if you have 3 languages (audio streams), is a ~0.1Mbps worth of bitrate savings worth the massive compatibility breakage? No, and that's why no video broadcaster uses it (and I hope they don't in the future, but you never know with broadcasters).

But even when it comes to radio broadcasting, it makes you wonder why HE-AAC is suddenly not enough and how many radio channels are too many. There is a compatibility cost to moving to newer formats (for example all those existing DAB+ receivers becoming useless). Digital shortwave radio doesn't have this problem because it's a completely new thing.

[benwaggoner]

Yes, in radio broadcasting xHE-AAC might make sense because most of your content is audio. But in video broadcasting, even if we assume xHE-AAC saves you 30kbps per audio stream (a generous estimate), and even if you have 3 languages (audio streams), is a ~0.1Mbps worth of bitrate savings worth the massive compatibility breakage? No, and that's why no video broadcaster uses it (and I hope they don't in the future, but you never know with broadcasters).
100 Kbps can matter if targeting mobile devices, and xHE-AAC decode is effectively universal on mobile: Android, iOS, and Fire OS have all supported xHE-AAC decode for a couple of replacement cycles now.

And with new codecs like VVC, we can push video bitrates down enough that audio becomes an increasingly large part of the total payload.

[benwaggoner]

'AAC True VBR mode' https://github.com/nu774/qaac/wiki/Command-Line-Options
https://wiki.hydrogenaud.io/index.php?title=Apple_AAC#afconvert
There have been some discussions over at HydrogenAudio about whether vbr or tvbr are better.
Ah. So "vbr" there is a CVBR (Constrained VBR) ala setting --crf with a --vbv-maxrate and --vbv-bufsize. That's going to be preferable for streaming and combined video/audio delivery, as peak bitrates worst case can be defined. We need that for video as profile/level define a maximum bitrate for compatibility which we want to stay under.

TVBR would be an uncapped VBR, ala just using --crf or --qp without any profile/level VBV limitations. Potentially slightly better sound quality, and preferable for file-based playback.

Since there's only so high a bitrate can go with a codec, in practice there's not likely to be that much a difference unless the constrained bitrate is quite constrained.

[kurkosdr]

100 Kbps can matter if targeting mobile devices, and xHE-AAC decode is effectively universal on mobile: Android, iOS, and Fire OS have all supported xHE-AAC decode for a couple of replacement cycles now.

And with new codecs like VVC, we can push video bitrates down enough that audio becomes an increasingly large part of the total payload.
As long as xHE-AAC stays away from video broadcast (DVB and ATSC), I am happy. Streamers can always encode an HE-AAC fallback for older devices and serve accordingly (I don't like the idea of throwing away good smartphones in the name of "replacement cycles"/planned obsolescence, I still use my Nexus 5 and 5X as secondary phones). Although on streaming you won't save 100kbps but 30kbps (in our example above) because you are not streaming all 3 languages (audio streams) simultaneously like you do on broadcast. So, I highly doubt the usefulness of it, but as long as they provide a fallback (as they do usually), it's not an issue.

[MoSal]

As long as xHE-AAC stays away from video broadcast (DVB and ATSC), I am happy. Streamers can always encode an HE-AAC fallback for older devices and serve accordingly (I don't like the idea of throwing away good smartphones in the name of "replacement cycles"/planned obsolescence, I still use my Nexus 5 and 5X as secondary phones). Although on streaming you won't save 100kbps but 30kbps (in our example above) because you are not streaming all 3 languages (audio streams) simultaneously like you do on broadcast. So, I highly doubt the usefulness of it, but as long as they provide a fallback (as they do usually), it's not an issue.

This whole discussion was weird, since it managed to ignore the two facts that:

1- Opus exists.
2- Audio codecs don't need hardware (accelerated) support. Platform-level support is not an absolute requirement either. Apps can add software decoding for any audio codec without a noticeable downside like too much battery drainage (assuming no unusual complexity requirements).

There is a reason why xHE-AAC is not that exciting.

---

There is a third fact that HE-AAC is shit for anyone who has any respect for their ears. But let's not get into that.

[benwaggoner]

As long as xHE-AAC stays away from video broadcast (DVB and ATSC), I am happy. Streamers can always encode an HE-AAC fallback for older devices and serve accordingly (I don't like the idea of throwing away good smartphones in the name of "replacement cycles"/planned obsolescence, I still use my Nexus 5 and 5X as secondary phones).[QUOTE]
xHE-AAC is supported on really old phones. As long as it can upgrade to Android 9 or iOS 13, the decoder is there. That's all the way back to the iPhone 6s for Apple. Android updates are up to the whim of the OEM, of course, but five years is enough to get a pretty complete ecosystem refresh for mobile. Certainly most streaming apps don't support OS versions earlier than those.

But yeah, for broadcast broadcast, introducing new codecs is fraught and generally part of a massive shift. ATSC 1.0 to 3.0, for example (which still exists more in theory than practice). DVB seems to be able to get an update in more than once every few decades ;).

[QUOTE]Although on streaming you won't save 100kbps but 30kbps (in our example above) because you are not streaming all 3 languages (audio streams) simultaneously like you do on broadcast. So, I highly doubt the usefulness of it, but as long as they provide a fallback (as they do usually), it's not an issue.
There are several big benefits of xHE-AAC for streaming

Seamless switching between all bitrates. That wasn't supported between LC and HEv1 or HEv1 and HEv2.
Single codec scalable from perceptually lossless music down to very low bitrate speech
Better speech quality in general at lower bitrates
Better compression efficiency than any legacy AAC variant at any given bitrate or perceptual quality threshold.

[birdie]

MPC-HC 2.2.0 by clsid2 now supports VVC decoding natively, hooray!

https://github.com/clsid2/mpc-hc/releases

Probably uses native FFmpeg decoding which is far from being fully/properly optimized (vvdec is 2-3 times faster) but it's still freaking amazing.

[guest]

I'm not sure if I'm in the correct thread, but I'm trying to use this VCC Encoder:-

https://github.com/Disa-Kizonda/VVC-GUI-Encoder

And after setting up the "Ready to Use Pack", and loading a file, I get this error:-


'ffmpeg_vvceasy.exe' is not recognized as an internal or external command,
operable program or batch file.
Exception in Tkinter callback
Traceback (most recent call last):
File "C:\Program Files\WindowsApps\PythonSoftwareFoundation.Python.3.9_3.9.3568.0_x64__qbz5n2kfra8p0\lib\tkinter\__init__.py", line 1892, in __call__
return self.func(*args)
File "C:\Users\Geoff\Downloads\VVC_GUI_Encoder\VVC_GUI_Encoder.py", line 10, in SelectButton
imgone=Image.open('temp.jpg')
File "C:\Users\Geoff\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.9_qbz5n2kfra8p0\LocalCache\local-packages\Python39\site-packages\PIL\Image.py", line 3277, in open
fp = builtins.open(filename, "rb")
FileNotFoundError: [Errno 2] No such file or directory: 'C:\\Windows\\System32\\temp.jpg'


'C:\\Windows\\System32\\temp.jpg' this doesn't look right, either...

double \\ ???

[LigH]

Regarding the double backslash: I am almost sure this is not the problem, just a required convention on Windows; but expecting a temporary JPEG file in Windows\system32 is an issue: No application should try to create files there. I guess the converter searches there for a file it did not find elsewhere, maybe because a verbose path to that file is missing. Searching alternatively in the system directory of Windows may be fine when looking for required DLLs, but not when looking for general data files.

Also note:
'ffmpeg_vvceasy.exe' is not recognized as an internal or external command, operable program or batch file.
Your package might be incomplete. Or it is not set up correctly with verbose paths to find the used tools.

[LigH]

Looking for "VVC encoder GUIs", I also found this project which might be interesting for some Linux users:

aviator - https://github.com/gianni-rosato/aVVCator
A Flatpak-first easy-to-use GUI for encoding with VVenC & aac.

[guest]

Looking for "VVC encoder GUIs", I also found this project which might be interesting for some Linux users:

aviator - https://github.com/gianni-rosato/aVVCator
A Flatpak-first easy-to-use GUI for encoding with VVenC & aac.

I need something pretty easy to use, don't like CLI stuff.

This one looks interesting:-

https://github.com/MartinEesmaa/VVCEasy

[birdie]

Please exercise extra caution when using random github projects or anything you download from the Internet.

In a perfect world you either run such things under a separate limited user account (given your system is 100% up to date/still supported/fully updated), or better yet in a virtual machine (virtualbox, vmware, qemu/kvm, etc), again under a limited user account.

The same applies to various PPA/COPR/AURs/whatever.

[guest]

Please exercise extra caution when using random github projects or anything you download from the Internet.

In a perfect world you either run such things under a separate limited user account (given your system is 100% up to date/still supported/fully updated), or better yet in a virtual machine (virtualbox, vmware, qemu/kvm, etc), again under a limited user account.

The same applies to various PPA/COPR/AURs/whatever.

Most of that didn't make any sense to me at all...

What do you suggest I use, that is an easy to use GUI ??

[birdie]

And now FFmpeg 7.0 as well!

"A new major release (https://ffmpeg.org/download.html#release_7.0), FFmpeg 7.0 "Dijkstra", is now available for download. The most noteworthy changes for most users are a native VVC decoder (currently experimental, until more fuzzing is done)"

MPC-HC 2.2.0 by clsid2 now supports VVC decoding natively, hooray!

https://github.com/clsid2/mpc-hc/releases

Probably uses native FFmpeg decoding which is far from being fully/properly optimized (vvdec is 2-3 times faster) but it's still freaking amazing.

[birdie]

It's weird, Qualcomm boasts about Adreno (https://www.qualcomm.com/developer/blog/2024/04/offload-tough-workloads-to-adreno-gpus--acceleration-of-the-adap) being able to decode 4K 60fps VVC video in real time in software mode on Snapdragon 8 Gen 2.

Meanwhile aside from MX Player no one seems to be interested.

[oibaf]

It's weird, Qualcomm boasts about Adreno (https://www.qualcomm.com/developer/blog/2024/04/offload-tough-workloads-to-adreno-gpus--acceleration-of-the-adap) being able to decode 4K 60fps VVC video in real time in software mode on Snapdragon 8 Gen 2.

Meanwhile aside from MX Player no one seems to be interested.

https://blog.chiariglione.org/a-future-without-mpeg/

[kurkosdr]

It's weird, Qualcomm boasts about Adreno (https://www.qualcomm.com/developer/blog/2024/04/offload-tough-workloads-to-adreno-gpus--acceleration-of-the-adap) being able to decode 4K 60fps VVC video in real time in software mode on Snapdragon 8 Gen 2.

Meanwhile aside from MX Player no one seems to be interested.
It's rather simple: Every chip or software player I've seen so far that can decode VVC can also decode AV1, but the reverse isn't always true. There are chips and software players out there that can decode AV1 but not VVC. Whatever marginal better performance VVC has over AV1, it's not worth breaking compatibility with those chips and software players. I'd even say it's not worth paying the royalties to implement a VVC decoder in smartphones, tablets, PCs, and software players. No streaming content in VVC means no reason to pay to implement a decoder.

[kurkosdr]

https://blog.chiariglione.org/a-future-without-mpeg/
So what? MPEG has no god-given right to exist, and neither do the for-profit companies that contribute the technologies (patents) behind it. As I've said elsewhere, now that MPEG doesn't have an automatic compatibility advantage (like HEVC has over VP9) and now that AV1 can do HDR10+, the companies behind MPEG have to earn their royalty dollars by competing with AV1 in the streaming space, for example by offering a performance delta over AV1 to be worth the royalty costs (including decoder royalties, encoder royalties, and content royalties). Simply put, no smartphone SoC vendor or software player vendor is obligated to support VVC. My guess is that VVC will eventually get some success in broadcasting (and as a result be supported in TVs alongside AV1), because broadcasters are obligated to use ISO or ETSI standards, but not elsewhere. Whether this is enough to keep the companies behind MPEG interested in developing new standards remains to be seen.

[ksec]

It's weird, Qualcomm boasts about Adreno (https://www.qualcomm.com/developer/blog/2024/04/offload-tough-workloads-to-adreno-gpus--acceleration-of-the-adap) being able to decode 4K 60fps VVC video in real time in software mode on Snapdragon 8 Gen 2.

Meanwhile aside from MX Player no one seems to be interested.

Because MX Player ( And Tencent ) are the only ones streaming VVC at the moment.

[benwaggoner]

https://blog.chiariglione.org/a-future-without-mpeg/
There was a good amount of talk about VVC at NAB a couple of weeks ago. More traditional video companies like broadcasters and cable are pretty much assuming that's what they'll be using down the road.

One talking point was that VVCEnc is already delivering equivalent quality to x265 at 70% the bitrate, which is an impressive delta at this point in the adoption curve given the relative maturity of the encoders.

Still, there's too much murk around the IP licensing for lots of markets. Things got somewhat simplified with Dolby integrating two of the three major patent pools, and Dolby is good at getting paid for licensed technology.

There was talk about AV2, but at least as much about how it keeps getting delayed due to not meeting its compression efficiency goals relative to VVC. I have no doubt it'll be a good codec, and a big improvement on AV2. Until we get close to a bitstream lockdown, it's a lot of speculation about where it'll land. Hopefully we'll get some useful demos for NAB 2025.

[Dann0245]

VVC film grain

https://arxiv.org/pdf/2402.00622

[LigH]

New uploads: [Windows][GCC 14.1.0][64 bit]

VTM Encoder/Decoder Version 22.0 (https://www.mediafire.com/file/w5zlpc94g0m07sb/VTM_22.0_463b869.7z/file) 463b869

Fraunhofer VVC Encoder ver. 1.11.1 (https://www.mediafire.com/file/m5pqaik0ibwokm6/vvenc_1.11.1-e4bb886.7z/file) e4bb886

Fraunhofer VVC Decoder ver. 2.3.0 (https://www.mediafire.com/file/fwvja2kb8nvs14z/vvdec_2.3.0-b3514f7.7z/file) b3514f7

[LigH]

PS: MP4Box can create an MP4 containing VVC video. But VLC with plugin does not decode the video in it.

That day (June 9, 2022) I created VLC issue 27055 (https://code.videolan.org/videolan/vlc/-/issues/27055); today a developer got assigned.

PS: Reading the history of comments in it again makes me sigh deeply.

[kurkosdr]

That day (June 9, 2022) I created VLC issue 27055 (https://code.videolan.org/videolan/vlc/-/issues/27055); today a developer got assigned.

PS: Reading the history of comments in it again makes me sigh deeply.
Generally, when it comes to VLC, you should assume a given bug is going to be fixed whenever or never. Those people have no process to rank bugs according to importance or popularity, so VLC is basically a hobby project with a professional-looking website. Hence the "send patches" response.

A characteristic example of this is how they still haven't implemented DVD-Video forced subtitles decades after DVD-Video support was added to VLC, which makes any DVDs that use forced subs to subtitle a foreign language/elvish/alienspeak unwatchable. The bug for this issue (#1135) is still open 17 years later.

I just moved to Kodi for my DVD-watching needs, and I suggest you do something similar: Find a player that can play VVC today or risk waiting for decades for VLC to add it.

[birdie]

VVdec has added support for the "film grain synthesis" attribute: https://github.com/fraunhoferhhi/vvdec/pull/178

Add film grain synthesis (based on VFGS). When an FGC SEI message is found in the bitstream, it is decoded and used to synthesize grain on top of the regular decoded picture. No specific commandline options are added, everything is automatic and hardwired = currently there is no way to disable FG synthesis if an FGC SEI message is received.

[birdie]

Just announced Intel Lunar Lake / Xe2-LPG (https://www.anandtech.com/show/21425/intel-lunar-lake-architecture-deep-dive-lion-cove-xe2-and-npu4/6) has been confirmed to support hardware VVC decoding. Finally.

[FranceBB]

I really hope an option is introduced to prevent reintroducing the already removed grain. It would make everyone happy: those who like grain can leave it on and those who prefer cleaner pictures like me just need to disable it, while both of us get the compression efficiency by coding a smoother picture.

As for hardware decoding, that's very good to know from Intel. Feels like we're slowly getting to the point in which H.266 is actually getting usable. :)

[Jamaika]

"Also disclosed was the Intel NPU 4, which Intel claims delivers up to 48 TOPS, surpassing Microsoft's Copilot+ requirements for the new age of AI PCs."
What does new age of AI PCs mean?

"The main change affecting this is the addition of an additional 8 MB side cache, which allows for reduced traffic in the system memory for multimedia-based tasks."
Is this extra memory on the motherboard?

"Intel Lunar Lake has been even further rebuilt in terms of the Media Engine and Display Engine, which is probably the most extensive system in this matter among laptops.
In addition, there is support for HDMI 2.1 and DisplayPort 2.1 (we are talking about full support, i.e. UHBR10, UHBR13.5 and UHBR20, but the type of DP 2.1 supported in a given laptop will depend on the specific OEM) and eDisplayPort 1.5."
Are these power-saving processors just for laptop?

[FranceBB]

What does new age of AI PCs mean?


That's just a term made up by Microsoft to justify shipping Copilot in as many things they could.
Essentially, the era of "AI PC" started with ARM in which you had the normal parts of the CPU doing normal computations and then dedicated accelerators (you can think about them as part of the CPU) to perform AI-related tasks. This, in Microsoft's view, would offload some of the calculations from their datacenter GPUs to the dedicated co-processor unit inside the CPU in the consumer device for the most basic stuff. They set a target and both AMD and Intel did something to reach that so that they could be part of this "AI PC" or "Copilot+" marketing nonsense.

[MoSal]

What does new age of AI PCs mean?


PCs that do mostly-useless low-precision bad math fast in the name of intelligence.


" In addition, there is support for HDMI 2.1 and DisplayPort 2.1 (we are talking about full support, i.e. UHBR10, UHBR13.5 and UHBR20, but the type of DP 2.1 supported in a given laptop will depend on the specific OEM) and eDisplayPort 1.5."

It's not full support if Intel can't partner with others to pressure the HDMI forum to allow support for 2.1 on Linux, and threaten a future boycott if they don't budge (AMD tried alone and failed). Otherwise, "full support" and "no support" are equivalent for us, an admittedly small but significant percentage of users. Directing the cost incurred towards something else would actually be more beneficiary to us. This also applies to dedicated GPUs, which Intel also sells nowadays.

[Jamaika]

Thanks for your replies.
It will be more profitable to buy AMD or Intel. What amounts are we talking about?
As I understand it, AVX512 will replace AVX10. What economical power supply is needed for this? I understand that we will not buy 800W. How to configure it yourself?

[kurkosdr]

It's not full support if Intel can't partner with others to pressure the HDMI forum to allow support for 2.1 on Linux, and threaten a future boycott if they don't budge (AMD tried alone and failed).
HDMI is a front for Hollywood studios to make arbitrary demands to the consumer electronics industry (enabled by the DMCA's "anti-circumvention provisions"). If you don't obey, no HD or 4K HDR Hollywood content for you.

So, with that in mind, it's a case of the HDMI Forum boycotting anyone who doesn't comply with their demands, not the other way around.

[MoSal]

HDMI is a front for Hollywood studios to make arbitrary demands to the consumer electronics industry (enabled by the DMCA's "anti-circumvention provisions"). If you don't obey, no HD or 4K HDR Hollywood content for you.

So, with that in mind, it's a case of the HDMI Forum boycotting anyone who doesn't comply with their demands, not the other way around.

Boycotts/Threats is how we got a single high-capacity compact disc standard (DVD):
https://web.archive.org/web/19981202113012/http://product.info.apple.com/pr/press.releases/1995/q3/950503.pr.rel.cd.html

And if boycotts/threats don't work, hardware vendors/manufacturers could rally around and push for an alternative new standard if they wanted to. We have historical examples of same-gen but later-appearing standard B ending up killing standard A due to vendors not wanting to deal with A.

Hardware vendors/manufactures simply don't consider the current situation a deal breaker for them to want to take such steps.

[birdie]

I've found a treasure trove of sample VVC clips for testing:

https://dvb.org/specifications/verification-validation/vvc-test-content/

They need some name and email, you can type anything.

[benwaggoner]

I really hope an option is introduced to prevent reintroducing the already removed grain. It would make everyone happy: those who like grain can leave it on and those who prefer cleaner pictures like me just need to disable it, while both of us get the compression efficiency by coding a smoother picture.
I've looked at some degrained-for-FGS content with FGS turned off, and it can look pretty weird and unpleasant. The signal-noise ratio is quite low for a lot of grainy content, particularly 16mm and Super35. The degrained versions can kind of look soft and textureless, like a mediocre upscale.

The results aren't as good as a real high-quality noise reduction that mutes the excess grain, but leaves enough texture to keep things from looking abnormally flat.

As for hardware decoding, that's very good to know from Intel. Feels like we're slowly getting to the point in which H.266 is actually getting usable. :)
Wonderful news indeed!

[Yups]

Hardware decoding in action:

https://youtu.be/-2yxPal4wQI?t=1951

[kurkosdr]

Boycotts/Threats is how we got a single high-capacity compact disc standard (DVD):
https://web.archive.org/web/19981202113012/http://product.info.apple.com/pr/press.releases/1995/q3/950503.pr.rel.cd.html

And if boycotts/threats don't work, hardware vendors/manufacturers could rally around and push for an alternative new standard if they wanted to. We have historical examples of same-gen but later-appearing standard B ending up killing standard A due to vendors not wanting to deal with A.

Hardware vendors/manufactures simply don't consider the current situation a deal breaker for them to want to take such steps.
You mean like how Hollywood studios picked the winner of the HD-DVD vs Blu-Ray format war by deciding one day to only throw content at one format (Blu-Ray) while letting the other rot (HD-DVD)? This happened shortly after BD+ gave studios the hope of unbreakable DRM. Whatever studio support HD-DVD had dried up right there and then.

Or how Hollywood studios cut out MacOS X from Blu-Ray and HD-DVD support because MacOS X didn't provide the DRM infrastructure Hollywood studios demanded for Blu-Ray and HD-DVD?

It doesn't matter what happened in the distant past, today pre-recorded content is king and DRM is legally empowered by the DMCA. Hollywood studios can cut out from their encrypted content whatever OS and hardware combination doesn't comply with their arbitrary demands. I mean, what can AMD and Intel do? "Boycott" HDMI 2.1 and come out and say "Nvidia GPUs as well as every $400 console out there support HDMI 2.1 but our flagship GPUs don't, please buy our flagship GPUs"? If they do that, they might get that 2% of users running Desktop Linux but will lose the much bigger market of Windows users who want their new GPU to support HDMI 2.1.

The weird thing in this case is that HDMI 2.1 is required only if you want 4K@120fps, and Hollywood doesn't serve any 4K@120fps content, but they can still mandate all kinds of DRM requirements by acting as gatekeepers to the HDMI spec. DisplayPort is technically a thing but isn't a thing on TVs (due to lack of eARC support), so you want at least one HDMI 2.1 port if you want to output 4K@120fps to a TV (which means GPU vendors can't boycott HDMI 2.1). And then there is the open question of whether encrypted 8K content will be allowed on DisplayPort or be HDMI 2.1-only.

[ksec]

Hardware decoding in action:

https://youtu.be/-2yxPal4wQI?t=1951

Great, excluding CPU and GPU that is probably around 2W decoding 4K. Good for Desktop, Good Enough for Laptop. not quite Smartphone ready yet. But hopefully next year for Qualcomm Mediatek and Apple.

Now we need encoders.

[FranceBB]

Hold on a second, I thought that the whole thing about HDMI 2.1 not being allowed on Linux was only because AMD tried to make the support part of its open source driver.
I might be wrong here, but I remember reading people suggesting AMD to ship a binary blob instead so that it would have been accepted.
Did I get it wrong?

[Yups]

Great, excluding CPU and GPU that is probably around 2W decoding 4K. Good for Desktop, Good Enough for Laptop. not quite Smartphone ready yet. But hopefully next year for Qualcomm Mediatek and Apple.

Now we need encoders.


Maybe less because the RAM is included in the package power on Lunar Lake. Encoding hopefully on Xe3.

[ksec]

Maybe less because the RAM is included in the package power on Lunar Lake. Encoding hopefully on Xe3.

I would expect at least 1W during active use. That puts decoding into 1W category. Sub 1W when deciding 1080P / 2K content. Pretty impressive. That doesn't take into account the bitrate it was decoding. Sounds like good enough for me!

Bring me x266!

[oibaf]

Dolby Laboratories to acquire GE Licensing in $429m deal (https://finance.yahoo.com/news/dolby-laboratories-acquire-ge-licensing-101608757.html)

Technology company Dolby Laboratories has announced a definitive agreement to acquire GE Licensing from GE Aerospace in an all-cash deal valued at $429m.The inclusion of GE Licencing’s video codec technology patents such as HEVC and VVC will complement and expand Dolby's existing intellectual property portfolio.