Top-Level Overview of How We Do Our Player

[ke...@blip.tv]

It's probably useful to talk a little bit about how the blip.tv HTML5
player is structured and the reasons for some of those decisions.

From 40,000 feet, our player is a single minified JS file that clocks
in at about 274KB (25K once gzipped). All styling in our player is
inlined JS. We bundle all of our vendors libraries to decrease file
requests and to insure we're the only point of failure for our player
loading. Our vendors include FreeWheel, Comcast, QuantCast, TubeMogul
and ScanScout. We are all learning and figuring out the best way to
handle things.

Our player is seen in the wild in two different scenarios: on user-
hosted pages (embedded) and on blip.tv (hosted). Both scenarios use
the same code base, but invoke the HTML5 player slightly differently.
In an embedded situation, we use <script> tags. We use the DOM in a
rawer fashion on our destination site.

Our player gracefully falls back to Flash in situations where we
cannot play the HTML5 video. (Currently, the Firefox environment is
also one of those situations; we do not have support for Ogg/WebM
yet.) We also have the capabilities to operate our Flash player in a
chromeless mode inside of an HTML5 frame, where we essentially
instruct our Flash component to behave like a <video> tag.

We consciously designed the player with two APIs. One is backwards
compatible with our current Flash player and the other is a bit more
sensible. They are really just one interface with two different
idiosyncratic namespaces. This allows us to hold up our HTML5 player
to the same standard through automated testing as our Flash player.

Hope this helps! If you've got any war stories, feel free to chime in.