Reflections on H.264 and Silverlight from a week at Stanford

All’s been quite on the Streaming Learning Center front as I spent the last week teaching several courses on streaming media production and encoding at the lovely Stanford Campus at Palo Alto. Other than a quick sneak peak at the new Final Cut Studio, which you can read about here, it was pretty much full immersion into the streaming world from a user’s perspective. This led to several conclusions about the future of streaming video and Microsoft Silverlight that I thought I would share.

The first observation came to me when I was explaining low level H.264 encoding parameters to the class – specifically, that many of the students would never really need to know these, or VP6 or WMV encoding parameters, at least not for much longer. This related to multiple trends.

The emergence of User Generated Video (UGC) and Online Video Platform (OVP) vendors as streaming providers for small to medium sized companies.

Five years ago, small to mid-sized companies who wanted to stream video from their web sites needed to encode the video, create a player and hope that whichever site they served it from could handle the hoped for high volume of viewers. They also had to chase eyeballs on their own.

Today, a small company in the same position should just upload the video to YouTube or Vimeo, or, for better service and analytics, OVP vendors like Brightcove, Ooyala and Sorenson. Then they’ll use codes provided by these vendors to embed the videos in their own web site, like I do for the videos on Streaminglearningcenter.com (for background on Online Video Platforms, see  Choosing an Online Video Platform).

If you go this route, you won’t even know what format your vendor is using, and you probably won’t care, so long as the video looks good and plays back in the Flash player virtually all of these technologies use. You’ll get a better player than you could produce yourself, complete with full screen options, embed codes, email links, and a better delivery network than your local ISP. If you opt to upload to multiple UGC sites, like blip.tv, YouTube, Vimeo and Google Video – and why wouldn’t you? – they can even help get more eyeballs for your videos. Either way, you won’t have to know the optimal setting for key frames, B-frames or reference frames, or how to create a player, you’ll simply entrust your service provider to set them for you.

The emergence of H.264 as the de facto standard

Codec specific knowledge will also become less valuable as the world inevitably turns to H.264. Five years ago, a compressionist’s toolkit needed to include a working knowledge of Windows Media, Real Video, Sorenson Video 3 and MPEG-4, along with an eye out for an emerging standard called H.264. Today, it’s VP6, which essentially has 2 relevant controls (VP6-E/S), Windows Media, and H.264. In two years, unless MPEG-LA totally hoses the royalty structure, most new encoding will be almost exclusively H.264.

Why, you say? Because it’s a joint standard adapted by the International Telecommunications Union and International Standards Organization, which together helps directs the standards adapted by the cellular, video, computer and consumer electronics market places. Obviously, it’s also been adapted by Apple, Adobe and Microsoft.

Looking forward, if video is critical to how you market, sell or support your product, or how you train or communicate with employees and partners, you’re going to need to consider a three or four screen strategy, encompassing cellular, computer, consumer electronics and portable players like iPods. The only compression technology that will work on all of these going forward will be H.264. So, if you’re serious about streaming video, that’s the codec you’ll need to adapt.

Once H.264 becomes the only truly relevant codec, bit-stream standards will coalesce, templates in encoding tools will adhere to them more closely and producing for any of the four screens will be as complicated as picking a target and pressing the encode button. Sure, there will be some variation in encoding parameters, but fewer and fewer producers will care about them.

The emergence of Cloud Encoding as a viable encoding alternative for large companies

On its face, the concept of cloud encoding companies sounds kind of funky – take two hours to upload a one GB raw video file and then start encoding? But then you realize that this is exactly the paradigm used by YouTube, Vimeo and multiple other sites UGC and OVP sites, and it certainly hasn’t held them back. You can also look forward and assume that in two or three years, broadband transmission speeds will approach the speed we loved on our LANs back in the late ‘90s, and that file uploading time will drop precipitously (for more on Cloud Encoding, see Encoding in a Cloud).

As more and more companies store their digital assets in the cloud, at least the re-encoding of these files won’t take a re-upload – just a very high speed transfer from one drive array to another. Since one of the key value propositions of cloud encoding is the transport of encoded files to key distribution partners like Hulu and Brightcove, you would expect more and more of these outlets to be served via template, making the bit-level codec knowledge unimportant for their customers.

Today, to utilize a cloud encoding service, you need to know quit a bit about levels and profiles and entropy encoding. In two or three years, as standard targets coalesce, it will be much less so.

Boosting Data Rates Cure All Ills

Back in the bad old days of streaming video, producing at 40 kbps for display over 56 kbps modems had little, if any, margin for error. You had to shoot, edit and encode to perfection to produce even moderately watchable video. Any error at any phase reduced quality to a blocky, streaky mess.

Today, ESPN streams soccer highlights from their television show at 576×324@700 kbps (video only) and quality looks great. Granted, no one watches soccer highlights, but you get the idea. To produce this video, ESPN uses their high motion TV feed, not a Quaalude-like, motion-limited streaming version. And, they’re using VP6, not H.264, so can boost quality even further simply by moving to H.264 (for more on ESPN, see Details of ESPNs new higher resolution VP6 files).

Don’t get me wrong, there’s still a lot of bad streaming video out there, folks forgetting to deinterlace, producing at incorrect aspect ratios, backgrounds that shimmer and text that’s too small or degraded and unreadable. But if you’re distributing at reasonable data rates, producing for streaming has distilled down from an intensive one month course to a two or three day seminar, shorter if you already know how to white balance a camera and light a scene. In three years, producing for streaming will be no different than producing for television or DVD.

What’s this all mean?

  • If you’re a small to mid-size company, or a consultant to same, you have to strongly consider UGC or OVP service providers over a roll your own solution.
  • If you’re developing streaming production courses, reflect these new realities into your curriculum. Over the next two to three years, the focus has to shift from how to produce streaming media into how to use it most effectively.
  • If you’re planning out your career, either inside an organization or as a consultant, understand that the value of understanding deep level H.264 encoding parameters will peak in 2010 or 2011, then quickly decline. Perhaps another technology will take its place, but perhaps not. Not a lot of folks out there making big dollars telling companies how to produce MPEG-2 for DVDs.

Next up, deep thoughts on Silverlight

About Jan Ozer

I help companies train new technical hires in streaming media-related positions; I also help companies optimize their codec selections and encoding stacks, and evaluate new encoders and codecs.

Check Also

Tuning for Metrics: What About VMAF and VP9?

If you’re comparing codecs with video quality metrics, you should consider tuning for that metric. …

Leave a Reply

Your email address will not be published. Required fields are marked *