'How This Product Manager Anticipated Customer Needs with a Revolutionary Streaming Solution'

Yeah, that's a great question. So, um, I talked a little bit about Google a little while ago. Um, several years ago, uh, there was, uh, there was a, a new, um, streaming manifest, uh, type that was coming on the scene called Dash. Um, and with Dash, uh, it, it, it allowed, um, it allowed you to combine. Uh, DRM, uh, protection schemes into a single manifest type. And Dash, uh, and so we call that, we call that common encryption and, and allowed to use uh Google Wide Vine and Microsoft uh um Play Ready into one manifest type. And, and that was, that was, that was a big win because it meant that you didn't have to, you didn't have to publish two different kinds of manifests anymore. So Microsoft has a manifest type called smooth streaming and then um Dash is, is, is yet another manifest type. And then Apple has their own called HLS. Um, so there were, you know, there were 3 manifest types that we, that we were supporting. Dash decided, hey, we, we can do this thing called a common encryption. As long as you follow this encryption standard, you can, we can support Play Ready and we can support uh Wine in this, in this one manifest. And yeah, what that kind of meant is that we didn't need to use Microsoft smooth streaming manifest type anymore. And what that means ultimately for, for, uh, for, you know, guys like me is, hey, I don't have to, I don't have to package this, this extra manifest type, um, and what it meant for customers is that they could, they could reduce their storage um of, of uh content by 3. and so, You know, that that's, that's all well and good, right? Like, so that's, that's a great feature and I identified that we needed we needed to have that uh capability. We needed to, to provide a a feature for common encryption. But we didn't have a method of, uh, we didn't have a tool that would package uh dash with common encryption. Um. And so I started looking around for tools that, that might be able to do this. Um, and I reached out to Comcast uh in Denver, and I found that they were using um a tool called Unified Packageger. And I researched Unified Packageger and found that, that they did support common encryption, um, and So I designed a, I basically wrote up a high-level spec saying, hey, let's, let's build a new service called Stream Packager. Um, it will produce dash with, with, with wide vine and uh Play Ready, uh encryption in it. Um, and we can offer this as a product to our customers. Um. And presented this to my uh VP and I presented to the architect of that team. Um, they thought, hey, this is a great idea, we really need to build this. Um, and then the next quarter, we, uh, you know, they, they gave us some resources, we assembled the team, and we built that stream packager service. It took about 3 months to build it. Um, but we built that service and we launched it, um, and we ended up you know, starting to migrate, you know, the lion's share of our customers over to that, um, that service.

Um, you know, it was actually a pretty easy sell, um, you know, when When you have, when you have a, a new technology like, like Dash and common encryption come on the scene, in, in the online video circles, you know, there are early adopters and then there are followers, right? And seldom were we at Comcast early adopters or leaders in our space. Um, and, you know, we, we knew that Google was gonna be supporting common encryption. We knew that Microsoft was on board with it. We knew that kind of the big industry players were, were Backing, we're backing this effort. Um, and, and we knew that it was, was going to become the standard. I mean, it was, it was obvious the writing was on the wall. Um, we just need somebody to, you know, kind of point it out and wave their hand and say, hey, we need to be doing this. It was, it was kind of a no-brainer.

Yeah.

Well, so, so hidden, hidden in the implementation, um, were serious cost savings for our operational side. Um, so the way, the way that content, the way that we were processing uh content for packaging and DR protection was, was complicated and slow. So when When you're, when, when we're packaging content in the, in, in the, the, the way before the stream packager service, uh, what, what happened is we would encode videos like a ladder of, of MP4s of different bit rates and resolutions, and then we would copy those files onto a Windows server, OK? And that Windows server um would add the uh the IVine DRM protection and the play Ready DRM protection to, to those manifests. Now, imagine if you have a 2 hour long video and you need to copy 8 different versions of that video onto your Windows server over the network and then package them and then DRM protect them. So the just the copying alone of those files can take hours, depending on how large they are. They could be many gigabytes. Um, copy those files over to your Windows Server, pack. Perfect. And then copy them all again out to a CDN for playback. Um, the, the win that we had with the stream packager service was that we could place that on top of a Linux NFS mount, um, that our encoding, our encoding service, our encoding, um, product was using. So our encoding product, basically what we would do is we would ingest the movie and it let's say it would be 60 gigabytes. We would ingest that into an NFS mount. Our encoding product was a Linux-based product that could mount that NFS directory and read and write directly over the NFS map. Now, there's no, there's no moving of files there. The files just stay at rest. So it can read, read the source file and then write the renditions out directly to, you know, the same directory. Um, and then what I wanted to do was, was build a packaging service that could also read directly from the NFS mount and then write the files right back to the NFS mount. So no moving of the files, so it was operational savings. OK. So Um,

Um, yeah, good question. So, For, for a given for a given movie, um. The copying the renditions would take on our local network would take anywhere from, you know, 2 to 3 hours, OK? Cause we're talking about many, many gigs of, of data. So copying a movie from one server to another server could take several hours. And that's one movie. We're processing hundreds of movies every day. So, the, the internal network bandwidth was being flooded, um. You know, and that causes, you know, that causes internal trouble tickets with the networking team that, that we could eliminate. Um, and, you know, ultimately, it's, it's a great story to tell customers. Look, we're, we're able to process your, your content now much faster than we were before. And let's say in, in, in 2/3 less time, and it's a great story to tell customers. And, and that's, you know, that's the win.