AOmedia next (AV2) codec [Archive] - Page 2

BlueSwordM

27th April 2025, 20:45

Jamaika

27th April 2025, 21:42

The main trick with CWG, aka proposals, is that they have to be rock solid to find themselves into production.
Their definition of rock-solid depends on a lot of members: hardware teams, software teams and worst of all, PSNR/SSIM scores.
Some of us have had to do a lot of work convincing peeps that a feature that increases perceptual quality and SSIMU2/butteraugli-jxl/XPSNR scores at the cost of non perceptual blur metrics, PSNR/SSIM.
2 features were added with the behaviors cited above and yet, some people complained :P
They did manage to go through, but it was hard.

I created something but not everything works for me under gcc.
I deleted CONFIG_ENABLE_IBC_NAT, CONFIG_IBP_WEIGHT.
Frames-I for AV2 work for me under libwebp2. I'll add plus for AV2 for large size 5212x3468 support.
av2enc_avx.exe -q 100 -444 -size 280x420 -effort 7 -threads 4 -pass 1 -tune ssim image_jpeg.wp2 -d output.av2
tune butteraugli workes with latest jpegxl. Delete default BT709:
/*if (img->mc != 0 && img->mc != AOM_CICP_MC_BT_709 &&
img->mc != AOM_CICP_MC_BT_601 && img->mc != AOM_CICP_MC_BT_470_B_G) {
ERROR(
"Only BT.709 and BT.601 matrix coefficients supported in "
"tune=butteraugli mode. Identity matrix is treated as BT.601.");
}*/

av1enc_avx.exe -q 100 -444 -size 280x420 -effort 7 -threads 4 -tune butteraugli image_jpeg.wp2 -d output.av1

I wasn't able to create a movie.
https://gitlab.com/AOMediaCodec/avm/-/commit/0ee2f9e68420aef0d69aa91cd975decc71064bcd
ffmpeg_avx2.exe -i "video.mp4" -f rawvideo -vf scale=1920:1080: in_range=limited: out_range=limited -frames:v 500 -pix_fmt yuv420p - | aomenc.exe --verbose --limit=500 --input-bit-depth=8 --i420 --width=1920 --height=1080 --ivf --good --passes=1 --pass=1 --bit-depth=8 --fps=30000/1001 --threads=20 --cpu-used=9 --end-usage=cq --qp=0 -o avm_yuv420p10le.ivf -

Assertion failed: is_inter_compound_mode(mode), file c:\gcc1150\x86_64-w64-mingw32\include\av1\common\blockd.h, line 178

https://www.sendspace.com/file/gh11if

benwaggoner

2nd May 2025, 02:00

The main trick with CWG, aka proposals, is that they have to be rock solid to find themselves into production.

Their definition of rock-solid depends on a lot of members: hardware teams, software teams and worst of all, PSNR/SSIM scores.

Some of us have had to do a lot of work convincing peeps that a feature that increases perceptual quality and SSIMU2/butteraugli-jxl/XPSNR scores at the cost of non perceptual blur metrics, PSNR/SSIM.

2 features were added with the behaviors cited above and yet, some people complained :P

They did manage to go through, but it was hard.
Sir, you did the work of Heroes!

People treat PSNR like some sort of fundamental definition of distortion rather than the decades-old "eh, easy to calculate and better than the other obvious alternatives" metric it truly is. And the square root of squares gets you a free absolute value conversion.

Lots of folks with a computer science background but without a neuropsychology or vision science background can assume that PSNR is what's before psychovisual optimization. But it's ALL psychovisual optimizations. It's just some of them are so old we don't really think about how they came to be.

sRGB/Rec. 709 is a perceptual optimization that makes 8-bit encoding work well within the range of what good CRTs used to be capable of reproducing.

Gamma is a psychovisaul optimization based on a first-order approximation of the human visual and CRT EOTF, easily implemented in simple analog circuitry. PQ is the second order approximation (but assumes a specific fixed ambient light). The non-psychovisual implementation would be linear light values.

Quant/Lambda tables are psychovisual optimizations based on our more accurate perception of horizontal and vertical details versus diagonal. And historically the PAL and NTSC versions embedded the different default sample aspect ratios (720x480 versus 720x576). The non-psychovisual implementation would be a flat quantizer.

