It's not a strawman after it comes true

[xiphmont]

A few months ago, Cisco announced they would distribute a free and fully licensed h.264 encoder/decoder blob that FOSS projects could use to support h.264. At the same time Mozilla announced we'd use the blob in Firefox. I blogged about it at the time.

That announcement was mostly about WebRTC, but there was plenty of talk about this being another step toward full MP4 playback in Firefox. Moz obviously can't do that without also supporting (and licensing) AAC, the audio half of MP4. AAC was not included in Cisco's h.264 offer, which many people noticed and Brendan confirmed on his blog.

At the end of my blog post about Cisco's plan, I suggested it might influence MPEG licensing:

"In the future, could nearly every legal copy of HEVC come as a binary blob from one Internet source under one cap? I doubt that possibility is something the MPEG LA has considered, and they may consider it now that someone is actually trying to pull it off with H.264."

Woah, damn. Did that just happen with AAC?

After Cisco's h.264 Open h.264 announcement, Via Licensing, which runs the AAC licensing pool, pulled the AAC royalty fee list off their website. Now the old royalty terms (visible here) have been replaced by a new, apparently simplified fee list that eliminates licensing sub-categories, adds a new, larger volume tier and removes all the royalty caps. Did royalty liability for AAC software implementations just become unlimited?

The new page is much shorter than the old page; Perhaps this is just an oversight or an as-yet-incomplete pricing update. Still it would be a bit odd for an organization that exists for the purpose of royalty licensing and collection to publish an inaccurate or incomplete price list.

So, who'd like to do the dirty work of following up in more detail with Via?

[update 2014-01-29]: Janko Roettgers followed up with Via Licensing, he details their response in a Google+ post. The short version is the old categories 'remain available' but 'under the new terms, products must be approved by Via before they can be reported in these categories.' In short, the caps are still there at Via's discretion. That's probably not actually much of a change; I believe Via decided what products qualified for capped pricing before as well.

Comments

Pricing

[steve rogers (from livejournal.com)]

As a non-engineer I'm not sure I understand what you're saying here. Are you saying that AAC used to have a reasonable price cap, but it's now possible for it to become expensive if those who license it felt like making it expensive?

Re: Pricing

[xiphmont.livejournal.com]

I am saying there used to be a yearly price cap and that cap may be gone.

A number of mainstream pundits take free software advocates and projects to task for 'refusing' to implement support for popular but royalty encumbered formats like h.264 and AAC (the basis for MP4 video).

Cisco recently announced what they hoped would be an acceptable workaround that would allow FOSS projects to support h.264 (the video half of MP4 video) as part of breaking a stalemate in the WebRTC standardization process. Essentially they offered to let everyone involved download a single, licensed binary blob from them, and they'd eat the licensing cost. This hack relies on the fact that there's a licensing cap; once Cisco maxes out the yearly cap, they pay nothing additional. The entire net could get their h.264 from Cisco, and after the first <n> copies, the beer flows free.

The Cisco announcement did not include AAC, the audio half of MP4.

if the AAC licensors have indeed moved to remove the caps, that would mean no one can use the same hack to ship AAC and FOSS is once again stuck between a dick move and 'I told you so.'

Re: Pricing

[steve rogers (from livejournal.com)]

Yes thank you. I now understand better about the licensing relationship and the implications of the change.

[some41.livejournal.com]

> can't do that with also supporting
Without?

Didn't the old cap only apply to consumer PC software, so fees for mobile versions were already unlimited?

[xiphmont.livejournal.com]

Yes, without. Fixed.

That might well have been the case for mobile. Or was the difference more between 'hardware' implementations (smartphones in which an implementation could be blown in at will via software are new) and software (which as mentioned could be installed by a user at will?) I don't actually know.

I do know that for the PC, this would be a big change.

And of course phones today are PCs with some phone circuitry on them... :-)

[some41.livejournal.com]

I'm just going by the page that you've linked, and they don't seem to care how the codec is implemented, only what end user product it's used in. And they consider PCs and cell phones to be different things. But I don't know for sure how they interpret their own language.

> I do know that for the PC, this would be a big change.
Yes, the old cap was actually quite small.

Good news for Opus (and everybody)?

[ivan privaci (from livejournal.com)]

Does this help remove excuses for delaying Opus support in some places?

Re: Good news for Opus (and everybody)?

[xiphmont.livejournal.com]

Do you have any specific places in mind? :-)

I don't know how much this it affects Opus adoption; I doubt many people have even noticed the change as yet. I wonder if anyone has even _verified_ the change as yet...

Re: Good news for Opus (and everybody)?

[ivan privaci (from livejournal.com)]

