Learn about the various steps needed to build a production level video streaming solution and how AWS helps you achieve those in an easy, scalable and low-cost manner. We will walk you through the various components of a media streaming stack, the challenges a publisher faces when moving beyond streaming to desktops and the choices you have in the AWS platform to address these by leveraging the power of the cloud.
I will start off this presentation by going over the major components of a streaming media stack to set the context for the rest of the slidesThen we will see how the rapid increase in viewership using various devices has posed a new set of challenges for the media publisherWe will then touch on how many publishers are handling this complexity and why that carries some in-efficiencies with itBased on working with our customers over the years and learning about their use cases and solutions, we have gathered a list of best practices that can help you stay competitiveNext is going a bit more deep into seeing how various AWS services can be used, within it selves and in conjunction with third parties, to implement these best practices
Here we describe what the current setup for storage is:Media companies traditionally have on-premise storagePrimarily for security reasonsSpeed of transfer for processing (edit bays, etc.)Tiered storageCurrent library (source and output formats) on site, back catalog archived on tape offsite, etc.Now we say why this need to be moved to the cloud and one of the biggest hurdles to that, moving vast libraries upstreamContent owners cannot keep up with scale – being forced to look to outside storage solutionsMore content, higher resolution=larger files, more output formats, etc.Need fast, inexpensive ways to move content into the cloud
When it comes to storage, scalability of the medium is paramount since video libraries, especially if its user generated content, expands fast (even exponentially), couple that with the fact that you will need multiple encodes of the same video (more on that in upcoming slides)You want a medium that won’t lose your video files, always demand high SLAs when it comes to durability, even more than performance and other metricsReplicating what a tape drive used to do back in the days, you need a super cheap archival solution that can keep your files in “cold storage”. Even better is one where you can setup policies in advance on when content should be moved to archivals (e.g. after 6-months, move the mezzanine copy these files to archival). In this way you don’t need to get involved and you won’t forget to do itFinally, this storage solution should be part of an ecosystem which has a rich set of media solutions in it. The reason for this is that you shouldn’t have to move all your video to yet another storage service just because capability xyz is not present in your current ecosystem
Two parts to the processing you do for filesConvert them to work with as many devices as you expect your viewers to use (aka, the “land-grab model”)Counting on a unified setup is not practical, at least for a few years outNext is to make these files deliverable through the popular HTTP video delivery protocols out there (HLS, HDS, Smooth, MPEG-DASH)<Give a 30-sec overview of how chunked delivery works>Traditionally this required streaming servers, but now more and more solutions are out there which will let you chunk the files in advance which can save on expensive compute costs, especially for popular content (vs. longtail). Virtual segmenting is even better since it removes the management complexity associated with millions of little chunksFor both these, keep in mind that due to the sheer number of permutations in transcoding/transmuxing needed, you need to have an automated transcoding solution that can scale fast and is not cost prohibitive
MP4 is still the most popular although WebM is catching up fastFLV still remains popular due to some platforms still sticking with RTMP (mostly due to legacy reasons)
In general, CloudFront only supports HTTP based delivery, meaning that client player requests going through CloudFront back to the streaming/origin server must use the HTTP protocol. The exception to this is a special case scenario where CloudFront can deliver RTMP streams. This is done by AWS running Adobe’s Flash Media Server 3.5 at the CloudFront edge locations worldwide. CloudFront will pull media files stored in S3 to CloudFront edge locations via HTTP, then use Adobe Flash Media Server running at the edge to convert the media file into an RTMP stream.Progressive download is easiest to implement and most widely supported, but can lead to wasted bandwidth. Also no quality switching mid-stream.RTSP/RTMP require a specialized streaming server and have issues with corporate firewalls.Pseudo-streaming is supported in CloudFront for HTML 5 delivery, but not for flash delivery since flash delivery typically requires querystring based segmentation. With HTML 5, players can make byte range requests which we support. ABR streaming takes advantage of CDNs by delivering HTTP cacheable objects. Each ABR format uses a similar method of segmentation where you have video “chunks” and a manifest file that describes the chunks
Challenge: Huge variety of devices, form factors, bandwidths, and streaming protocols.In terms of reaching your audience, your goal is to reach as many of them as possible.
Give an overview of why this is confusing (e.g. its not just what audio-video codecs are supported, but also what delivery protocols are supported). Don’t spend too much time here, paint the complexity picture and leave it hanging (to be solved in later slides)
Lets for example take the cross-section of smartphonesLarge and disparate collection of devicesiOS is HLS onlyAndroid has non-deterministic hardware support with a software-only baselineNewer devices coming to market frequently
Due to the licensing deals made by various companies / publishers, this complexity is to remain at least for the next few yearsMultiple transcoded outputs needed to match various device profilesCodecsScreen dimensionsAsset library management becomes a challenge at this point with the large number of encodes you now have
No true unified playerNative players offer an out of the box experienceThird-party players can add value added features (e.g. customization skins, analytics etc)No single way to secure contentDRM support differs by player/device (e.g. playready works best with smooth whereas adobe access works best with HDS)DRM can do more: it can specify policies that a player needs to adhere to (e.g. delete the chunks from hard-disk once its played)
Monitor Buffering, Player erros, server erros Internal SLAs etc Revenue, drop-off rate etcIdentify Re-encode for, e.g. iOS8 Best CDNs for the regionWhats popular in your library and give the feedback to your biz devReduce costs in this fragmented ecosystem Iteratively work on lowering buffering Be able to onboard new deviceIdentify and rectify duplication in storage, processing and delivery
Build a separate stack for each deviceIncreased complexityIncreased costInability to pivot fast for new user experiencesPick only one or two platforms to supportLoss of business by not reaching customers on other platformsSubject to risk of chosen platform(s) losing users
Faster on-boarding of contentLess content management overheadReduce processing & storage costsiOSEncode in multiple profiles to target different iPhones, iPads and Apple TVsUse H.264 & AAC codecsDeliver using HLSAndroidEncode in three different profiles; SD (low quality), SD (high quality) and HD 720pUse H.264 and AAC wherever possibleHLS delivery for v3.0+, progressive download fallbackWindows Phone 8 / XboxEncode using H.264 and AACDeliver using Smooth StreamingRokuEncode using H.264 and AACDeliver using HLSPlayStation 3Encode using H.264 and AACDeliver using HLSDesktop (Windows & OS X)Encode using H.264 and AACDeliver using HLS (or using Smooth Streaming for Windows)http://blog.zencoder.com/2012/01/24/encoding-settings-for-perfect-ipadiphone-video/http://developer.android.com/guide/appendix/media-formats.htmlhttp://msdn.microsoft.com/en-us/library/windowsphone/develop/ff462087(v=vs.105).aspxhttp://support.xbox.com/en-US/xbox-360/audio-video-setup-and-use/audio-video-playbackhttp://sdkdocs.roku.com/display/sdkdoc/Encoding+Guide#EncodingGuide-30MPEG-4part14mp4andMPEG-4part10H264http://mashable.com/2011/12/09/apple-mobile-video/
Single origin location for various CDNsScalable at a low cost
Talk about how we updated our software for Roku streaming for streaming context aware. We saw that Roku had some performance issues and worked jointly with them to zero-in on a specific way in which certain Roku requests are made. Given the impact it can cause our customers, we handled that special case leading to very good Roku performance on CloudFront
Third party player (e.g. JWPlayer) / Custom playerProvides consistent user experienceAbility to customize (e.g. branding, skins)Data collection from the deviceNative playersNo need to install softwareHard to debug and react to customer issues DesktopUse third-party / custom player
Pre-DRM content while encodingNo packaging server neededNeeds encoder support. Your encoder, in addition to transcoding and packaging for delivery, will also encrypt the chunks before storing it back. Now your player needs to know how to get a decryption key from a license server and decrypt the chunksDRM on the flyPay DRM license fee only when needed. If it’s a long tail content, you can do it only when neededCDN specific private content featuresSignature based authenticationDelivery over SSLTypically requires third party / custom player for both DRM and CDN private content since the player needs to know how to acquire a license and decrypt and in the case of DRM implement policies (e.g. delete the data after its played)
CDN provided logsCache efficiency, content popularity, origin facing eventsHighly granular for generating custom reportsReal User Metrics (RUM)Requires instrumenting playersCaptures true experience of viewers (playback buffering, DRM errors, observed throughput)Consolidating the above two will show the end-to-end picture of your video delivery
Amazon Elastic TranscoderHLS output to S3Define presets to output encodes for device groups3rd party encoders on AWSSaaS SolutionsAWS Marketplace solutionsMinimize encoding time by having presets that span maximum number of devicesH.264, AAC, HLS combination works across most devicesSpecializations needed to target non-standard screen-sizes and operating systems
CloudFrontSigned URLsSSL deliveryDRMPlayReady, Adobe Access, Widevine, Merlin are the common ones with the first two seeing the most tractionWowza on Marketplace has a DRM add-on that can protect your assets while its being streamedhttp://www.wowza.com/addons/DRM-server Wowza DRM AddOn for Wowza Media Server provides integration with multiple DRM key management systems, enabling on-the-fly DRM encryption for a variety of playback devices. The integration offers best-of-breed solutions to Wowza customers who need studio-approved security for delivery of premium content. Wowza DRM AddOn provides simultaneous secure key exchange with multiple DRM platforms. Individual live or on-demand content is encrypted on-the-fly with Microsoft® PlayReady® or Verimatrix® VCAS™ for delivery via Apple® HTTP Live Streaming (HLS) and Microsoft Smooth Streaming to viewers on a wide range of endpoints, including PCs and Macs, set-top boxes (STBs), smart TVs, game consoles, smartphones, and tablets. Wowza DRM AddOn can help you up-sell content for OTT premium services and cross-sell content for multi-device distribution.- See more at: http://www.wowza.com/addons/DRM-server#sthash.vtcTAa3t.dpufAWS CloudHSM can be used to key storage using dedicated hardware that is compliant to regulationsService HighlightsSecure Key Storage — As part of the service, you have dedicated access to HSM capabilities in the cloud. AWS CloudHSM protects your cryptographic keys with tamper-resistant HSM appliances that are designed to comply with international (Common Criteria EAL4+) and U.S. Government (NIST FIPS 140-2) regulatory standards for cryptographic modules. You retain full control of your keys and cryptographic operations on the HSM, while Amazon manages and maintains the hardware without having access to your keys.Contractual and Regulatory Compliance — By protecting your keys in hardware and preventing them from being accessed by third parties, AWS CloudHSM can help you comply with the most stringent regulatory and contractual requirements for key protection.Reliable and Durable Key Storage — AWS CloudHSM is available in multiple AZs and Regions to help you build highly available applications that require strong key protection. You can also use AWS CloudHSM with your compatible on-premise HSMs to securely store keys in your datacenter. This increases key durability and gives you the flexibility to securely migrate keys in and out of AWS.Simple and Secure Connectivity — CloudHSMs are in your VPC, so it is easy to use them with your Amazon EC2 applications. You use standard Amazon VPC security mechanisms to control access to your CloudHSMs. Improve Application Performance — By placing CloudHSMs in your VPC near your EC2 instances, you can reduce network latency and increase the performance of your AWS applications that use HSMs.