AOmedia next (AV2) codec

[GeoffreyA]

Please tell me that Google hasn't started doing on the YouTube app and YouTube mobile that annoying thing they are doing on YouTube desktop, where they'll serve you AV1 even if your computer only has H.264 hardware acceleration? I had to install h264ify to prevent some old laptops from doing a vacuum cleaner impression while watching YouTube. On mobile it will drain the battery like no tomorrow.

I tested it now on the Gamers Nexus video, and on the computer, it uses AV1, but on my phone, which does not have AV1 hardware, it uses VP9; so they seem to be querying the hardware properly.

[hajj_3]

AV2 v1.0.0 has been released!!!

https://github.com/AOMediaCodec/avm/releases/tag/v1.0.0

[Z2697]

Is it the release of specification or the reference software?
https://av2.aomedia.org/ This thing still says draft.
https://web.archive.org/web/20260528203129/https://av2.aomedia.org/ For future reference.

[hajj_3]

Is it the release of specification or the reference software?
https://av2.aomedia.org/ This thing still says draft.
https://web.archive.org/web/20260528203129/https://av2.aomedia.org/ For future reference.

It is the reference encoder and i think decoder. They haven't updated their website yet. Hopefully within the next few days they will make a blog post and release the final specification document.

[Z2697]

Why they love trolling...

[Jamaika]

AV2 v1.0.0 has been released!!!

https://github.com/AOMediaCodec/avm/releases/tag/v1.0.0
Finally, the first release of AV2 is officially planned next week (https://github.com/AOMediaCodec/avm/commit/87aa8dc44e8a40f992604111a5ce83cf413ec9b7)...

btw, a dav2d x64 Windows build for those whom interested : https://www.mediafire.com/file/m0hgq5tdabsggf8/dav2d-0.0.1-142_x64.7z/file
Now that it is released, you can test and check compatibility.
So I decided to test the AV2 decoder. I generated AV2 images using a webp2 pump to see if they could be displayed.
https://chromium.googlesource.com/codecs/libwebp2/+/d5920d8fe6abb5b3ba9b9bef3924f18433dd6d37
https://github.com/AOMediaCodec/avm/commit/f2364007035db686b220e3ec17d17abca2037328
https://code.videolan.org/videolan/dav2d/-/commit/ca6c40055baff65f4f7dacc4484bbf17c5251426

I'm having a problem with the AV2 encoder. One definition is deleted, but that's irrelevant. The images are being generated, but how do I decode them?
I used the latest 8-bit DAV2D. Error messages are displayed. I corrected the errors as best I could, but the image won't decode.
I used the AVM decoder. To my surprise, the image converted correctly. Unfortunately, decoders do not show input file information. It's unclear whether the image is 8-bit or 12-bit.

avmdec_avx.exe input_8bit.av2 -o output_8bit.yuv
avmdec_avx.exe input_12bit.av2 -o output_12bit.yuv //fantasy, distant future, added TEST_ONLY_12BIT_PROFILE
dav2d_avx2.exe -i input_8bit.av2 -o output_8bit.yuv //only 8bit
Error decoding frame: Invalid argument
Defaul is MAIN_444_10_IP1 that means InternalBitDepth is no less than 10. How is an 8bit decoder supposed to decode this?
ewp2_avx.exe input_12bit.y4m -size -q 100 -nometadata -effort 7 -csp 0 -o output_???bit.wp2
av2enc_avx.exe (-depth 12) -q 100 -444 -size 280x420 -effort 7 -threads 4 -pass 1 -tune ssim input_???bit.wp2 -d output_12bit.av2

Decoder dav2d 0.0.1
https://www.sendspace.com/file/duxvuf
Codec AVM 1.0.0
https://www.sendspace.com/file/cvevjm
Image webp2 0.0.1
https://www.sendspace.com/file/rj8ynd

[Z2697]

It looks like Jamaika's artisanal build process has meaning when the official build system doesn't work :) On Windows.
I'd say I'm a experienced Linux user but sadly my main system is still W10.

