In reading Ars Technica’s lengthy, thorough review of Apple’s new Snow Leopard, I noticed the addition of screen recording to QuickTime. The screenshots indicate that it is configurable for “medium” and “high” quality. Naturally, I bring this up because I wonder what format the video is saved in. QuickTime’s extensive suite of default video codecs does not include a lossless, screen video-oriented codec (per my recollection). And since the feature is out there, people are going to expect FFmpeg and all of its descendant apps to be able to transcode it.

I am greatly anticipating learning more about how this technology works: Video appears in paper magazines. Copies of Entertainment Weekly (a U.S. entertainment magazine) will have small, presumably flexible screens that are supposed to be able to store 40 minutes of video. The magazines are slated to go on sale in Los Angeles and New York next month. With any luck, San Francisco (which I am near) may see a few as well.

The BBC article reports that the underlying chip technology is supposed to be similar to the stuff found in singing greeting cards. That sounds like an oversimplification. But the article also names the tech supplier– Americhip, the self-proclaimed leader in multisensory marketing. They have a YouTube channel with demos of this and related technology.

Have you heard of Sun’s JavaFX? It’s due out later this year and is allegedly positioned to compete in the RIA space. It might be pertinent to mention that I work on a competing technology. Anyway, the reason I bring this up is that I recently learned that On2 is reported to be supplying JavaFX with video codec technology. According to “Sun Adds Comprehensive Video Capabilities to Ubiquitous Java Platform with On2 Technologies,” Sun licensed On2’s “TrueMotion” codec. I’m not entirely sure what codec they’re talking about and I can’t quite find any solid details. On2’s site seems to classify TrueMotion as encompassing both VP6 and VP7. I’m always surprised to hear the name TrueMotion since I thought that went away after the Duck Corporation morphed into On2. But the VP* series seems to be interchangeable with TrueMotion, just for extra confusion.

Who knows? Maybe they actually are using the classic Duck TrueMotion video codec in JavaFX.

Curiously, there is no word on what JavaFX will use for audio. Maybe logarithmic PCM in au/snd files?

I still read the IMDb Studio Briefing everyday, though it gets a little discouraging. I sometimes wonder if there will ever be anymore interesting multimedia tech news. I should have more faith: New Movie Media Devices Predicted. Really, the story here is that IBM has developed a new, giant capacity yet very small storage method. This is one of those curious situations where they don’t mention how large capacities can possibly reach but instead express the capability in terms of how much media the thing might theoretically hold. It’s left as an exercise to the reader to decide what the average size of a ’song’ or ‘movie’ might be and compute from there.

Remember the days when CD-ROM storage capacities were expressed in terms of how many printed documents it could hold? Later, the benchmark was number of pictures, then songs. Now it’s movies. This article cites that a device built around the memory could hold the 3500 movies or 1/2 million songs. Thus, the average movie is ~140 times larger than the average song.

The weirdest aspect of the articles floating around is that the hypothetical device would come with 3500 movies prepackaged and the consumer would purchase codes to activate individual movies.

Given recent media consumption trends, there’s little reason to doubt this strategy.

I’m reading fluffy press releases today about how Sun is going to work towards developing an open video codec: Sun Tackles Video Codec. The article is short on substance which is generally what earns this article a spot the Multimedia PressWatch category of this blog. Something about an Open Media Stack (OMS), perhaps correlated somehow to Open Media Commons (not to be confused with Open Media Now!).

It’s hard to find anything about this initiative that’s not a rehashed press release. But this Sun blog seems to have the most authoritative information, abstract though it may be. They present a fascinating design approach: Rather than evaluate algorithmic techniques based on their performance, evaluate them based on their legal status.

Good luck to them. Here’s a Wiki page to track it.

Google has unveiled their mighty Android platform SDK today. It apparently based uses that phone-based flavor of Java. An ergonomic Eclipse-based development environment and a software emulator are both provided for your experimentation.

That’s nice. But let’s cut to what really matters — multimedia. The SDK specifies the Media API along with its MediaPlayer and MediaRecorder APIs. According to the AudioEncoder class, audio can be encoded to AMR-NB. The VideoEncoder class specifies H.263, H.264, and MPEG-4 SP. All pretty standard for a mobile application, I suppose.

Who handles the multimedia heavy lifting? Vitor noticed this press release and associated fluffy overview from PacketVideo

It’s Java, though, and that means obfuscated Java bytecode programs. Time for a renaissance for my Java de-obfuscator?

I honestly do not understand much about Google’s new Android platform. But if I gather correctly from the surrounding hype and press releases, it’s the answer to all of my prayers and will make every single one of my dreams come true.

If you’re like me (and, let’s face it, if you read this blog then you probably are), you are interested in the multimedia features of this proposed platform.

The literature that I have perused thus far has not made any remarkable claims with respect to multimedia capabilities amidst all the other wish-granting facets of the phone framework. The above picture, which seems to be the mascot image, specifically sports that ubiquitous symbol of multimedia playback — the rightward-facing arrow in a circle.

Since “open source” is a key selling point of this platform, what are they going to use for a general multimedia backend? I can hardly imagine.

