Comments on the Alliance for Open Media, or, "Oh Man, What a Day"

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.


Cisco introduces the Thor video codec

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:

"World, Meet Thor – a Project to Hammer Out a Royalty Free Video Codec"

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.


Color Calibrating the W701 under Linux (...and probably the W700, W510, etc too...)

"Whaaaat?" you say, "dispcal works just fine with the W701's built-in calibrator under Linux." Well, it should...

Problem is, the BIOS shuts off the LCD when you close the lid. I've not found a user-exposed LCD or backlight control in Linux, sysfs or otherwise, that does a gosh-darned thing when the lid is closed. I'm not aware of anyone else who's found one either. If someone out there knows of an existing software interface, please let me know!

Until I find the 'correct' software solution, there's an easy hack to make it work:

The W701's lid sensor is on the status led board to the right of the suspend indicator. A stainless steel ruler placed between the hinges blocks the magnet in the base, preventing the lid switch from turning off the LCD. TADA! Dispcal et. al. can do their magic.

(Aluminum and austenitic stainless steel won't work. A magnet has to stick to it. Fortunately the cheapy stainless rulers sold by e.g. Staples and Michaels fit the bill nicely.)


This is the wrong tool, but it feels so right

The little handheld spectrometer I've been using for LED and color matching work, aside from being something of a toy, is intended for lighting applications, that is, for very bright light (e.g., it's rated to be pointed directly into the sun) with a wide field of view. Screen evaluation requires low light sensitivity in a narrow field.

Sometimes two pounds of optical glass is easier and cheaper* than the 'right' tool.

*$19 for two 3" condenser lenses from Anchor Optics. Anchor is awesome.


Design to double precision...

...measure with ruler, mark with Sharpie, cut with utility knife, assemble using foamboard and hot glue.


The most recent project hits a Yak-shaving milestone...

There are so many posts that need to come out of this one...

I ordered a whole bunch of Chinese LED conversion kits. I tried lots of ways to mod them to work on Thinkpads, all of which worked... though many turn out not to work well enough, so don't use the mods on those pages for now :-(

Dissatisfied with all offerings, I designed and have been testing my own LED driver boards....

The LED strips that came with the Chinese kits all had terrible color rendering (low temperature, greenish, or both) on the spiffy AFFS screens the X61T is known for.

...so that's sucked me into the world of spectrometers, reverse engineering the protocols to use them on Linux (oh, yeah, I need to publish that), binning leds by hand with a makeshift integration chamber...

...and then of course all the software needed to take the SPD data from the assembled system and interpret the color data, then plot it, which I just finished today!

That contrast measurement is too low and I know why, the sensor is too close and unbaffled, so it's picking up IPS glow. Time for measurement jig rev 2....


libvpx 1.4.0 ("Indian Runner Duck") officially released

Johann Koenig just posted that the long awaited libvpx 1.4.0 is officially released.

"Much like the Indian Runner Duck, the theme of this release is less bugs, less bloat and more speed...."


Today's WTF Moment: A Competing HEVC Licensing Pool

Had this happened next week, I'd have thought it was an April Fools' joke.

Out of nowhere, a new patent licensing group just announced it has formed a second, competing patent pool for HEVC that is independent of MPEG LA. And they apparently haven't decided what their pricing will be... maybe they'll have a fee structure ready in a few months.

Video on the Net (and let's be clear-- video's future is the Net) already suffers endless technology licensing problems. And the industry's solution is apparently even more licensing.

In case you've been living in a cave, Google has been trying to establish VP9 as a royalty- and strings-free alternative (new version release candidate just out this week!), and NetVC, our own next-next-generation royalty-free video codec, was just conditionally approved as an IETF working group on Tuesday and we'll be submitting our Daala codec as an input to the standardization process. The biggest practical question surrounding both efforts is 'how can you possibly keep up with the MPEG behemoth'?

Apparently all we have to do is stand back and let the dominant players commit suicide while they dance around Schroedinger's Cash Box.


NetVC BoF and a roundup of things IETF

In case folks hadn't heard the good news from IETF92 in Dallas, hums from the NetVC BoF indicated consensus for forming a NetVC working group. It's now up to the IESG to formally approve or nack formation. Should the working group be formally approved, we'll obviously submit Daala as one of the inputs to the development and standardization process.

The articles above are a good summary if a bit overly Daala-centric. It's unlikely that the final codec will be 'Daala', much as the IETF work on Opus drew from our codec CELT, but also drew from other contributors, most notably the SILK codec from Skype. We hope and expect to see substantial input from other participants (such as Cisco and Google).

As a parting mention, any IETF followers or insiders who haven't yet seen ietfmemes are missing their recommended daily allowance of realtime insider process backchannel snark :-)


Daala Blog-Like Update: Bug or feature? [or, the law of Unintentionally Intentional Behaviors]

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.

[continue reading at Xiph.Org....]

Tags: ,


Log in