Entries tagged with xiph

Performance-wise, 1.3 is the biggest Opus update so far.
Several commenters have suggested it should have been named 2.0,
but full interoperability is important, and '2.0' could suggest
we broke compatibility somehow (we haven't).

Opus 1.3 adds full Ambisonics surround support, improves
the built in speech/music detection, and greatly improves low
bitrate performance. Wideband speech now goes down to 9kbps,
narrowband to 5kpbs, and stereo performance improves especially
in the 24-32kbps range.

"AV1 is a new general-purpose video codec developed by the
Alliance for Open Media. The alliance began development of
this new codec using Google's VPX codecs, Cisco's Thor
codec, and Mozilla's/Xiph.Org's Daala codec as starting
point. AV1 leapfrogs the performance of VP9 and HEVC,
making it a next-next-generation codec. The AV1 format is and
will always be royalty-free with a permissive FOSS
license."

I'm about to get an official press release together, but in the meantime, I'm pleased to announce we've released Opus 1.2!

Quoting Jean-Marc Valin, the Opus lead developer:

Opus gets another major upgrade with the release of version 1.2. This release brings quality improvements to both speech and music, while remaining fully compatible with RFC 6716. There are also optimizations, new options, as well as many bug fixes. This Opus 1.2 demo describes a few of the upgrades that users and implementers will care about the most. You can download the code from the Opus website.

Last week, Fraunhofer and Thomson suspended their MP3 patent licensing program because the patents expired. We can finally welcome MP3 into the family of truly Free codecs!

Then came a press push calling MP3 dead. That's dumb. Fraunhofer is only calling MP3 dead to push unwary customers into 'upgrading' to AAC for which they can still charge patent fees.

This is a bit like the family pediatrician telling you that your perfectly healthy child in college is dead-- and solemnly suggesting you have another child immediately. Just to keep making money off of you.

I would call that disingenuous at best.

No, MP3 isn't dead, and it's not pining for any fjords. The money that Thomson and Fraunhofer were previously collecting in patent royalties now stays in your (and everyone else's) bottom line. Don't license something new and unnecessary just to spend more money.

If you really do need something more advanced than MP3, the best alternatives are also open and royalty-free. Vorbis is the mature alternative with 20 years of wide deployment under its belt. Better yet, consider Opus, the world's most advanced officially standardized codec.

That said, the network effects that have kept MP3 dominant for so long just got stronger. Nothing beats its level of interoperability and support. There's no reason to jump off a thoroughbred that’s still increasing its lead.

I've not posted many entries in the past year-- practically none at all in fact. There's something entirely different about coding and writing prose that makes it difficult to shift between one and the other. Nor have I been particularly good (or even acceptably bad) about responding to questions and replies, especially those asking where Daala is, or where Daala is going in the era of AOM.

I assume folks who follow video codecs and digital media have
already noticed the brand new Alliance
for Open Media jointly announced by Amazon, Cisco, Google, Intel,
Microsoft, Mozilla
and Netflix. I expect the list of member companies to grow somewhat
in the near future.

One thing that's come up several times today: People contacting Xiph
to see if we're worried this detracts from the IETF's NETVC codec
effort. The way the aomedia.org website reads right now, it might
sound as if this is competing development. It's not; it's something
quite different and complementary.

Open source codec developers need a place to collaborate on and share
patent analysis in a forum protected by client-attorney privilege,
something the IETF can't provide. AOMedia is to be that forum. I'm
sure some development discussion will happen there, probably quite a
bit in fact, but pooled IP review is the reason it exists.

It's also probably accurate to view the Alliance for Open Media (the
Rebel Alliance?) as part of an industry pushback against the licensing
lunacy made obvious by HEVCAdvance. Dan Rayburn at Streaming Media
reports a third HEVC licensing pool is about to surface. To-date,
we've not yet seen licensing terms on more than half of the known HEVC
patents out there.

In any case, HEVC is becoming rather expensive, and yet increasingly
uncertain licensing-wise. Licensing uncertainty gives responsible
companies the tummy troubles. Some of the largest companies in the
world are seriously considering starting over rather than bet on the
mess...

Is this, at long last, what a tipping point feels like?

Oh, and one more thing--

As of today, just after Microsoft announced its membership in the Open Media Alliance, they also quietly changed the internal development status of Vorbis, Opus, WebM and VP9 to indicate they intend to ship all of the above in the new Windows Edge browser. Cue spooky X-files theme music.

I want to mention this on its own, because it's a big deal, and so that other news items don't steal its thunder: Cisco has begun blogging about their own FOSS video codec project, also being submitted as an initial input to the IETF NetVC video codec working group effort:

Heh. Even an appropriate almost-us-like nutty headline for the post. I approve :-)

In a bit, I'll write more about what's been going on in the video codec realm in general. Folks have especially been asking lots of questions about HEVCAdvance licensing recently. But it's not their moment right now. Bask in the glow of more open development goodness, we'll get to talking about the 'other side' in a bit.

Codec development is often an exercise in tracking down examples of "that's funny... why is it doing that?" The usual hope is that unexpected behaviors spring from a simple bug, and finding bugs is like finding free performance. Fix the bug, and things usually work better.