Frequency transforms like DCT and iDCT themselves are perceptual optimizations about how our eyes and brains detect edges more than absolute brightness and color spatially. The non-psychovisual implementation would probably be pixel-based. And square pixels themselves are more of a computational friendly approach. Why not triangles or hexagons?

paul97

3rd August 2025, 05:36

Have you got an AVM build for sse4 Windows 10 65 bit as they fixed msvc build yesterday? Thank You. Do it needs to compile wsl or bash.

Jamaika

4th August 2025, 08:15

https://www.sendspace.com/file/azxpwg

mlkj

15th September 2025, 20:37

AOMedia says they're planning a release of AV2 by end of year.
Not clear if that means freezing and ratifying the spec, officially branding AVM as AV2, or if it's purely symbolic to mark the anniversary.

https://aomedia.org/press%20releases/AOMedia-Announces-Year-End-Launch-of-Next-Generation-Video-Codec-AV2-on-10th-Anniversary/

birdie

16th September 2025, 00:07

The Alliance for Open Media (AOMedia), a global collaboration of innovators working together to define and deploy open standards that power the next generation of media experiences, today announced the upcoming launch of the next evolution in open video coding: AV2. Set for a year-end release, AV2 is not only an upgrade to the widely adopted AV1 but also a foundational piece of AOMedia’s future tech stack.

AV2, a generation leap in open video coding and the answer to the world’s growing streaming demands, delivers significantly better compression performance than AV1. AV2 provides enhanced support for AR/VR applications, split-screen delivery of multiple programs, improved handling of screen content, and an ability to operate over a wider visual quality range. AV2 marks a milestone on the path to an open, innovative future of media experiences.

To me it sounds like the spec will be ratified by the end of 2025.

Jamaika

17th September 2025, 13:18

To me it sounds like the spec will be ratified by the end of 2025.
I gave in. I deleted the old version of AVM 10.0.1 6b2b423, which was working. The new version won't even start in tests. It's still a long way off.
https://www.sendspace.com/file/302x5f

hajj_3

8th October 2025, 21:46

There will be a live webinar/presentation about AV2 on Monday 20th October. Presentation by Netflix, Google and Meta: https://aomedia.org/events/live-session-the-future-of-innovation-is-open/

birdie

11th October 2025, 08:15

hajj_3

11th October 2025, 10:25

I'm surprised they didn't compare it to VVC as a 29-33% compression improvement should be better than the heavily patented VVC.

birdie

11th October 2025, 11:40

I'm surprised they didn't compare it to VVC as a 29-33% compression improvement should be better than the heavily patented VVC.

