xiphmont

Daala Demo 6: Perceptual Vector Quantization (by J.M. Valin)

Jean-Marc has finished the sixth Daala demo page, this one about PVQ, the foundation of our encoding scheme in both Daala and Opus.

(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!)

Tags: , ,

xiphmont

Intra-Paint: A new Daala demo from Jean-Marc Valin

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 ;-)

Tags: ,

xiphmont

ThinkPad hacking: LED backlight conversion

In case anyone was wondering what I was doing with all the LEDs recently, I've been converting classic Thinkpads with old, dying CCFL backlights to LED. It's a popular mod, and there are plenty of generic DIY backlight kits out there. Unfortunately, most of these kits don't work as-is, and there are no good instructions, walkthroughs, reviews or comparisons of various kits anyway.

I've just had a great deal of fun fixing that. Consider this a beta-test invitation :-)

Also... I touched the white tape. I touched it really quite a lot.

Tags: , , ,

xiphmont

Anyone know the manufacturer of this LED?

I've been working on a backlight retrofit project with some odd and fairly tight spectral output requirements. Specifically, I need a cool-white LED with a very low CIE Y value. Something around x=.3 y=.28 resulting in a purplish/pinkish tinge.

As luck would have it, one of the first engineering samples I ordered from <insert random Chinese Supplier here> as part of a larger kit nailed the requirement perfectly. What luck! I ordered an additional large lot of exactly the same part--- and was sent completely different LEDs the second time around. The combination of language barrier and reluctance to name their own suppliers has meant I've made no progress on tracking more of these suckers down. I have 50. I need about 2000.

Large photomicrographs under the cutCollapse )
Tags:

xiphmont

And then there's this guy.

( You are about to view content that may only be appropriate for adults. )

xiphmont

Presentations, presentations, presentations and slide decks

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:

https://people.xiph.org/~xiphmont/demo/daala/daala-vp9summit-20140606.pdf

Tags: ,

xiphmont

It's not a strawman after it comes true

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.


xiphmont

Libvorbis 1.3.4 released

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.

That's a long way of saying "Xiph.Org is pleased to announce the release of libvorbis 1.3.4..."

No functional changes, but the encoder lib is now a shade over 25% the size it was in the 1.3.3 release.

Tags: ,

xiphmont

Linux eMagic driver update

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).

tl;dr, get the driver here: http://people.xiph.org/~xiphmont/emagic/

Tags: , , ,

xiphmont

Opus 1.1 final release

...and the final 1.1 release lands!

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.)

Tags: ,

You are viewing xiphmont