Netflix's Digital Supply Chain

Fascinating. It is surprising that their architecture is that messy. So the question is, how or why did it get that way?

In regard to 120 "downloadables" per video, obviously it would be much simpler to support a smaller set of encodes. This would either force device manufacturers to be compatible with those encodes or to simply not offer netflix. In the short term, by supporting devices with custom encodes, netflix will likely draw more customers. On the other hand, in the long run it may not prove beneficial. From the outside I'm unwilling to even hazard a guess.

Hopefully they're making better decisions than with their user interface. The netflix GUIs and website has been getting worse each year. At this point I can't imagine a worse video player or library browsing experience. Despite using netflix nearly everyday, I'm willing to proclaim that the emperor wears no clothes. Perhaps their user interface team is saddled with an equally complicated ecosystem to support.

That's difficult to believe. It seems as if the adaptive bit rate streaming (ABS) players all use the same set of 6-9 AVC video encodes, which include 6 SD ones, and for HD titles, 2 720p encodes and (usually) a 1080p. Now they have to continue to support "legacy", non-ABS players like older BD players and first generation Roku boxes; I don't know how many video encodes those require, but they're all pre-1080p. That recruitment slide show seemed to imply that they have different encodes for TVs (and presumably TV-connected STBs), PCs, phones and tablets.

I don't know. It'd be interesting to know how many distinct hardware platforms they have to generate different encodes for. Having to maintain such a large set of encodes seems totally inelegant.

I would urge those who want to get a handle on what your can do with Silverlight encoding (which NF uses) to visit Microsoft's site and even download their free versions. You can take that HD video of your summer vacation and using a default setting watch how many streams it will generate for different bitrates (good to have a fast computer though). Of course production houses will be using the Pro versions and possibly rolling their own encoder software using the SDK.

http://www.microsoft.com/expression/

I agree 120 different encodes seems a bit overkill.

I'm pretty sure that they don't use IIS Smooth Streaming (not actually a part of Silverlight, but of a multi-media extension to IIS, MS's web server platform). Microsoft's Alex Zambelli denies it in an an old entry in his blog. From the article:
From the comments:
I've scanned this very dense academic technical paper comparing the performance characteristic of three adaptive bit rate streaming technologies, IIS Smooth Streaming, Netflix's system and something called OSMF. From their conclusion:
Their Netflix web player and Window 8 app use some significant elements of Silverlight (and the web player is authored with Silverlight, MS' version of Adobe's Flash suite); I'm not sure how much. I believe that Microsoft, Netflix and several other ABS systems (including the emerging MPEG-DASH standard) are using the fragmented MP4 format, but I don't think that Netflix has used MS' Expressions encoder. They've moved away from whatever they were using to eyeIO's encoding tech in any case.

I don't know how Silverlight became synonymous with Smooth Streaming players--it's this huge suite of multi-media web authoring tools and APIs. Streaming video playback support is just a small part of it.

EDIT: After all this exposition, I re-read your post and note that you didn't say that Netflix is using MS' Smooth Streaming tech, just "Silverlight encoding", which, if taken to mean fMP4, is true. Sorry. Everybody does seem to think that Netflix is using Smooth Streaming, though.

120 encodes is pretty insane but considering pretty much every device out there can do Netflix is makes sense.

Personally if we are talking technical stuff.... I almost would be more interested to know how xbox video works. To me that is the best overall implementation that gives excellent quality and good smoothstreaming experience (really cool how quickly it moves to the 1080p encode and how the ff/rw runs full screen and is as responsive as if it was a bluray playing locally). Almost wish Netflix would just license that tech for their service or xbox comes out with their own streaming subscription using this tech.

The Pro version of the encoder can do MP4. It's even listed in the free version but will tell you that you need to Pro version or MP4. Rather than guessing, do as I did and download the free version and see what it does.

I know that the Expression Encoder can create fMP4 encode sets--it's designed to be used to create encodes for Smooth Streaming. I just don't think that Netflix has ever used it. That blog post by Zambelli that I linked to says that Netflix created their own tool chain for that work. They do use that file format, developed by MS; it's becoming (or has become) an industry standard.
Edited by michaeltscott - 12/22/12 at 1:48pm

Yes and hence I would think they would use the SDK to create that software. That's how these companies work. Hastings is on the board of directors for Microsoft so it is a bit more than their engineers just picking the platform. There is politics involved in this. With a lot of licenses added on a weekly basis one would want an automated system that would need to be updated and tweaked far more often than Expression would ever be tweaked. I never said that Netflix would use Expression just the encoder SDK.

Make that Hastings was on the board. Departed last month.

Now who's guessing ? Zambelli said, "Netflix built their own Silverlight player, their own adaptive streaming platform, their own encoder… everything". I would think that if Netflix was using MS' Expression Encoder SDK he might have mentioned. Given that stream encoding is core technology for Netflix, I can see where they might write everything from the bottom up, perhaps buying OS/machine agnostic encoder code somewhere, though not necessarily MS. Why write an encoder tool chain limited to Windows instead of something which can easily be ported to whatever you want to run it on?

And you're right about them needing the ability to maintain and modify their process and tools at will. I've worked on projects where we had the codebase for the commercial RTOS we were using so that bugs in it could be fixed locally as fast as possible rather than relying on the company which developed it to do it after they'd worked their way through bugs reported by other customers. (Of course, this made upgrading to a new version of the RTOS a major PITA, since we had to roll our fixes and mods into it).