The only "specific places" that were in my mind were Internet Exploder and - maybe - safari (I suspect Apple corp.'s problem goes beyond mere foot-dragging). Possibly also Android, which surprised me a bit by still having no hint of native opus support in their last release.

Assuming Google has ever gotten around to enabling opus support by default in chrom(e|ium), getting MS to join the modern era with .opus support would at least bring browser support fir it up to around 90% (from 50-60% or so, I think?)

Really I'm just assuming (on no specific basis but just my cynical observations of corporate behavior) that proprietary vendors were assuming everyone would just give in and pay off the aac people, perhaps even more so if someone could have pulled off Cisco's trick with it.

Can't really blame them

[(Anonymous)]

Via are trying to make money out of their codec - that is their business model (and H264 for that matter). They will price it as appropriate to make as much money as possible...

...but the pay-for-codec model is going the way of the pay-for ZIP compression program. Saving an extra 5% of bandwidth is now only relevant to telcos - so maybe they should consider paying the bill.

I don't think that there will ever be a successful AAC2 codec.

Re: Can't really blame them

[xiphmont.livejournal.com]

There have been many AAC sequels already; they're all named AAC. In MPEG terminology they're 'profiles' of the original codec, but they're not necessarily all that closely related.

Proprietary codecs are successful by monetary and other narrow metrics, but I agree it's unlikely any will reach ubiquity again. mp3 got there by accident.

(I'd assert most people using mp3 in the early years assumed it was free, and it was the free software folks who cemented its market. By the time the lawsuits started flying it was firmly established. For the most part the people who treated it as free never stopped.)

Flash, Chrome, etc.

[james jensen (from livejournal.com)]

Sounds like this is going to put Adobe, Google and everyone else distributing AAC-capable gratis software in an uncomfortable position. It's one thing to spend a consistent, predictable amount every year on a loss leader; it's quite another to pay for literally every copy of two of the most-downloaded pieces of software out there.

Am I missing something?

Re: Flash, Chrome, etc.

[xiphmont.livejournal.com]

I suspect we're missing a bunch of fine print. We'll see.

Same for HEVC?

[(Anonymous)]

MPEG-LA just announced draft details of their HEVC royalties. They've still got a cap, but it now starts at $25 million per year (I assume it'll rise by about 5% per year like H.264, which is up to about $6.5 million per year I think).

So if Cisco tried to pull the same stunt for HEVC they'd be looking at, what, somewhere over half a billion for the next couple of decades?

They dropped the fees for content (which I could never understand the legal basis of), which I think makes it harder for royalty-free codecs to compete, since it removes some of the ongoing incentive for content distributers to switch or dual encode, and makes it more about ubiquity where they probably feel the have an upper hand.

On the other hand, $25 million a years a lot of money, maybe Google's investment in VP9 just paid for itself?

Re: Same for HEVC?

[xiphmont.livejournal.com]

Charging royalties on the content produced by some patented technology has a long history. Software makers have tried to do the same off and on since commercial software started out in the late 70s/early 80s. For a brief period in the early days, Microsoft even tried to collect royalties on the sale of any program compiled on one of their compilers; they dropped that idea pretty quickly along with most of the industry in general.

Ben

[(Anonymous)]

> the audio half of MP4
More like the audio third. I could have sworn the container format itself was patent-encumbered too (!) But I'm not sure what the licensing status is on that.

I heard for MP4+h.264+AAC the h.264 part was actually the least expensive (which is amazing considering it's the only "worthwhile" one, support notwithstanding), and these fees seem to confirm it.

It's even worse for Blu-Ray playback where video was peanuts compared with the (crappy performing) audio codecs and containers they have to support there.

Re: Ben

[xiphmont.livejournal.com]

You're right that Apple holds a patent or two on the MP4 container, or aspects of it. I'm not actually sure what all they've done with the patents in terms of licensing or leveraging.

That said, the mp4 container isn't all that interesting, so it's hard to think of it as a full third :-)

So that's a yes then?

[(Anonymous)]

Regarding the update: You appear to be selling yourself short here. I realize we won't know for sure until someone actually asks VIA "Do you mind if we distribute your codec to the whole world as a binary plugin for a flat fee" and they say "Hell, no!" (will they even bother to answer the question if it comes from some random nobody? Maybe Mozilla should ask, just to test the waters?) but that response seems more a confirmation of your hypothesis than not.

Discretionary caps is exactly what I'd do if I was an evil patent rent-seeking genius faced with Cisco's workaround, because you don't want to annoy the big corps who actually hit your cap in the course of their business by abolishing them completely and springing a surprise price hike on them.

Re: So that's a yes then?

[xiphmont.livejournal.com]

I apologize missing this comment in the screening queue last week! Sorry about that.

It is indeed possible that the discretionary criteria have changed in the background, and there's just no way to know until someone gets a license request nacked.

Daala Demo #5

[(Anonymous)]

May I inquire for a guesstimate on when the next Daala demo page might be up?
You have some avid fans of this attempted technology leap waiting with bated breath! :D

Re: Daala Demo #5

[xiphmont.livejournal.com]

Daala Demo 5 is coming :-)

Every now and then, coding comes first. Demo 5 is about PVQ, and working on the PVQ code took priority over writing about it. PVQ is one of the parts of Daala that by far has the most unanswered questions, and I wanted to take a shot (along with Jean-Marc) of answering some of them before making a big writeup with the conclusion "we dunno, LOL" :-)

The return of the silent movies

[(Anonymous)]

The return of the silent movies! >:->