Oh okay I just had to read the actual cmake codes instead of just "trust it"...

This works in MSYS2:
cmake -DCONFIG_ML_PART_SPLIT=0 -DCONFIG_DIP_EXT_PRUNING=0 -DENABLE_TESTS=0 -DENABLE_TESTDATA=0 -Bbuild
But lacks "AI" features, whatever that is...

[Spyros]

The final AV2 specification (v1.0.0) has been released!

https://av2.aomedia.org/

[Z2697]

So they were just having sometime to update the website.
Now let's wait for SVT-AV2!
Hopefully it's not gonna take long, since the teams are working closely- I suppose.

(Great, so the AOM calendar is like half a year behind real world.)

[Zebulon84]

When they announced (https://aomedia.org/press%20releases/AOMedia-Announces-Year-End-Launch-of-Next-Generation-Video-Codec-AV2-on-10th-Anniversary/) "year-end release", we all understood Calendar year 2025, but they probably meant Academic year 25-26 ;)

[GeoffreyA]

So they were just having sometime to update the website.
Now let's wait for SVT-AV2!
Hopefully it's not gonna take long, since the teams are working closely- I suppose.

(Great, so the AOM calendar is like half a year behind real world.)

Yes, this time we want to go straight to SVT-AV2 and not waste a couple of years with the tortoise-like reference encoder.

[hajj_3]

Dav2D blog post: https://web.archive.org/web/20260531130034/https://jbkempf.com/blog/2026/dav2d/

[oibaf]

Dav2d is already packaged in Debian (14) and Ubuntu (26.10):
https://tracker.debian.org/pkg/dav2d
https://launchpad.net/ubuntu/+source/dav2d

[ksec]

Not really. They originally said that but after speaking to manufacturers they realised that manufacturers don't want to have to use more silicon every 3yrs for a new codec. They other reason is that a know codec every 3yrs would see little adoption. Having a 8yr gap between AV1 and AV2 was a good idea as AV1 hardware decoders are now in all computers and all high end smartphones. Low end phones are supposed to get AV1 support this year or next year.

That was their excuses. As if they were completely new to codec development. Nearly everyone in the codec community, including professional see it as lies.

But they got the press release, and all of their supporter to rally behind, suggesting because it is Google, a codec every 2-3 years was possible. Because Google could somehow afford to design the hardware decoder IP and give it to everyone for free. Guess how that turned out?

[rwill]

A new codec every 2-3 years makes sense, even if the actual coding gains are small.

YouTube just needs to re-encode everything, consumers will need to buy a new phone and older content illegaly downloaded from YouTube will become deprecated. Cannot let a chip grow every iteration beyond some point so older YouTube codecs can be kicked out of new chips.

Android devices are just Google Services access points anyway, and Google wants to push ahead. No need to orient at a slow and dysfunctional MPEG market.

I wonder if AV2 is already in the required codecs list for the next Android TV certification tiers....

And where is SVT-AV2? Intel better re-instantiate the development program. Its the right of the AOM enthusiasts to get a usable encoder for free, given their unconditional support for the project.

[GeoffreyA]

A new codec every 2-3 years makes sense, even if the actual coding gains are small.

YouTube just needs to re-encode everything, consumers will need to buy a new phone and older content illegaly downloaded from YouTube will become deprecated. Cannot let a chip grow every iteration beyond some point so older YouTube codecs can be kicked out of new chips.


Perhaps if there were a halfway approach: instead of a hard-coded ASIC, a generalised encoder-decoder unit whose firmware could be updated with new codecs.


And where is SVT-AV2? Intel better re-instantiate the development program.

Hopefully, juliobbv or BlueSwordM could comment. After the nightmare early days of libaom, whose speed and Instagram plastic were renowned, I don't think many an enthusiast will want to touch the reference encoder.

[Z2697]

Perhaps if there were a halfway approach: instead of a hard-coded ASIC, a generalised encoder-decoder unit whose firmware could be updated with new codecs.



Hopefully, juliobbv or BlueSwordM could comment. After the nightmare early days of libaom, whose speed and Instagram plastic were renowned, I don't think many an enthusiast will want to touch the reference encoder.

I guess if power efficiency is considered, the ASIC is still the inevitable choice.

libaom is/was semi-usable at least, but avm is like completely unusable (slow)...

[GeoffreyA]

libaom is/was semi-usable at least, but avm is like completely unusable (slow)...

I think it took me about 45 minutes for 96 frames.

[kurkosdr]

Perhaps if there were a halfway approach: instead of a hard-coded ASIC, a generalised encoder-decoder unit whose firmware could be updated with new codecs.
AMD tried doing that in some high-end R600 GPUs (using the GPGPU cores, aka the pixel shaders, to do video decoding), but power efficiency was below ASIC decoding and users didn't receive it well:
https://en.wikipedia.org/wiki/Unified_Video_Decoder#Availability

I would prefer a compromise: If ASIC decoding is not available, use GPGPU decoding (that can be added later via driver updates), but I haven't seen anyone do this (either GPU vendor or player/browser using OpenCL).

[soresu]

Perhaps if there were a halfway approach: instead of a hard-coded ASIC, a generalised encoder-decoder unit whose firmware could be updated with new codecs.

You mean an FPGA?

With video codecs getting increasingly complex to extract increasingly diminishing returns I'm not certain an FPGA could handle it, IIRC they tend to be pretty density challenged per mm2 relative to ASICs.

[soresu]

I would prefer a compromise: If ASIC decoding is not available, use GPGPU decoding (that can be added later via driver updates), but I haven't seen anyone do this (either GPU vendor or player/browser using OpenCL).

I think GPGPU decoding is technically possible for modern codecs like AV1/VVC, but the higher complexity, multiple references and various other things mean that running it is like an emulator ubershader (shader based console GPU emulation) on steroids.

From what I've heard over the years it just doesn't play well to a GPUs strengths past a certain level of complexity for a program to be executed purely in GPU, and splitting up the workload between CPU and GPU for hybrid compute requires super tight integration, low latency and high bandwidth of the likes you don't see in many SoCs.

It might be worth Apple's time and money to do it, but they'd probably just wait for their own ASIC to mature, while using dav2d in the meantime.

[Z2697]

AMD tried doing that in some high-end R600 GPUs (using the GPGPU cores, aka the pixel shaders, to do video decoding), but power efficiency was below ASIC decoding and users didn't receive it well:
https://en.wikipedia.org/wiki/Unified_Video_Decoder#Availability

I would prefer a compromise: If ASIC decoding is not available, use GPGPU decoding (that can be added later via driver updates), but I haven't seen anyone do this (either GPU vendor or player/browser using OpenCL).

The page literally says it's ASIC.

For anyone who might be interested, GPGPU decoding of prores and ffv1 etc. is availble in FFmpeg.
Performance is roughly same as CPU.
The only worth part I can think of is offloading to GPU, so when doing fast transcoding the CPU can have more resource.

[soresu]

For anyone who might be interested, GPGPU decoding of prores and ffv1 etc. is availble in FFmpeg.
Performance is roughly same as CPU.
The only worth part I can think of is offloading to GPU, so when doing fast transcoding the CPU can have more resource.

I saw that, and I could definitely see the interest for video editors with non Apple hw (includes ProRes ASICs at this point?).

Do you know if anyone has done power consumption comparisons?

[Blue_MiSfit]

I'd be astonished if vulkan is more efficient than videotoolbox native hardware decode

[soresu]

I'd be astonished if vulkan is more efficient than videotoolbox native hardware decode

I meant CPU sw decode vs GPGPU decode.

[Z2697]

I meant CPU sw decode vs GPGPU decode.

When I said "performence" I did mean both speed and power consumption...
But I can't (or not willing to) control my system precisely for this test, so take it with a grain of salt.
Depending on the design of the chip(s), for example Intel's efficiency cores, things may be more interesting.
My system has not much to do with efficiency, so they are just about the same. (modern chips are quite efficient and I like it this way, but efficiency is only in the back of my mind, faintly, you know, when I hear fans...)

So I said when doing fast transcoding, i.e. decoding at that speed will be a significant portion of the load, it's worth offloading to GPU.
Otherwise, I don't really see many use case... well maybe doing native GPU pipeline without the need to pump raw pixel data between CPU/RAM and GPU/VRAM? IDK.

[GeoffreyA]

AMD tried doing that in some high-end R600 GPUs (using the GPGPU cores, aka the pixel shaders, to do video decoding), but power efficiency was below ASIC decoding and users didn't receive it well:
https://en.wikipedia.org/wiki/Unified_Video_Decoder#Availability

I would prefer a compromise: If ASIC decoding is not available, use GPGPU decoding (that can be added later via driver updates), but I haven't seen anyone do this (either GPU vendor or player/browser using OpenCL).

It might be just marginally more efficient than an optimised software decoder.

You mean an FPGA?

With video codecs getting increasingly complex to extract increasingly diminishing returns I'm not certain an FPGA could handle it, IIRC they tend to be pretty density challenged per mm2 relative to ASICs.

Something along these lines, but generic in the sense of defining common functions across decoders and encoders, then tying it up with codec-specific stuff that can be changed.

[ksec]

A new codec every 2-3 years makes sense, even if the actual coding gains are small.

YouTube just needs to re-encode everything, consumers will need to buy a new phone and older content illegaly downloaded from YouTube will become deprecated. Cannot let a chip grow every iteration beyond some point so older YouTube codecs can be kicked out of new chips.

Android devices are just Google Services access points anyway, and Google wants to push ahead. No need to orient at a slow and dysfunctional MPEG market.



It really doesn't.

AV2 currently offers 20-30% BD-Rate took nearly 8 years. If you could make a new video codec very 2-3 year. Let's assume you can. You will still need at least 1 year to design the ASIC that is low power, which is already an impossible task. You will need another 1 year to integrated into the SoC. On the assumption your SoC release schedule fits into next Smartphone sales cycle perfectly that is at least 6 - 8 months validation process.

The hardware alone is 2-3 years lead time minimum *after* your codec development cycle. And that is assuming the codec has the conformance, testing kit and everything in place.

>YouTube just needs to re-encode everything

Google is already having issues just to keep up with new video upload encoding, excluding storage cost problems. You can't re-encode a Video which has little to zero adoption on Mobile. When 80% of the total consumption on Youtube, 95%+ if you are Facebook, Instagram or TikTok on mobile.

Even with Apple, a new mobile phone with new SoC only sell about 100M unit in total, that is ~8% of their iPhone user spread across the world. It is far lower on Android.

Let's just assume 8%, which is not even a best case but unrealistic scenario. You will have to encode AV2 for 8%, AV1 for 30%, H.264 for the rest. And if you do 2 -3 years, You will have AV3 for 8%, AV2 for 24%, AV1 for 10%? and Rest H.264?

Upgrading firmware and GPGPU acceleration is even worse. Simply because vendors are not going to upgrade their phone for free. It requires additional work and validation and man power. Android took years to even have long form of Software and security support. Forget about firmware upgrade without the help of Qualcomm, MediaTek working along side all Chinese Vendors. Their interest do not align.

And the end of the day. What is the point of a new codec? Do new codec really help to sell new Smartphone? It doesn't. It only helps Google. If a new codec requires constant work on hardware and die space, which has additional cost, what is the incentive for hardware side to adopt it? Other than perhaps great marketing to minor group of people? Google might have a better excuses if their Pixel Tensor SoC are leading the pack, but they are not.

None of that is new, It wasn't even new in 2016. But the recent update from both AOM and MPEG / VCEG has finally admitted they will now need to consider adoption cycle. And may be we should stop fantasying new video codec without hardware adoption.

[Z2697]

I think rwill is being sarcastic :rolleyes:

[hajj_3]

What is the point of a new codec? Do new codec really help to sell new Smartphone? It doesn't. It only helps Google. If a new codec requires constant work on hardware and die space, which has additional cost, what is the incentive for hardware side to adopt it? Other than perhaps great marketing to minor group of people?

A new codec saves bandwidth costs for youtube, netflix, amazon prime video, appletv, disney+ etc not just 1 company. It also reduces bandwidth for consumers which is particularly beneficial when using your phone's data contract allowance. That saves consumers money as they can have a cheaper data plan. It also helps to reduce data congestion during peak times on 4G/5G as some major cities have slow speeds during peak time due to excessive bandwidth usage.

Another advantage is faster startup of videos. Videos only play once they have download a bit of the beginning of the video. AV2 will have a smaller filesize so if you want to download the first 3 seconds it will download it faster. This is particularly beneficial for platforms like tiktok and instagram.

[rwill]

I think rwill is being sarcastic :rolleyes:

Yeah. I have now read my comment again and still thought this is obvious. Shows that at least ksec seems to be subjected to a constant stream of nonsense his mind has to fight through daily, breaking his sarcasm detector. I blame western social media.

In China they have made it so that only certified and approved people can comment on certain topics on their social media. If the deterioration of the intellectual level in the western internet continous we might have to establish a similar approach to save our society.

[rwill]

A new codec saves bandwidth costs for youtube, netflix, amazon prime video, appletv, disney+ etc not just 1 company. It also reduces bandwidth for consumers ...

Oh boy do I have news for you. There have been hardly real bandwidth savings in the last 10+ years in the end-consumer codec space. What happened is that the recent codecs have special tools which help for special content cases, but these improvements are not generic.

A generic movie or UGC is not special, its generic. The tools arent helping there. Saving 25-50% bandwidth with VVC or AV2 switching from HEVC or AV1 is marketing talk. Sure enough, if the plan is to cut bitrate by 30% the streaming services or YouTube can do just that, the engineers will have to if they want to keep their job, but it will hurt quality and thus QOS. And consumers will notice. The businesses will most likely do the cut anyway.

There are also quality to size gains coming from algorithmic encoder improvments that are generic, but the % gain they state with new codecs is most of the time only referencing the state of the encoder implementation there was when the old standard was released, not the state of the art when the new standard released. So more unreal alleged gains for the new codec.

Thats some reasons why x264 still beats recent codec encoder implementations frequently in subjective quality given sane settings.

[GeoffreyA]

In China they have made it so that only certified and approved people can comment on certain topics on their social media. If the deterioration of the intellectual level in the western internet continous we might have to establish a similar approach to save our society.

It's as Aldous Huxley noted in Brave New World Revisited, that more than the battle between truth and falsehood, it was the irrelevant and unreal that would drown out everything else. In true BNW-style, it tends to distract us from the real issues at hand, or, in film terms, what the Matrix is.

"In regard to propaganda the early advocates of universal literacy and a free press envisaged only two possibilities: the propaganda might be true, or it might be false. They did not foresee what in fact has happened, above all in our Western capitalist democracies—the development of a vast mass communications industry, concerned in the main neither with the true nor the false, but with the unreal, the more or less totally irrelevant. In a word, they failed to take into account man's almost infinite appetite for distractions."

[Z2697]

Oh boy do I have news for you. There have been hardly real bandwidth savings in the last 10+ years in the end-consumer codec space. What happened is that the recent codecs have special tools which help for special content cases, but these improvements are not generic.

A generic movie or UGC is not special, its generic. The tools arent helping there. Saving 25-50% bandwidth with VVC or AV2 switching from HEVC or AV1 is marketing talk. Sure enough, if the plan is to cut bitrate by 30% the streaming services or YouTube can do just that, the engineers will have to if they want to keep their job, but it will hurt quality and thus QOS. And consumers will notice. The businesses will most likely do the cut anyway.

There are also quality to size gains coming from algorithmic encoder improvments that are generic, but the % gain they state with new codecs is most of the time only referencing the state of the encoder implementation there was when the old standard was released, not the state of the art when the new standard released. So more unreal alleged gains for the new codec.

Thats some reasons why x264 still beats recent codec encoder implementations frequently in subjective quality given sane settings.

I do think most of the time those numbers can reflect generic improvement.
It's just intra prediction, motion estimation, residual transform encoding, in-loop filter(s), and entropy encoding,
I tend to think there's no/very few special cases, because what we want to encode is some sequence of the illusion of something moving on the screen after all.

It's just the the numbers are exaggerated.
And some contents rely more on one area, but the number may represent all combined.
For example, fast chaotic motions rely more on intra prediction.

[rwill]

I do think most of the time those numbers can reflect generic improvement.

Well, lets take the tool ALF, the Wiener based adaptive loop filter. Great BD-Rate gains using PSNR as metric. Lets say 5%. But is it really a generic 5% improvement when, in addition to coding artifacts, small details are filtered away as well and the picture looks like as if some strong selective gaussian blur with large radius has been applied? My opinion is "No".

[Z2697]

Well, lets take the tool ALF, the Wiener based adaptive loop filter. Great BD-Rate gains using PSNR as metric. Lets say 5%. But is it really a generic 5% improvement when, in addition to coding artifacts, small details are filtered away as well and the picture looks like as if some strong selective gaussian blur with large radius has been applied? My opinion is "No".

Yeah, jump down three lines from where you quote...

And it's like the SAO situation, the implementation matters.

I think ALF in VVC is similar to CDEF in AV1? (restoration filter has a Wiener mode but it's on a larger level, correct me if I'm wrong)
It's not really that bad...

[Z2697]

The AV2 sample in VQAnalyzer is too low quality (blame avm default setting), so I encoded the y4m sample with a higher quality, CQP 140.
Maybe too high (bigger than AV1 sample), but the encoder is dead slow so I don't want to encode another one.
Encoder is built by Clang in MSYS2 clang64 environment, without the ML (TFLite) features, there's a crash in

if (sms_tree != NULL) sms_tree->partitioning = PARTITION_NONE;

I commented out this thing...
(I later found out that it's "caused" by a inlined function that called this function, so perhaps I'll noinline it and do another encode... later...)
(sms_tree is function parameter and should be NULL in this call but some weird thing make the inlined call pass in 0x85008500850085 ...or some other garbage similar to it)
https://pixeldrain.com/u/6xs2X11a

[kurkosdr]

The page literally says it's ASIC.
Read more carefully, it's wasn't an ASIC on the Radeon HD 2900 XT.

Most of the Radeon HD 2000 series video cards implement the UVD for hardware decoding of 1080p high definition contents.[31] However, the Radeon HD 2900 series video cards do not include the UVD (though it is able to provide partial functionality through the use of its shaders), which was incorrectly stated to be present on the product pages and package boxes of the add-in partners' products before the launch of the Radeon HD 2900 XT,

[kurkosdr]

You mean an FPGA?

With video codecs getting increasingly complex to extract increasingly diminishing returns I'm not certain an FPGA could handle it, IIRC they tend to be pretty density challenged per mm2 relative to ASICs.
Something along these lines, but generic in the sense of defining common functions across decoders and encoders, then tying it up with codec-specific stuff that can be changed.

How would an FPGA help here? Once an FPGA is programmed, it functions as an ASIC with worse power consumption and heat generation (compared to an ASIC made with the same node process). FPGAs can't be reprogrammed, not that even if they could, most users would buy an FPGA (re-)programmer and disassemble their devices to pop out the chip to reprogram it.

What you could have is an ASIC that allows low-level access to features such as IDCT, motion prediction, deblocking etc so those can be used by software to decode new standards, but considering how much the algorithms of those things change with each new standard, I doubt something like that can exist. For example, DST was introduced in HEVC, so any H.264-era ASICs that implement only IDCT (inverse DCT) won't be able to do inverse DST (aka decode DST), so your low-level access to the ASIC's functions is worthless, since you'll have to fall back to software processing anyway.

For anyone who might be interested, GPGPU decoding of prores and ffv1 etc. is availble in FFmpeg.
Performance is roughly same as CPU.
The only worth part I can think of is offloading to GPU, so when doing fast transcoding the CPU can have more resource.
Aww... sucks. I expected GPGPU decoding to give a massive boost compared to CPU decoding, just like it does for cryptocurrency mining, since video decoders are inherently parallel due to the fact the input (the compressed bitstream) is already split into multiple independent macroblocks.

[Z2697]

FPGAs can't be reprogrammed

They can, that's the purpose of FPGA...

most users would buy an FPGA (re-)programmer and disassemble their devices to pop out the chip to reprogram it.

That's because FPGA is not usually end up in products the general consumer would use.
If they do, they will be designed in such way that a driver update, or maybe lower level, VBIOS update, can reprogram the FPGA.

[Z2697]

Read more carefully, it's wasn't an ASIC on the Radeon HD 2900 XT.

OK... so it's not like they had no other choice, they essentially did decoding design twice just to save some ASIC chips on ironically, high-end GPUs...
Weird choice.

Perhaps they need the die area to put in extra GPU cores?

[Z2697]

The AV2 sample in VQAnalyzer is too low quality (blame avm default setting), so I encoded the y4m sample with a higher quality, CQP 140.
Maybe too high (bigger than AV1 sample), but the encoder is dead slow so I don't want to encode another one.
Encoder is built by Clang in MSYS2 clang64 environment, without the ML (TFLite) features, there's a crash in

if (sms_tree != NULL) sms_tree->partitioning = PARTITION_NONE;

I commented out this thing...
(I later found out that it's "caused" by a inlined function that called this function, so perhaps I'll noinline it and do another encode... later...)
(sms_tree is function parameter and should be NULL in this call but some weird thing make the inlined call pass in 0x85008500850085 ...or some other garbage similar to it)
https://pixeldrain.com/u/6xs2X11a

I can't help but notice that I can just use Linux, LOL.
https://pixeldrain.com/l/vMfjQcDE

(In a VM)

[kurkosdr]

They can, that's the purpose of FPGA...



That's because FPGA is not usually end up in products the general consumer would use.
If they do, they will be designed in such way that a driver update, or maybe lower level, VBIOS update, can reprogram the FPGA.
It depends on the FPGA, but if you want to get anything resembling good performance-per-watt, you need the kind of FPGAs that cannot be reprogrammed once programmed (antifuse-based).

And if you don't care about performance-per-watt but still want to keep the CPU free for other tasks, GPGPU decode is right there.

[kurkosdr]

OK... so it's not like they had no other choice, they essentially did decoding design twice just to save some ASIC chips on ironically, high-end GPUs...
Weird choice.

Perhaps they need the die area to put in extra GPU cores?
The spat between GPU vendors for the all-important "performance crown" was insane during the 90s and 2000s, and it was the cause of several paper launches, officially-overclocked hardware of dubious reliability (FX 5800 Ultra), rushed/sloppy engineering causing failures even within the warranty period (Nvidia bumpgate), and cheats in the drivers that would embarrass the GPU vendor (see: ATI quack scandal).

Eventually, Nvidia realized during its Fermi "mistake" that gamers don't care about power efficiency or high-end GPUs fitting a certain price bracket, so the gaming GPU industry shifted to brute force (in the form of huge transistor counts and comically oversized cooling solutions).

But back in the 2000s, the die area occupied by the video-decoding circuitry mattered.

[excellentswordfight]

FPGAs can't be reprogrammed, not that even if they could, most users would buy an FPGA (re-)programmer and disassemble their devices to pop out the chip to reprogram it.
It depends on the FPGA
Oh common, like you knew what a antifuse fpga was when you made the first post. SRAM-based fpga are by far the most common type.

I work with fpga-based products all the time, vendors ships new features - comes with an update, fpga is re-programmed.

If a updatable hw-decoder using an fpga is practical from a perf/w standpoint though? No idea, out of my expertise.

But on the notion of having a fpga on a more general purpose chip, If memory serves my right, I do think that at some point Intel had Xeons with a fpga on the same package, not sure what happened with that though.

[kurkosdr]

Oh common, like you knew what a antifuse fpga was when you made the first post. SRAM-based fpga are by far the most common type.
FYI it's common knowledge that some FPGAs can't be reprogrammed and they are the ones getting good performance-per-watt.

But anyway, if you think you know what I know better than me, go ahead.

[excellentswordfight]

FYI it's common knowledge that some FPGAs can't be reprogrammed and they are the ones getting good performance-per-watt.

But anyway, if you think you know what I know better than me, go ahead.
I was not the one claiming that they, and not some, cannot be re-programmed, and if they could they needed a re-programmer. It only sounds you are trying to backtrack cause you did a bit of googling, and started to talk about a niche type of FPGA that would be completely irrelevant to the discussions as it was specifically about having the ability to update the hardware with new de-coders.

And apparently I do know more given the nonsens in your first post which no one familair with fpgas would have wrote.

[kurkosdr]

I was not the one claiming that they, and not some, cannot be re-programmed, and if they could they needed a re-programmer. It only sounds you are trying to backtrack cause you did a bit of googling, and started to talk about a niche type of FPGA that would be completely irrelevant to the discussions as it was specifically about having the ability to update the hardware with new de-coders.

And apparently I do know more given the nonsens in your first post which no one familair with fpgas would have wrote.
FYI I was taught about FPGAs that are programmed by blowing fuses (or more accurately, anti-fuses) in uni, but what do I know about myself.

[rwill]

FYI I was taught about FPGAs that are programmed by blowing fuses (or more accurately, anti-fuses) in uni, but what do I know about myself.

Wild, were you also taught at that uni that "DST was introduced in HEVC, so any H.264-era ASICs that implement only IDCT (inverse DCT) won't be able to do inverse DST (aka decode DST)" ?

FYI: I too blew some fuses at the uni I got taught things, even so many that the lecturer suggested to me skipping practical lab assignments after a while.

[kurkosdr]

Wild, were you also taught at that uni that "DST was introduced in HEVC, so any H.264-era ASICs that implement only IDCT (inverse DCT) won't be able to do inverse DST (aka decode DST)" ?

FYI: I too blew some fuses at the uni I got taught things, even so many that the lecturer suggested to me skipping practical lab assignments after a while.

(oh look, the forum's resident arse is here)

Anyway, where exactly is the wrong in my statement? While DST existed as a mathematical concept since forever, it was introduced in HEVC (whether it was introduced in video compression standards or in cauliflower agriculture, I will leave that to the reader's ability to fill-in context to figure it out). So, any ASIC that can only do IDCT won't be able to do IDST (because such feature is never exposed anyway), so you'll have to fall back to software. It's one example of how, no matter how much fine-grained control you have over the ASIC, you can't re-use an existing ASIC to decode new video compression standards without falling back to software at least for some things.