Today, Microsoft released some framework for delivering rich internet applications called Silverlight. One of its larger selling points is the ability to stream HD-quality multimedia over the internet. Naturally, I wonder what codecs the system uses. Various press releases play up the VC-1 codec, which of course only pertains to video. I can only assume that WMA3 would be a standard audio codec, and likely WMA2.

But is that all? I started asking this question after I wondered how or if someone could possibly create a Silverlight YouTube clone. The secret to YouTube’s success is, of course, free software. The site runs FFmpeg and MEncoder (see my previous post on this matter) on top of free operating systems and web servers (and I read a forum post somewhere that alleges that Python scripts schedule the multimedia conversion jobs). Sure, you could build the same kind of site with purely Microsoft OSes and multimedia conversion software, but it would cost lots of money in software licenses. This is money that doesn’t need to be spent in, e.g., YouTube’s case and can go towards expanding the hardware infrastructure or lining executive pockets.

Maybe it will be possible to build a Silverlight-based YouTube after all. Here’s a post in a Silverlight forum that describes what codecs Silverlight is alleged to support: On the video side, there is WMV1, WMV2, WMV3, WMVA, and something called WMVC1 (not a proper FourCC): Windows Media Video Advanced Profile. For audio, the post lists WMA 1, 2, and 3, and MP3. Free software encoding support for MP3 is quite abundant. FFmpeg also has support for encoding WMA2. Out of that list of video codecs, FFmpeg can encode WMV7 and 8 (no XIntra8-type frames, of course, but the encoded streams are still compliant).

As is my custom, I have started a MultimediaWiki page tracking what is known about the multimedia formats supported in Microsoft Silverlight. It would be nice to put together a simple Silverlight platform to empirically test the capabilities. I just can’t get past thinking that Silverlight should also support raw PCM, though that’s not as sexy as MP3 for mentioning in a press release. Fairness dictates I should do the same for Adobe’s Flash Player (Silverlight’s obvious competitor), so I have started an appropriate MultimediaWiki page on that topic.

Meanwhile, there’s that Moonlight project offshoot from the Mono Project that is supposed to provide Linux support for the new hotness that is Silverlight. For some reason, the meme going around today is that MS Silverlight is officially out, and Linux has 100% perfect support (or is right around the corner). My cursory investigation leads me to believe that this is not the case. I have read stuff about the Silverlight install for Linux being a one-click affair. I have some direct experience with that type of goal so I am a tad dubious. My guess is that the one-click thing is supposed to be reliable for SuSE Linux (Microsoft partner Novell’s distribution) and hopefully adaptable, with modifications, to other distros. But based on the official status page, it’s not quite there.

But thinking about my primary obsession, multimedia codecs– how will Moonlight cope with decoding the aforementioned formats? The project status page recommends developers and early adopters download and install a particular SVN revision of FFmpeg. That can’t be relied upon to decode all the formats called for above. I have read some rumblings about how Microsoft will release binary codecs that will only be allowed to run with browser plugins. So there’s something to look forward in the binary-supporting components of the free Linux multimedia players.

I should probably mention that I help develop a program that operates in a similar space as Silverlight.

This article in IMDb’s Studio Briefing was the first exposure I have had to the British Broadcasting Corporation’s initiative called iPlayer: BBC Chief Says New Software Moves TV Into a New Age. This is the official page (iPlayer is formerly known as IMP), and here’s Wikipedia’s treatment.

BBC’s player client allows users to download recent BBC shows and view them locally for a limited period of time. Any multimedia hacker who hears ‘BBC’ likely thinks of the Dirac video codec. There is no sign of the codec in any of the literature. Indeed, the container, codec, transport, and DRM capabilities all appear to be based on Windows Media technologies. Further, the client distributes content via a P2P protocol. I suppose this is a natural outgrowth of such a community-owned entity as the BBC.

The official iPlayer homepage links to a message board for the program beta. The board is closed now but the latest activity was from… February… May… even July? Oh wait, these messages are from 2006. The BBC is not known to be the most efficient or competitive enterprise in the broadcast market. So it is not a big surprise to see how gradually this project has progressed.

Presumably, subjects under the BBC’s jurisdiction will express the most interest in this media client. I wonder if foreigners will be able to use it as well? There was much consternation on the message board regarding the limitations of the service, e.g., not being able to sync the downloaded content to such portable devices as the Apple iPod and Sony PSP.

Does the BBC publish any content that would even make any hacking endeavors worthwhile? (Not in my viewing experience…)

IMDb reports: High-Definition Movies Coming to Hotel Rooms. The story says that the capability will be provided by an outfit named nSTREAMS; they presently produce all kinds of large boxes that provide multimedia entertainment to hotels, hospitals, schools, and karaoke bars. I don’t see any boxes on their website that specifically tout HD support, but they must be coming soon.

I gained a small interest in these hotel-based entertainment solutions just recently when I came across a thorough investigation of something called the Famicombox, apparently a pay-per-play NES solution installed in hotel rooms a long time ago. These systems never made it to the U.S., but there were successors at least in the N64 generation and I believe for the SNES as well. I think PlayStation might have gotten in on the hotel action as well.