Tuesday, September 27, 2005

Google Video: Pragmatism at work

I've been following the news about Google switching to Flash Video lately and I am watching with interest their technical implementation of it. While I can mostly only make assumptions some things are interesting.

Google loves Open Source solutions, the cost savings for them are certainly immense. The original implementation of Google Video was using a custom plugin which was based on VLC. VLC in itself is heavily lending code from the ffmpeg project to decode and encode a number of video streams, an effort originally driven by Fabrice Bellard, while most of the real interesting stuff is now done by Michael Niedermayer. ffmpeg incidentally has support for Flash 7 video, supporting the .FLV and .SWF file formats. So the step from going from a VLC based solution to using FLV was probably a small one. At least on the encoding and other server side tasks.

What Google was really lacking with the VLC plugin is in my opinion penetration and a stable client. I tried the VLC plugin and ran into some minor problems on some machines, making me think it would have taken major engineering efforts to make it really stable (granted the Flash Player has its problems too, although more and more problems are fixed as we go along). IMO these are probably the main two reasons Google picked Flash. I do not think that porting the VLC plugin to Mac or Linux would have been such a big deal since the NetScape plugin API is supported on all of them.

Another small issue could have been the license fees which come with encoding MPEG-4 and MPEG-2 streams. Google did not use these format and actively disabled handling of these codecs. Still, the source code for encoding with non patent encumbered file formats is pretty much shared and intermixed with the MPEG-4 and MPEG-2 code, and so probably legally questionable in some countries. Do take my word for it though, this is just an assumption.

There are more reasons though why using Flash Video makes sense for such a large undertaking I think. One of these is that the .FLV file format is by design using the KISS (Keep it simple stupid) approach. It's neither offering the high fidelity or the flexibility file formats like QuickTime or Windows Media offer. But it does what it does well and that is playing back simple video streams with some meta information. In fact it's so simple that was able to write a perl script in less than 20 minutes which determines the length of a .FLV file, not having touched Perl for a really long time. Some customer had troubles interpreting the public FLV file format specification, so this helped them tremendously, they ported it to Java though for performance reasons. ;-) With some simple changes this can be modified to do splitting, merging and many other tasks.

As to Google not using the Flash Media Server, I got to give them some slack. Their whole backbone is probably based on serving HTTP streams, so not handling RTP at this early stage makes somehow sense. I hope though that at some point they'll feel more comfortable with Flash and see the benefits of going RTP once more complex client experiences are planned. On my side I would love to see Google Mail offering the ability to record and view video messages and Google Talk could easily be integrated into that experience also. Flash has everything you need to do so, on most of the common platforms. Certainly on more platforms that are currently supported by Google Earth and Google Desktop ;-) And new ones will be added too...

13 Comments:

video is probably the most important reason i'm into flash these days, so I was v glad to see jd's post over the weekend about google's move to flv.

I had published earlier that "with this release, Macromedia (or rather Adobe) positions itself, and the FLV format (together with the Flash Media Server), as (arguably) the most compelling stage for web video"; with all the options opened to google, choosing flv, just as you point to here, underscores maturity/importance/benefits of the technology... truly exciting, and you bet flash/video enthusiasts would be watching what other uses they put it to

btw, thanks for sharing the perl script... now back to the joys of hackery :)

I wouldn't be surprised if the reason google isn't using flashcom (flash media server whatever), is the PRICE. Say they needed 100 servers, each supporting high bandwidth. 100 unlimited license would cost $3,000,000 per year. And I don't think 100 servers would be unreasonable for google. (Various sources say google has somewhere between 40,000 and 100,000 servers).

I'm sure macromedia does high volume discounts, but even if they gave 2/3rd off the price, that's still a million a year. Whereas progressive download has no associated licensing costs.

The "Maximum Data Rate" option has inherent limitations depending to what the codec can do. Once the codec is pushed to its limits in the amount of data it will discard, the data cannot be squeezed any further. This is the case for all codecs in all formats.

Full PAL-resolution 720x576 at modem rates is not a reasonable expectation by any extent of the imagination.

Just wondering if you'd be interested in bloging / podcasting about Matrixstream's cutting edge video on demand and IPTV Technology ( TV over broadband ). This is a technology that allows the consumer to receive a potential for unlimited VOD / IPTV content up to 1080P in H.264 codec over any broadband connection on a PC Player or set top box for TV ( IMX1020 1080P High definition STB - the world's first 1080P H.264 STB ) If you'd like to see pictures and video's of the this new STB you can go to www.matrixstream.com/presskit . Let us know if your interested.