AV2 will be competing with the ECM codec (https://forum.doom9.org/showthread.php?t=185662) that will also be quite a lot better than VVC albeit both will be equally dead in terms of real life applications.

ksec

11th October 2025, 11:50

I'm surprised they didn't compare it to VVC as a 29-33% compression improvement should be better than the heavily patented VVC.

We need more data and considering AOM have over stated their gain and understated VVC in the past.

I am wondering if those 29-33% is compared to which version of AV1 encoder. Theoretically they could have compared to libaom 1.0 and that statement would still be true.

I am just really hoping they get everything right this time around. They said they looked into Decoder complexity, we need to know actual numbers. Fixing AVIF the format, and hopefully Av2 image format as well.

foxyshadis

11th October 2025, 19:42

I gave in. I deleted the old version of AVM 10.0.1 6b2b423, which was working. The new version won't even start in tests. It's still a long way off.
https://www.sendspace.com/file/302x5f

Status of the test encoder has nothing to do with status of the spec.

Fixing AVIF the format, and hopefully Av2 image format as well.

What's wrong with the AVIF (or HEIF) format? It's complex, but it's incredibly capable of far more complex things than storing a basic pic, and ways to exploit that capability have started becoming available this year in libheif and libavif. Meanwhile, if you do just want to store a basic picture, you don't have to care about any of that complexity and it just works, even the structure of the simplified file format is quite basic and straightforward.

For me, one of the most powerful is being able to save layers with a combination of lossy graphics and lossless text/screen content, and it just works.

Jamaika

12th October 2025, 21:08

Status of the test encoder has nothing to do with status of the spec.

What's wrong with the AVIF (or HEIF) format? It's complex, but it's incredibly capable of far more complex things than storing a basic pic, and ways to exploit that capability have started becoming available this year in libheif and libavif. Meanwhile, if you do just want to store a basic picture, you don't have to care about any of that complexity and it just works, even the structure of the simplified file format is quite basic and straightforward.

For me, one of the most powerful is being able to save layers with a combination of lossy graphics and lossless text/screen content, and it just works.
If it works like that, I'll read how it's supposed to work. 20250804
Converting a simple photo without CONFIG_ENABLE_IBC_NAT. This converter works.
https://www.sendspace.com/file/f2ddp2
Converting a simple photo with CONFIG_ENABLE_IBC_NAT. This converter doesn't work.
https://www.sendspace.com/file/hvxny9
So how do I disable the outside, inside function? What is it for? Where can I find it in help?

olduser217

13th October 2025, 03:40

A massive video detailing AV2:

https://www.youtube.com/watch?v=Se8E_SUlU3w

And info from it:

https://videocardz.com/newz/av2-video-codec-delivers-30-lower-bitrate-than-av1-final-spec-due-in-late-2025

https://i.ibb.co/s9LvP6m5/av2.webp

Talked to someone from AOM 2 years ago, they dropped the idea of adding AI module to the base profile, as the cost is too high (the chip area size) while the gain is relatively low.

kurkosdr

14th October 2025, 17:17

AV2 will be competing with the ECM codec (https://forum.doom9.org/showthread.php?t=185662) that will also be quite a lot better than VVC albeit both will be equally dead in terms of real life applications.
What does "both" refer to? AV2 and ECM? AV2 has guaranteed adoption from YouTube at the very least. Google contributed money to develop AV2 (as an AOM member), and they didn't contribute that money to not use it.

Also, Google can afford to support multiple formats since they aren't a broadcaster that has to "simulcast", they already encode 4K HDR streams three times just for the 2160p resolution (VP9 SDR, VP9 HDR, AV1 HDR) and serve you one of the three depending on what your 4K-capable device supports. They can add 1 more encode for AV2 HDR. They make dedicated encoding hardware (https://arstechnica.com/gadgets/2021/04/youtube-is-now-building-its-own-video-transcoding-chips/) to handle encoding, and it will save them more and more bandwidth as more and more devices ship with AV2 hardware decoding.

My point is, lots of people in the industry care about AV2 because their devices will have to support it eventually.

birdie

15th October 2025, 07:37

What does "both" refer to? AV2 and ECM? AV2 has guaranteed adoption from YouTube at the very least. Google contributed money to develop AV2 (as an AOM member), and they didn't contribute that money to not use it.

Also, Google can afford to support multiple formats since they aren't a broadcaster that has to "simulcast", they already encode 4K HDR streams three times just for the 2160p resolution (VP9 SDR, VP9 HDR, AV1 HDR) and serve you one of the three depending on what your 4K-capable device supports. They can add 1 more encode for AV2 HDR. They make dedicated encoding hardware (https://arstechnica.com/gadgets/2021/04/youtube-is-now-building-its-own-video-transcoding-chips/) to handle encoding, and it will save them more and more bandwidth as more and more devices ship with AV2 hardware decoding.

My point is, lots of people in the industry care about AV2 because their devices will have to support it eventually.

I meant VVC and ECM.

AV2 will be heavily pushed by Google, so circa 2030 we'll see a lot of HW implementations.

hajj_3

21st October 2025, 09:33

AVIF 2.0 is coming: https://aomedia.org/blog%20posts/AVIF-at-Five-Powering-a-Faster-Sharper-Web-Experience/

hajj_3

6th November 2025, 21:35

soresu

7th November 2025, 09:39

Talked to someone from AOM 2 years ago, they dropped the idea of adding AI module to the base profile, as the cost is too high (the chip area size) while the gain is relatively low.

Given the emphasis on AI/ML inference hw in modern SoCs you would think that the silicon is already there just waiting to be tapped, like with that end to end ML based Deep Codec or whatever it's called.

soresu

7th November 2025, 09:41

Here is the AV2 presentation by the alliance for open media from 20th october: https://www.youtube.com/watch?v=RUMwMe_2Dqo&t=267s

They said that AV2 has 30-32% better compression than AV1 at 1080p and 38% better at UHD.

Better than I expected I guess.

The question is at what enc/dec computational cost?

soresu

7th November 2025, 09:53

AV2 has guaranteed adoption from YouTube at the very least.

I wouldn't necessarily take that as a given.

We are 7 years into AV1 now, with supposedly in house designed transcoding hardware levied for everything on Youtube now, and yet still many videos are not first transcoded to AV1.

Likewise decoding hw for AV1 should be pretty widespread across the consumer ecosystem at this point and the highly efficient libdav1d exists for the rest.

GIven AV2 will only increase the computational complexity further I would expect it to take quite some time before we see it brought to bear for anything but the most bandwidth intensive videos.

kurkosdr

8th November 2025, 00:55

I wouldn't necessarily take that as a given.

We are 7 years into AV1 now, with supposedly in house designed transcoding hardware levied for everything on Youtube now, and yet still many videos are not first transcoded to AV1.

Likewise decoding hw for AV1 should be pretty widespread across the consumer ecosystem at this point and the highly efficient libdav1d exists for the rest.

GIven AV2 will only increase the computational complexity further I would expect it to take quite some time before we see it brought to bear for anything but the most bandwidth intensive videos.
It will be used for the 2160p resolution for sure, since 2160p is seriously bloating Google's bandwidth costs.

ksec

9th November 2025, 14:26

Here is the AV2 presentation by the alliance for open media from 20th october: https://www.youtube.com/watch?v=RUMwMe_2Dqo&t=267s

They said that AV2 has 30-32% better compression than AV1 at 1080p and 38% better at UHD.

This is finally some glimpse of hope. Lots of signs they learned from their mistakes in AV1. Assuming they actually deliver it. Still no words on computational differences.

Rumbah

9th November 2025, 19:58

They said that the decode complexity should not be more than twice of that of AV1.

oibaf

10th November 2025, 09:59

This is finally some glimpse of hope. Lots of signs they learned from their mistakes in AV1.

What do you mean exactly?
Which mistakes are you referring to, and why do you have hope now?

ksec

10th November 2025, 12:09

What do you mean exactly?
Which mistakes are you referring to, and why do you have hope now?

Roll out schedule, Hardware Design, Complexity, Features and Profile, AVIF and Still image, Conformance and Testing Kit. Lot of other small things from JVET that people take for granted.

benwaggoner

10th November 2025, 19:55

I'm surprised they didn't compare it to VVC as a 29-33% compression improvement should be better than the heavily patented VVC.
I don't know that they consider VVC enough of a competitor that people will be comparing AV2 to it.

If people weren't adopting VVC over AV1, they definitely won't over AV2.

benwaggoner

10th November 2025, 20:04

I wouldn't necessarily take that as a given.

We are 7 years into AV1 now, with supposedly in house designed transcoding hardware levied for everything on Youtube now, and yet still many videos are not first transcoded to AV1.
H.264 is the universal codec, so it makes sense they'd prioritize that over a codec that only a portion of their customer devices can decode. AV1 is also a lot more complex to get to its big compression efficiency advantages.

GIven AV2 will only increase the computational complexity further I would expect it to take quite some time before we see it brought to bear for anything but the most bandwidth intensive videos.
Well, yeah. It generally takes 3-4 years from a video standard being published before there's a significant installed base of players to even do pilot projects with. HEVC was an exception because it enabled 4K and HDR which weren't viable on existing decoders, and were only needed in new devices with 4K and HDR panels anyway.

So even if it is a decade between starting to create a codec an being able to use it broadly, we'll still want a better codec a decade from now. They're long-term investments with eventually huge payoffs.

oibaf

15th November 2025, 19:36

This video looks it was not posted earlier: AV2 Common Test Condition Latest Test Result Update, presented by Ryan Lei, Meta (https://www.youtube.com/watch?v=f0ivgL8vu9w).

benwaggoner

18th November 2025, 18:00

This video looks it was not posted earlier: AV2 Common Test Condition Latest Test Result Update, presented by Ryan Lei, Meta (https://www.youtube.com/watch?v=f0ivgL8vu9w).
Reasonably promising at this point. The v10 results are just hitting the 30% PSNR improvement threshold. v11 are behind those (presumably tuning is still required), but I imagine will catch up at the minimum.

If VVC had gotten "normal" MPEG codec adoption, these numbers wouldn't be enough to get the industry to switch to AV2. But VVC simply hasn't, so it's really HEVC and AV1 that are AV2's competitors in practice.

Note that these benchmarks are all "codec development comparison" tests. So fixed GOP, fixed QP, and really only normative features being used with barely any psychovisual or other scenario-specific tuning.

For actual practical use, the best HEVC and AV1 encoders would handily beat these early AV2 encoder implementations, both in quality @ bitrate and especially quality @ perf. All going well, we'd see some viable encoder implementations and some software decoders in 2017, with hardware decoders in 2028+ products.

Which requires patience, but isn't bad news at all. Each new, more advanced generation, if/when refined psychovisual optimizations are done, often get subjective compression efficiency gains substantially better than what PSNR would predict. I I'd expect our best 2035 AV2 encoders are able to deliver the same quality at half or less the bitrate of today's best AV1 encoders.

All AV2 decoders should be delivered with high quality AFGS1 implementations as well, which means savings for grainy/noisy content should be substantially better than that. We've really not seen significant AV1 FGS use in the wild yet due to a variety of decoder issues, and AFGS1, although the same at the lowest level, is quite a bit better in practice. Most importantly, the grain gets rendered at display resolution, not content resolution. That means grain and thus a lot of perceptual detail will be constant detail irrespective of the encoded stream's resolution. That will be particularly useful for adaptive streaming, as there will be much less visual discontinuity when switching between bitrates/resolutions than there is with 2025 adaptive bitrate implementations.

I expect we'll eventually see some pretty darn good 2160p HDR 24p encodes in the 2-4 Mbps average bitrate range. AFGS1 means that we'll see the biggest savings in the content that need the highest bitrates today.

oibaf

18th November 2025, 18:34

... barely any psychovisual or other scenario-specific tuning...

Having had a look at their plan for the next milestone (v13 (https://gitlab.com/AOMediaCodec/avm/-/milestones/17#tab-issues)), I found this issue interesting: Import changes from libaom (https://gitlab.com/AOMediaCodec/avm/-/issues/570): current AV2 is indeed still missing many thousands commits merged in 5+ years after the fork from aom (AV1).

Since then, many tunings were indeed merged in aom (https://aomedia.googlesource.com/aom/+/refs/heads/main/CHANGELOG) (it would be interesting to quantify the overall improvements with all these).

And it would be equally interesting to check AV2 again after merging them into it (likely a massive change, doable by someone with knowledge of both codebases, I suppose, even if a subset can be applied by a script like explained in the issue).

ksec

22nd November 2025, 13:03

Having had a look at their plan for the next milestone (v13 (https://gitlab.com/AOMediaCodec/avm/-/milestones/17#tab-issues)), I found this issue interesting: Import changes from libaom (https://gitlab.com/AOMediaCodec/avm/-/issues/570): current AV2 is indeed still missing many thousands commits merged in 5+ years after the fork from aom (AV1).

Since then, many tunings were indeed merged in aom (https://aomedia.googlesource.com/aom/+/refs/heads/main/CHANGELOG) (it would be interesting to quantify the overall improvements with all these).

And it would be equally interesting to check AV2 again after merging them into it (likely a massive change, doable by someone with knowledge of both codebases, I suppose, even if a subset can be applied by a script like explained in the issue).

Which is why I said the comparison of AV2 against its anchor point is at least 3-5 years behind. AV1 has had many improvement since, making some of those improvement BDRate not realistic. But I am optimistic this time around. No more flamboyant promise like they did with AV1 and everything seems much more practical .

oibaf

26th November 2025, 09:36

Having had a look at their plan for the next milestone (v13 (https://gitlab.com/AOMediaCodec/avm/-/milestones/17#tab-issues)), I found this issue interesting: Import changes from libaom (https://gitlab.com/AOMediaCodec/avm/-/issues/570): current AV2 is indeed still missing many thousands commits merged in 5+ years after the fork from aom (AV1).

Since then, many tunings were indeed merged in aom (https://aomedia.googlesource.com/aom/+/refs/heads/main/CHANGELOG) (it would be interesting to quantify the overall improvements with all these).

And it would be equally interesting to check AV2 again after merging them into it (likely a massive change, doable by someone with knowledge of both codebases, I suppose, even if a subset can be applied by a script like explained in the issue).

They just closed it:
"There is no plan to take action on this. So, closing as Won't do." :confused:
https://gitlab.com/AOMediaCodec/avm/-/issues/570

Maybe, someone else may be interested in taking it.

Z2697

26th November 2025, 12:31

I think the purpose of AVM is "for research only", indicated by the word Model in its name (just like JM, HM and VTM I suppose).
So while libaom benefits from various tunings because it's trying to be both research and "production ready", AVM is probably not going to need those.

oibaf

21st December 2025, 13:55

AV2 is coming, Sisvel is prepared (https://www.sisvel.com/insights/av2-is-coming-sisvel-is-prepared/)

soresu

23rd December 2025, 16:44

AV2 is coming, Sisvel is prepared (https://www.sisvel.com/insights/av2-is-coming-sisvel-is-prepared/)

It reads more like a "we have been paying attention - but in reality we have no idea what patents we manage are potentially infringed by AV2".

It's even more like a "I don't think anything we currently know about is covered by this, or not enough to make it worth the cost of a court case, so please come and share your patents so we can all make nuisance lawsuits together!"

hajj_3

23rd December 2025, 17:35

It reads more like a "we have been paying attention - but in reality we have no idea what patents we manage are potentially infringed by AV2".

It's even more like a "I don't think anything we currently know about is covered by this, or not enough to make it worth the cost of a court case, so please come and share your patents so we can all make nuisance lawsuits together!"

I doubt it. They probably know of some patents that a violated but want to stay quiet instead of announce them now so that the AOM can't remove those tools from the final version so they can extract money out of companies.

Kurt.noise

25th December 2025, 10:04

Is there any public AV2 decoders yet somewhere, except the AVM one ?

birdie

28th December 2025, 12:06

Is there any public AV2 decoders yet somewhere, except the AVM one ?

The spec has not been finalized yet. Expect third-party encoder/decoders at the end of 2026 at the earliest.

oibaf

31st December 2025, 16:22

It looks like they added a new milestone: https://gitlab.com/AOMediaCodec/avm/-/milestones/18

hajj_3

1st January 2026, 00:42

It looks like they added a new milestone: https://gitlab.com/AOMediaCodec/avm/-/milestones/18

I suspect that v13.0.0 will become the ratified version of AV2, that was released on december 19th and the reason why they haven't announced it is that they are probably doing benchmarks to include in their blog post announcement.

soresu

1st January 2026, 03:42

I suspect that v13.0.0 will become the ratified version of AV2, that was released on december 19th and the reason why they haven't announced it is that they are probably doing benchmarks to include in their blog post announcement.

A bit odd to start work on v14 so early then if they are finished with the research work on AV2.

IMHO someone(s) got an itchy trigger finger and made promises the AOM couldn't realistically keep given the state the project was in at the time.

Their press releases basically stated that they were releasing the actual codec by the end of 2025 - when in reality the reference encoder is not even into beta yet and the spec is nowhere to be seen.

For all the mess MPEG has allowed to happen, AOM could still learn some lessons from their regular meetings that leave little doubt as to what is going on.

modus-ms325c

2nd January 2026, 17:32

IMHO someone(s) got an itchy trigger finger and made promises the AOM couldn't realistically keep given the state the project was in at the time.

Their press releases basically stated that they were releasing the actual codec by the end of 2025 - when in reality the reference encoder is not even into beta yet and the spec is nowhere to be seen.gaslighting. this is what it's called, as a catch-all term for "unintentional lies" or just straight-up deceit by anyone unfortunate enough to even learn what that word even means.

For all the mess MPEG has allowed to happen, AOM could still learn some lessons from their regular meetings that leave little doubt as to what is going on.ok, how about instead of doing, well, that, let alone any kind of self-inspection, or god forbid, self-introspection on what went wrong with trying to promote their oh-so-finished AV2 masterpiece(TM) before they had a chance to pull this crap instead of after the fact, they just so happened to talk down to anyone about how shit VVC licensing really is (https://forum.doom9.org/showthread.php?p=2026447#post2026447).

soresu

2nd January 2026, 17:42

ok, how about instead of doing, well, that, let alone any kind of self-inspection, or god forbid, self-introspection on what went wrong with trying to promote their oh-so-finished AV2 masterpiece(TM), they just so happened to talk down to anyone about how shit VVC licensing really is (https://forum.doom9.org/showthread.php?p=2026447#post2026447).

"For all the mess MPEG has allowed to happen" was I thought a pretty obvios reference to the licensing business that has kneecapped their standards.

I was talking about using recorded meetings so that any interested parties know what is going on at regular intervals during the year instead of having to go through a whole song and dance of contacting people and what not.

MPEG may have screwed the pooch over the licensing, but the meetings part at least works.