Open standards are good. Open codecs are essential. That’s why SD Times supports the efforts of some big players in the industry—most notably Google and the Free Software Foundation—to rally video producers around the WebM (VP8) codec.
H.264, with support from Apple and Microsoft, was thought to be the leading candidate for codec standardization in HTML5, the in-development next iteration of the Web markup language that supports the playing of video in applications. But H.264 is constrained by patents held under the MPEG-LA consortium, and it comes with restrictive fees. So, for now, HTML5 remains codec-agnostic, which does not help to clarify the muddied waters.
Google promises WebM will be open, and several organizations already have joined the effort, including Mozilla, Opera and Adobe. (For now, only Firefox, Opera and Google Chrome browsers support WebM; Microsoft’s Internet Explorer and Apple’s Safari do not.)
At least one critic believes Google’s openness argument is a bit disingenuous; after all, it’s looking to commoditize technology in an area where the competition (Apple) clearly has an advantage, at least for now. For its part, Apple doesn’t mind paying the royalty fees for H.264, because that guarantees that it won’t have to face a “stop ship” injunction because something in the iPad or iPhone violates some patent of which it was unaware.
But no matter. We believe software developers should not have to pay to be able to read or write data, including video, in a specific file format—or to sign a license agreement. Nor should they have to choose between codecs because certain browsers support certain codecs, or dual-encode their videos to play properly on the different supported codecs.
So, if Google, the FSF and others indeed keep WebM an open, unconstrained project, SD Times sees this as technology upon which the industry should standardize. It will benefit developers, who can write applications using video to one specification, and it will benefit application users, who will get a consistent video experience regardless of browser or device.
Mobile ads in the applications
SD Times has been writing about “Ads in the applications” since our very first issue in February 2000. At the time, of course, there were no mobile ads; we were studying the short-lived trend toward embedding advertisements inside desktop software. At the time, we editorialized:
But the bad news is: Your employees are trying to do a job. To protect them, your company doubtlessly stops salespeople at the door and won’t allow them to canvass your busy employees while they’re working. Should embedded advertisers be afforded special privileges and 24×7 access to your staff? Of course not. If you’re developing consumer applications, embedded advertising for your freely distributed software is a good idea, and can provide a valuable source of additional revenue for hot products. But please don’t inflict ads on your enterprise customers because, frankly, they won’t stand for it. Would you?
The world has changed since then. Ads are accepted everywhere an enterprise user goes, including, in many cases, Web applications. There’s no reason why mobile apps should be any different. If it’s a tool that you and your employees need, if embedded ads make it financially viable for the developer and affordable for you, and if the ads aren’t too obnoxious, there’s little to complain about.
And if you’re an enterprise developer or a commercial software writer, well, advertising is the way to go. It seems that customers will put up with both paying for software and seeing ads. If they’re happy, you should be too. As we said in 2000, it’s an ad, ad, ad, ad world.
