Software compromises

September 21, 2008

I have a rather love/hate relationship with software.  I got bit by the bug back in 1982 (might have 1981 - can’t remember now!) with a ZX81 kit (from the UK no less).  Since then I’ve been writing software in a variety of languages: various BASICs, machine code (no, not assembler - straight POKEing HEX codes in to memory by hand), Pascal, Rexx, Perl, PHP, Javascript, CF, Java and lately Groovy, Actionscript and lately a dash of C#. One of the few lessons that’s stuck with me is that the act of writing software includes quite a lot of compromises - build vs buy, “cheap/fast/good” triangles, etc.  I was recently hit with some compromises on a project and it really stuck in my craw (so to speak) so I felt like sharing it here.

I was asked to build a desktop video capture client.  The original project was done as a VB6 project and had some problems, partially in the speed in which the original developer could meet deadlines (not really his fault) and some of the quirks of the system itself.  This was a Windows-only app (obviously, being VB6), and I originally looked at recreating it with C#.NET.  I’ve done a couple of small C# apps, mainly as tests for myself - things slightly above ‘hello world’, but nothing terribly practical.  So, with that in mind, I was a little anxious about it, but gave it a whirl.  After about a day of wrestling with C# Visual Studio Express, Windows Media Encoder SDK and Windows itself, I put it on a shelf.  I’d not made much headway, and if I can’t make progress quickly, I tend to drop something (either to meditate on it, or look at other options, or whatever).  In this case, I looked at building an AIR app.

In 10 hours I had a system that was *far* further along.  It was about 70% of the functionality of the original system, with working video streaming, capture, playback, program scheduling and some other features.  10 hours!  Just getting all the IDEs, SDKs and .NET runtime set up took an hour going the Windows-only route.  Sure, my lack of .NET experience was shining through, but I had *never* built an AIR application before, and had limited Flex experience before that.  To boot, the AIR streams could stream directly to a Red5 server - open source and free.

However, the big kick came in that the default Flash encoder algorithm is simply not that good.  The specific project this is for has to do with live streams - there’s no time to give them to a different offline encoder for later playback.  The default Flash encoder in the AIR system (and in regular browser-based Flash encoder systems) is single-pass only, and in short the client was simply not happy with the quality of the streams.  To be fair much higher bit-rates were, imo, pretty close.  Flash 450k stream quality was a bit better than a Windows Media 250k stream quality, but not much, and not in all circumstances (almost any signifiant motion - people walking - made it worse).

More investigation in to this uncovered a company called ‘On2′ which provides a plugin for the Flash player that would allow for multi-pass encoding, and the live streaming results are phenomenal.  Seeing this software running on justin.tv made us consider Flash again.  The AIR software system was further along, easier to install, cross platform, and pretty small.  Why not use it?  So we gave On2 a call for pricing.  You know when you have to call for pricing it’s going to be bad.  The price quoted was around $12k to get started.  I can’t remember if that was a yearly license fee or a one-time fee.  However, they wanted an extra 50 cents per minute of encoded video - $30 hour.  This completely priced the product - the *only* one that can provide any sort of decent quality for live streaming Flash-based systems - out of consideration.  And this meant we had no viable alternative except to go back to struggling with Windows/VS development.

Adobe seems to have wanted to open up the encoder space to allow for third parties to create their own encoder algorithms.  I’ve seen two names mentioned over and over - on2 and sorenson.  However, only on2 has anything that will run inside the Flash runtime to improve the quality directly in the capture process, rather than requiring external streaming systems.  External systems seem to either preclude liveness, or customized/branded applications, or both.

Adobe’s business decision to do this seems to be really short sighted.  Taking the one-pass quality out of the equation, building AIr or Flex apps to deal with video capture / streaming / manipulation is almost a no-brainer.  Easy to develop for, cross-platform (linux, mac, windows), a growing community and other reasons all seem to make the decision easy.  However, when you factor in the issue of quality, and the *cost* of obtaining that quality, it makes the platform unattractive, or at the very least most of the competitive edge is gone.  *Most* developers out there don’t have millions in VC-backing to afford the latest and greatest toys.  We have budgetary considerations, and from a “TCO” standpoint, right now Windows Media still seems to be the winner.

So, while we started off much further along going the Flash/Adobe route, their decisions to cripple the core encoding functionality for the sake of letting others make money in the encoder space ultimately is forcing me (and probably many others) back to the single-platform Windows world.  Had Adobe put a stronger/better encoder in the core engine, there’d be *very* little (perhaps no?) reason to develop a Windows Media application, unless you were working solely on intranet applications ina Windows-only world.  Instead, they’re sacrificing long-term dominance of this space for short-term profits (I have to assume they’re licensing some plug-in technology to on2 and whoever else wants to cough up).  In the end, they will probably end up losing out in this space (live streaming capture), and Adobe’s Flash capabilities will be sidelined to a second-choice.  Unless perhaps the encoder algorithm market gets some competitive jolt, or the money falls out of it and Adobe builds a quality one in to the base engine in the next year or so.  However, Flash Player 10 is in beta, and an improved encoding algorithm is nowhere on their list of new features.

Argh… had to capture some of those thoughts down here.  Perhaps I’ll come back and elaborate more in the future.

Posted in Uncategorized