Often, though, hunting down the 'bug' is a frustrating exercise in finding that the code is not misbehaving at all; it's functioning exactly as designed. Then the question becomes a thornier issue of determining if the design is broken, and if so, how to fix it. If it's fixable. And the fix is worth it.

Before we get into the update itself, yes, the level of magenta in that banner image got away from me just a bit. Then it was just begging for inappropriate abuse of a font...

Ahem.

Hey everyone! I just posted a Daala update that mostly has to do with still image performance improvements (yes, still image in a video codec. Go read it to find out why!). The update includes metric plots showing our improvement on objective metrics over the past year and relative to other codecs. Since objective metrics are only of limited use, there's also side-by-side interactive image comparisons against jpeg, vp8, vp9, x264 and x265.

The update text (and demo code) was originally for a July update, as still image work was mostly in the beginning of the year. That update get held up and hadn't been released officially, though it had been discovered by and discussed at forums like doom9. I regenerated the metrics and image runs to use latest versions of all the codecs involved (only Daala and x265 improved) for this official better-late-than-never progress report!

(I suppose this also means we've finally settled on what the acronym 'PVQ' stands for: Perceptual Vector Quantization. It's based on, and expanded from, an older technique called Pyramid Vector Quantization, and we'd kept using 'PVQ' for years even though our encoding space was actually spherical. I'd suggested we call it 'Pspherical Vector Quantization' with a silent P so that we could keep the acronym, and that name appears in some of my slide decks. Don't get confused, it's all the same thing!)

Intra paint is not a technique that's part of the original Daala plan and, as of right now, we're not currently using it in Daala. Jean-Marc envisioned it as a simpler, potentially more effective replacement for intra-prediction. That didn't quite work out-- but it has useful and visually pleasing qualities that, of all things, make it an interesting postprocessing filter, especially for deringing.

Several people have said 'that should be an Instagram filter!' I'm sure Facebook could shake a few million loose for us to make that happen ;-)

The spring 'conference tour' season is finally coming to a close. I'm a bit surprised by the number of people who have asked for my slide decks. Well, slide deck actually, since of course I mostly reused the same slides across the talks this spring.

In any case, I 've posted the latest iteration (from my presentation at the just-finished Google VP9 Summit) for anyone who's interested:

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.

Nathan Froyd at Mozilla noticed something odd in the libvorbis sourcebase. Codebook 'length lists' only use integers in the range of 0 to 32. Well, worse than integers, actually, longs. And the lengthlists are big; the static data comprises the bulk of libvorbisenc.

In the earliest days of Vorbis development 15 years ago, codebooks were constructed differently and the lengthlists were quite small. Longs still weren't necessary, but the wasted space was negligible. When the coding strategy shifted and these lists became much larger, no one caught the wasted space. The vast majority of optimization was always for speed, not space. The only concentrated effort in trimming Vorbis library size down over the past decade had been in the decoder.

But now browsers need to ship encoders, and size matters. Add that to 64 bit taking over (and doubling the wasted space in the lengthlists), someone finally noticed the oversight.

Every now and then I'm reminded I'm not the last emi2|6 or 6|2m user left in the world-- apparently Debian just recently made some of the changes that broke the eMagic drivers on other distros years ago and I've been getting mail about it again.

Background: The eMagic emi2|6 and 6|2m firmware loaders shipped with the Linux kernel have been broken for many years. Different distros have had them on life support with an inconsistent array of minor patches, but they've got a couple problems across the lot: races in the loader, an incorrect memory target, deadlocking all of USB with synchronous firmware requests in probe(), and the fact that the bitstream.fw file being shipped for the 6|2m is the wrong file. Apparently, someone accidentally substituted the 2|6 version of the file in a code cleanup years ago, and so even if you get the 6|2m loader to work, it crashes the device because it uploads the wrong thing.

Oh, and Linux is apparently shipping a buggy, early version of the firmware without 96kHz support. Even if you don't care about 96kHz for audio production, and you probably shouldn't, the extra frequency range makes these guys a lot more useful as software oscilloscopes.

I've maintained a working version of the driver with updated firmware for the past several years, but getting it into the official kernel always stalled on 'wait, do you have permission from eMagic to use this firmware?' Unfortunately a) Apple bought eMagic and discontinued all their hardware products more than a decade ago, b) to my knowledge, no one ever had explicit permission to use the firmware currently being shipped either. I have no real interest in having a battle over firmware licensing, so my fixes continue to be my own. If Apple turns out to care, I'll pull them down, but I doubt that will happen. I don't think Apple remembers this device even exists. Seriously, they're Bondi Blue. That's soooo late-90's.

Anyway, here's my latest, updated, out-of-kernel firmware loader with the last firmware release form eMagic. It works properly on 2.6.x and 3.x.x kernels for both the emi2|6 and emi6|2m. It replaces the old firmware and two kernel modules with new firmware and a single unified firmware loader module name emi.ko. All new! Such shiny. Wow.

If you have kernel module build dependencies installed, it should be as easy as untarring as root, make, and make install. I also included a 'make remove-old' target to clean out the old driver and avoid any conflicts. It just removes the old modules and firmware files; obviously that might make a packaging system a little pissy (and you'd probably have to re-run it on each kernel update).

The release also features an extensive demo page that describes and shows off the improvements in 1.1 in detail. (The page will look familiar to those who have been following over the past few months; it's an updated and expanded version of the demo for last July's beta test release.)