or Connect
AVS › AVS Forum › Video Components › Video Download Services & Hardware › Netflix's Digital Supply Chain
New Posts  All Forums:Forum Nav:

Netflix's Digital Supply Chain

post #1 of 12
Thread Starter 
Recently there was a post on the Netflix Tech blog about their Digital Supply chain: How movies get from the studios to a streaming. Attached to the blog post is a video with lots of interesting tidbits. The most interesting one to me is that Netflix needs to generate 120 "downloadables" for the variety of devices, bitrates, audio and captions. I don't think they mean 120 separate encodes since some of the captioning and audio assets sometimes live in their own files. It's still a lot of assets to support the 900+ Netflix enabled devices. There's other interesting tidbits on country-specific metadata and other subjects too.

Here's a link to the video:
http://vimeo.com/52637219
and the blog entry:
http://techblog.netflix.com/2012/12/complexity-in-digital-supply-chain.html?m=1
post #2 of 12
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.
post #3 of 12
Thread Starter 
There was a article at GigaOM about the Netflix post/video and they stated there were 120 encodes created. I asked if that it included other assets or not. Netflix confirmed there are 120 separate encodes created.


http://gigaom.com/video/netflix-encoding/?go_commented=1#comment-1267008
post #4 of 12
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.
post #5 of 12
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.
post #6 of 12
Quote:
Originally Posted by Brian Conrad View Post

I would urge those who want to get a handle on what your can do with Silverlight encoding (which NF uses)...

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:
Quote:
Despite popular belief, Silverlight doesn’t actually feature native support for any particular adaptive streaming technology – Microsoft’s, Netflix’s or Move Networks’ for example. Smooth Streaming support in Silverlight is implemented via the MediaStreamSource API. This API allows developers to implement their own media transport methods (instead of relying on MediaElement‘s native transport methods) while still leveraging Silverlight’s native decoders and renderers.

From the comments:
Quote:
Jake says:
August 21, 2009 at 20:26

this website is great just hope someone intelligent respones before my trail version of netflicks expires, otherwise byby netflicks

Alex Zambelli says:
August 21, 2009 at 22:54

Jake, you’d probably be better off posting a comment at http://blog.netflix.com. Netflix built their own Silverlight player, their own adaptive streaming platform, their own encoder… everything. They’re the only ones who can tell you what’s going on with their player.

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:
Quote:
The Netflix player is similar to Smooth Streaming (they both use Silverlight for the media representation). However, we observed that the former showed some important differences in its rate-adaptation behavior, becoming more aggressive than the latter and aiming to provide the highest possible video quality, even at the expense of additional bitrate changes. Specifically, the Netflix player accumulates a very large buffer (up to few minutes), it downloads large chunks of audio in advance of the video stream, and it occasionally switches to higher bitrates than the avail-bw as long as the playback buffer is almost full. It shares, however, the previous shortcomings of Smooth Streaming.

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.
post #7 of 12
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.
post #8 of 12
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.
post #9 of 12
Quote:
Originally Posted by Brian Conrad View Post

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
post #10 of 12
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.
post #11 of 12
Quote:
Originally Posted by Brian Conrad View Post

Hastings is on the board of directors for Microsoft so it is a bit more than their engineers just picking the platform.

Make that Hastings was on the board. Departed last month.
post #12 of 12
Quote:
Originally Posted by Brian Conrad View Post

Yes and hence I would think they would use the SDK to create that software.

Now who's guessing rolleyes.gif? 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).
New Posts  All Forums:Forum Nav:
  Return Home
AVS › AVS Forum › Video Components › Video Download Services & Hardware › Netflix's Digital Supply Chain