Raw Video File Uploads

First things first. Before you upload videos to any platform, you need to decide the best format for encoding your master videos. Standardizing your video format now will make it easier to manage them as your library grows.
To ensure good playback quality and efficient uploading, you can record video like MP4, which is compatible with a wide variety of compression standards (codecs), including H.264—efficient and supported by most devices—and HEVC—high quality for high-res video.

Encoding

The process of converting a raw video file into a compatible, compressed, and efficient digital format is called encoding. Getting your video feed onto your platform of choice will require an encoder, which will use a codec to compress your data according to a standard capable of being accepted and decompressed by video services across the web.

In the early days of digital video, files were all raw video, a collection of still photos. For a video recorded at sixty frames per second, you had, well, sixty photos per second. That’s 3600 images per minute of video, resulting in a massive file.
Obviously, the only solution for distribution was to compress these files, but video quality was lost as a result. Software engineers developed video-encoding processes to compress video files without compromising the quality.
There are two types of encoders: hardware and software. A hardware encoder is, as the name suggests, a physical device that captures and processes audio and visual data suitable for streaming. Hardware encoders can be complex, so they’re not often used by beginners. Software encoders are programs you can install in your system. They require less time to set up, and they’re less costly, which means they’re more universally suitable for anyone trying to format video for streaming.
For optimized encoding, go with HEVC/H.265 encoding. It can increase bandwidth efficiency by 50 percent. You can read more about building an encoding video workflow here, and then check out some techniques for optimization here.

DRM

Digital Rights Management (DRM) refers to the standards of protection for copyrighted media. Without tools and technology to enforce DRM (via limited installations, encryption, watermarks, and so on), your video content could be easily copied.

DRM Technology Providers

To achieve acceptable device coverage—and broad delivery of premium content to viewers—you’ll need to use multiple DRM systems. Here are a few of the most popular systems:
Microsoft PlayReady:

• Very popular DRM
• Supports major smart TV alliances
• Supports gaming consoles (Xbox/PlayStation)
• Only supported on Windows phones

Google Widevine

• Supports Android
• Not supported by major TV alliances
• Not supported in gaming consoles
• Natively supports Google devices

Apple Fairplay DRM

• Native support to Apple devices & HLS content
• Only (enterprise) DRM to support Safari
• Not supported by major TV alliances
• Not supported in gaming consoles

For more in-depth information about DRM, check out these resources:

• Bitmovin’s Guide to DRM
• State of the Web—Data Rights Management
• DRM Comparison

Delivery via CDN

Video delivery is perhaps the most critical part of the video workflow. You may have thousands of videos, but if your viewers have trouble playing them, that content is worthless.
A streaming service uses a CDN to publish videos faster to users around the globe. When someone tries to stream a video from a CDN, the server closest to the user either attempts to deliver it because it already has the media files cached, or it will send a request to the next closest server that does.
Most services offer pay-as-you-go fees, and so do CDNs. They’re normally billed as per usage. If you have your own server, you can connect it to CDN providers if you expect major traffic. For further optimization, you can use decentralized CDN architecture to lower the chances of rebuffering.
Delivering video through the internet in such a way that it loads quickly, doesn’t need to buffer, and plays in the highest possible quality is a complex, resource-intensive, and time-consuming challenge. Services like Bitmovin can help you set up a fast, modern streaming experience in just a few steps.

Playback

The ability to play a video within a website or in an application is an absolute necessity for anyone that uses video as part of their business. On top of that, the video playback should be a universal experience across platforms—users should be able to access the video as smoothly and easily on their phone as they do their desktop PC or television.
According to Bitmovin’s Video Developer report, 65 percent of people say that video start-up time is the most important video performance metric. This yields the issue that if a video wasn’t delivered to the user fast enough, viewers will rapidly disengage. Research from Akamai shows that most viewers will wait about two seconds for video playback, but for each second of delay after that, 5.8 percent of viewers abandon the video.

So what’s behind video playback issues in the first place? Larger files typically take longer to download, so to ensure fast playback, your service can opt to preload the video onto the device. That way, when your user clicks Play, playback will be relatively immediate.
HTML offers preload attribute options for video on a webpage: auto, metadata, and none.

```
preload = auto | metadata | none
```

When your video is delivered with `preload=”auto”`, the browser downloads the entire video file and stores it locally. This often results in a large performance improvement; the video is available locally on the device, and network interference can’t slow it down.
However, you should only use `preload=”auto”` if there’s a high chance the video will be viewed. If the video is simply living on your webpage, and it’s downloaded each time, this can add a large data penalty to your mobile users, not to mention increase your server or CDN costs for delivering the entire video to all of your users every time the page is opened.
When the video player knows the optimal video stream for playback and the stream is lower than the available network speed, the video will play with no issues.
With Bitmovin, you have complete control over your video live streams, with easy-to-use services and APIs that run easily on any cloud or hardware.

Video Analytics

So your videos are playing smoothly on your website, but do you know which ones are being viewed, where they’re being viewed, or if viewers are even watching the entire video? Businesses that analyze viewing data are able to gauge audience interest, the effectiveness of marketing efforts, and produce content that will keep viewers coming back for more.

You can use video analytics solutions like Bitmovin for custom solutions.

Complete end-to-end video workflow

So that’s an end-to-end video workflow. It starts with ensuring you’re working with the best files, then moves through choosing the right codecs, handling DRM intelligently, deciding how you want to deliver your video to consumers and how you want it to actually play, and then finally ends with analyzing the data from each of those steps so you can improve your product and service over time.
Sound like a lot? If you’d like to offload some of that workflow, contact Bitmovin, for integrated developer tools to ensure a smooth experience for OTT video providers and their viewers.

The post Everything you need to know to build an Optimized End-to-End Video Workflow appeared first on Bitmovin.

Implementing Cloud-Based Per-Title Encoding in the Real World

Bitmovin’s gives developers access to industry-leading codecs and advanced encoding algorithms such as Per-Title. As you saw in the first part of this series, Per-Title Encoding allows you to save money on storage and streaming costs while giving viewers the best perceivable quality for their streaming session.
In part one of this three-part series, I outlined a demo application and discussed a practical high-level architecture to deploy Bitmovin’s encoding service into your own AWS account’s infrastructure using Cloud Connect. 
In the application we’re discussing in this blog, users are able to upload videos to an S3 bucket which triggers a Lambda function. The Lambda, in turn, calls the Bitmovin Encoding API to configure and start encoding. The Bitmovin platform then spins up instances in your AWS account to perform the encoding. On completion, playback information and metadata about the encoding is retrieved, stored, ready to be passed through to a front-end application that will let you watch the encoded asset.
In this second part, I’ll talk more about the implementation details for the encoding workflow. I’ll show you first how to enable and configure Cloud Connect, and then how to set up this AWS-based workflow to trigger Bitmovin encodings. If you want to skip ahead, check out part three of this series: Cloud-Based Workflows with AWS: Plugging in the Video Player and Video Analytics

Enabling Cloud Connect for AWS

The Bitmovin Cloud Connect feature essentially allows you to perform encodings on virtual infrastructure inside your own AWS account, without any restrictions on the encoding features, codecs, and algorithms that Bitmovin offers.  
Let’s first look at how you need to configure things to use Cloud Connect. You will need an AWS account, and a Bitmovin account with Cloud Connect enabled (contact us if you don’t). The configuration process is documented in detail here, but I’ll walk you through the major steps below.

Configuring AWS

Bitmovin will be creating resources within your AWS account, so you’ll need to create an IAM user for it. This user needs to have access to EC2 with applicable permissions. For a prototype, using the `AmazonEC2FullAccess` is sufficient.
Next, you’ll need a Virtual Private Cloud (VPC) and Security Group in your AWS account. You likely already have a default VPC, but if you deleted it, recreate it before proceeding. The security group will make sure that the EC2 instances can communicate with the Bitmovin API and with each other. 
Finally, you will likely need to request quota increases from AWS, depending on your expected workloads and concurrency requirements. That’s due to the nature of the Bitmovin encoding process, which splits the video asset into chunks and encodes them in parallel on multiple worker instances.

Configuring Bitmovin

Now that you have a new IAM user and your AWS account configured, you need to create an infrastructure resource on the Bitmovin platform. From the Bitmovin dashboard, go to Encoding > Infrastructure > Add new Infrastructure.

Select AWS at the top and enter your credentials and a name for this infrastructure. Click Create. You now need to specify and configure what AWS region you want to work in. Click Add new Region Settings.

Enter your `security_group_id` and a low number of Max parallel Encodings to start with. You won’t need to set the other settings for simple use cases.
Finally, you need to request access to Bitmovin’s Amazon Machine Images (AMIs). These will be used to create EC2 instances on your AWS account, so let your Bitmovin technical contact know your AWS account number to get access to the AMIs.
This is all you need to do to enable Bitmovin Cloud Connect on your AWS account. Once you start using Cloud Connect, you’ll be able to take advantage of volume pricing discounts, security rules, and configuration options that aren’t available to customers using Bitmovin’s managed encoding service. 
Make a note of the ID of the infrastructure. You will need to use it in your encoding configuration later on to instruct Bitmovin to route encodings to your AWS account.

Bitmovin Encoding workflow on AWS

We are now ready to look at the details of the implementation of the workflow. In the first part of this series, I discussed in some detail the architectural choices we made for this demo application. In the remainder of this post, we will focus on the components that interact directly with the Bitmovin encoding platform.
You can also find more details on using the Bitmovin Encoding API in the documentation. Otherwise, read on to see some code samples and more details for setting this up yourself.

Encoding with the Bitmovin API and SDK

I’ll focus first on the AWS Lambda code that calls the Bitmovin API when a new file arrives on S3.

After you’ve set up S3 event notifications to call a Lambda function, you need to write some code that will handle the notification. Lambda supports several common web programming languages and Bitmovin provides SDKs for most of the same ones, but I’ll use the Python SDK for this example. You should be able to adapt these samples to your language of choice.
A Lambda function is configured to invoke a single method in the code. That method is passed an event that contains contextual information and in this case essential information about the S3 bucket and file that triggered the function. We need both to pass into the encoding configuration.

You will previously have configured an S3 Input object on the Bitmovin platform that allows the encoder to grab files from that bucket. For simple workflows with a single watch folder, you would not even need to retrieve the bucket name from the event data, but here we do it to keep the code generic and allow multiple watch folders in different buckets.
The `encode` function will initialise the Bitmovin API with your credentials, which are passed to the Lambda function via environment variables, then retrieves the S3 Input resource that corresponds to the one that triggered the event. It then creates our encoding object.

Compared to a “standard” encoding, there is really only one difference when using Cloud Connect: note how we pass the infrastructure ID and AWS region when creating the encoding object. That’s all! From here on, it is a standard Per-Title configuration, which will generate an ABR ladder optimised for that video asset.

In my code I make use of helper functions that wrap the Bitmovin SDK, to improve the readability of the high-level functions and reusability. I’ve left a lot of detail out because the Bitmovin Python SDK is already well documented. In particular, you can get full details on how to configure Per-Title from our tutorial. 
When it comes to audio, I want to make sure that the encoding only attempts to create an audio stream if it’s present in the source. This is easily accomplished with stream conditions:

We want to be able to play our video through standard web players, and we therefore also need to create HLS and DASH manifests for them. Since our use case is quite simple, I will make use of Bitmovin’s Default Manifest functionality that will create a standard manifest with very little configuration needed. So the `encode` function continues…

With this done, we are now ready to start the encoding. The start call needs a request payload that instructs the encoder to use the Per-Title algorithm and gives it complete freedom to choose the number, bitrate, and resolution of the renditions to generate for that input asset. 
We also let the encoder generate the manifests automatically when the encoding process has completed.

The code is complete, we are now ready to deploy it to our Lambda function. You will need to package it with the Bitmovin Python SDK as dependency. Check the AWS documentation on the various methods that you can use for this deployment. We also need to set the environment variables as appropriate.

At this point, your Lambda will be triggered every time a new video file is added to your S3 bucket. When encoding starts, Bitmovin will split the file, spin up Spot Instances in your AWS account, and begin the encoding process. When the video is finished, it will be saved in the Output S3 bucket you configured. You’ll be able to monitor the encoding process in the Bitmovin dashboard.

Reacting on Completion of the Encoding

In our workflow, we want to gather some information when the encoding is complete to feed to the front-end application. At a minimum, we want to know whether the encoding succeeded, the name of the asset, and the URLs of the manifests. In essence, this performs the same function as an online video platform or content management system would in a more traditional setup.
All of this should be automatic, so we will use Lambda again to retrieve that information. To trigger it, the Bitmovin platform will notify a webhook endpoint when the encoding is finished. The Lambda function will retrieve that information and then store it to DynamoDB. 

The AWS console makes it easy to create an AWS Lambda function triggered with an HTTP call, through an API Gateway endpoint. 

On the Bitmovin side of things, the simpler way to configure a webhook is through the Dashboard. I will create a single “catch-all” webhook that gets triggered for all finished encodings in my Bitmovin account. If I wanted to do it on a per-encoding basis, I could just add a webhook in the encoding configuration instead, in my `encode` function.

Amazon has documentation for setting up DynamoDB, so I won’t cover that here. Instead, I’ll show you how to save data coming in from the completed encoding job. I chose DynamoDB to store the data because it allows you to quickly store unstructured data like this. Great for prototyping during a hackathon!
This second Lambda function has its own code, with its own handler. This time the event data contains the payload from the Bitmovin notification, which contains the encoding ID.

The `summarize_encoding_info` uses the Bitmovin SDK to retrieve the asset name, path, manifest URLs, status, and other useful metadata into a JSON object. I won’t go through the details here, but you will find tips on how to do this in my tutorial on retrieving encoding information.
This function also translates S3 URLs into CloudFront CDN URLs, which the player will use for streaming.
Having extracted that metadata, we save the `info` object to our DynamoDB table (using AWS’ excellent boto3 Python library):

From now on, the data will flow in automatically, and you can use the AWS DynamoDB interface to look up metadata about your encodings.

Multiple encodings

You may remember from part one of our blog series that for the 2020 AWS + Bitmovin hackathon project, we wanted to compare Per-Title and static ladders for our content. The eagle-eyed among you will also have noticed from the previous screenshot that my DynamoDB table does indeed contain 2 sets of info data for the asset.
The code I presented in this post is indeed a simplification, which only creates a single Per-Title ladder, to make it more of a real-life use case. If you wanted to match what we did, the differences are actually quite small:

• The handler for the first Lambda function triggers 2 encodings in parallel. 
• A single parameter on the “encode” function offers a switch to allow it to handle the small differences between a static and a Per-Title configuration
• Each encoding is independent and triggers a completion notification individually. The summarize_encoding_info function in the second Lambda determines whether Per-Title was used (which I do through the use of `labels` on the encoding) and updates the corresponding fields in the DynamoDB table 

What’s Next?

In this post, you saw how to configure Bitmovin’s Cloud Connect for Amazon Web Services and call Lambda functions each time a video is uploaded and encoded. Using the encoding complete webhook, you can save metadata about each video into DynamoDB.
Going back to the high-level architecture from part one, there’s just one more piece of the application to cover. In the last part of this three-part series, I’ll show you how to implement the Bitmovin Player and gather data about how users are interacting with your content using Bitmovin Analytics.
Finally, if you need help setting up a scalable video encoding pipeline on AWS, reach out to Bitmovin’s team or read more in the encoding API’s documentation.

The post Cloud-based Per-Title Encoding Workflows (with AWS) – Part 2: Implementing the Encoding Workflow appeared first on Bitmovin.

 “Video transcoding is one of the most computationally challenging things you can do right now. As we’re moving toward more advanced codecs, those challenges become even bigger… [Bitmovin is] trying to deliver the best quality per bit so we can reach users on their mobile device or lower quality connections, while saving on their CDN spend.” – Paul MacDougall, Principal Sales Engineer, Bitmovin

Bitmovin’s video-encoding service and its unique parallelized architecture gives your developers access to the best codecs and encoding algorithms in the industry, allowing them to efficiently transcode videos in the cloud without maintaining their own custom software or hardware. This is how you can set up your very own cloud-based encoding workflow using Bitmovin Encoding with AWS.

Why Per-Title Encoding?

One of the biggest advantages of using Bitmovin is per-title encoding. Unlike standard encoding ladders, Per-Title Encoding offers you the best perceivable quality at the lowest possible bitrate. This can lead to fewer encoded files to store and lower bandwidth usage when your video is streamed.
When you compare Per-Title and standard encoding, you’ll notice that the video quality is essentially the same, but the bitrate savings are significant.

Serving video at a lower bitrate means you will stream less data, which in turn means lower hosting costs. As you can see from some of the data obtained during Bitmovin’s AWS Hackathon in 2020, Per-Title Encoding can lead to a large cost saving compared with a standard ladder (up to 69% for some of the assets used in this particular application).

Finally, Per-Title Encoding typically means fewer encoded files to store, which also reduces your hosting costs. While results will vary depending on the complexity of your video, Per-Title Encoding is almost always the right choice, as it optimizes the ladder for every asset individually.

Bitmovin Cloud Connect on AWS

With Bitmovin’s new Cloud Connect encoding option, you can now deploy Bitmovin’s software to your own public cloud account, including Amazon Web Services.
Bitmovin’s Cloud Connect option can help you further reduce your costs, allowing you to take advantage of bulk pricing deals by letting you run Bitmovin’s encoding process on your own AWS infrastructure, including with the Per-Title algorithm. Cloud Connect also gives you more control over how your infrastructure is deployed and lets you apply your own security policies while getting complete access to Bitmovin’s robust software and auto-scaling for maximum performance.

Per-Title Encoding in the Real World using Cloud-Based Workflows (with AWS)

In this three-part series, you’ll see how to deploy a real-world application that uses Bitmovin’s Per-Title Encoding in a standard cloud-based AWS workflow and with Cloud Connect. This series is based on a workflow that we built in a 2-day winter 2020 hackathon between Bitmovin and AWS.
This first part will give you an overview of the high-level architecture and AWS resources you need to run Bitmovin Per-Title Encoding. In the second part, we’ll dive into the code so you can see some of the important details your engineers will need to run encoding on your AWS architecture with the Per-Title algorithm, and in the third part, you’ll learn how to use the Bitmovin Player to gather analytics and examine how users are consuming your videos in real-time.

What We’re Building

This demo application allows users to upload a video, and then view that video. Behind the scenes, we’ll use both our classic Bitmovin Per-Title as well as our new Cloud Connect options to process and encode the video using a Per-Title ladder.
Before starting, it’s important to understand Bitmovin’s services. We offer three services that will be used throughout this application:
– Encoder: Breaks the uploaded video into chunks, transcodes each piece, and stitches them back together when complete.
– Player: Allows users to view the transcoded video on any device and any browser.
– Video Analytics: Give you insight into how users interact with your video, their bitrate, and the amount of data streamed.

When using Cloud Connect, you still use the Bitmovin platform via its APIs to orchestrate your encoding workflow, but the encoding tasks are performed in your own AWS account. While Cloud Connect runs on your infrastructure, Bitmovin handles most of the hard work of scaling up the number of instances for encoding, so you’ll just need a few Amazon services to glue the pieces together.

Key AWS Services

AWS has several great products that we’ll use together to handle authentication, file uploads, calling the Bitmovin API, and storing transcoded files and URLs. Let’s look at the key pieces required for this application and what their roles are.

Cognito

AWS Cognito handles user authentication so that only authenticated users can upload a video to your portal. While you could build your own authentication, Cognito saves you a lot of time by integrating with your existing SSO solution and Amazon’s other services.

Amplify

AWS Amplify will power your upload page. It integrates with Cognito and AWS’s various data storage options, so you can focus on the core parts of your application logic rather than the glue that moves data into and out of your backend.

Simple Storage Service (S3)

AWS S3 offers fast, affordable file hosting. We’ll use it to store the raw video files uploaded by users and the encoded files processed by Bitmovin.

Lambda

AWS Lambda is Amazon’s serverless hosting option, which allows you to write a few lines of code and instantly make them available to run in the cloud rather than having to build and deploy a robust application from scratch. Our Lambda functions will trigger the Bitmovin encoding cluster and handle the results when the encoding is finished.

EC2

Bitmovin’s encoder runs on Amazon EC2 and takes advantage of the pricing discounts for Spot Instances to help you keep your costs low. While you won’t need to manually spin up any EC2 instances to process videos (Bitmovin handles this for you), it may be helpful to know that this is what’s running under the hood.

API Gateway

Amazon API Gateway will provide a webhook URL that Bitmovin will notify when encoding is complete. API Gateway can then pass data to other Amazon services, so we’ll use it to post encoding information when the processing of a new video is done, to trigger our post-processing Lambda.

DynamoDB

Amazon’s proprietary database, DynamoDB, will store the encoded videos’ URLs. The Bitmovin Player will use these URLs to stream video to the user at the appropriate bitrate and resolution.

CloudFront

Finally, we’ll use AWS CloudFront to cache the encoded video files. A CDN is essential for streaming video because it ensures that viewers around the world will be able to watch your videos with minimal latency.

Building a Cloud-based Encoding Architecture with AWS

Now that we’ve reviewed how each Amazon service will be used, let’s walk through the flow of data through your application.

There’s a lot going on in the diagram above, so let’s break it down:

1. A user logs in using Cognito and is directed to a simple upload page hosted on Amplify.

2. The user can upload a file, which is then stored in an S3 bucket.
3. An S3 event notification triggers a first Lambda function.
4. The Lambda function configures and triggers a new Bitmovin encoding using the API, taking as parameter the new file’s location on S3.
5. Bitmovin spins up Spot Instances as needed to encode the file, and saves the outputs of the encoding to another S3 bucket. 
6. On completion (or failure) of the encoding, Bitmovin calls a webhook hosted on Amazon API Gateway.

7. The API gateway endpoint triggers a second Lambda function, which retrieves the manifest URLs from the finished encoding job.
8. The Lambda saves these URLs to DynamoDB along with some video metadata.
9. The Demo Page with embedded Bitmovin player retrieves the data from DynamoDB and triggers playback.
10. The video files are served from S3 through CloudFront to the Bitmovin Player.
11. The Player sends data to Bitmovin Analytics.

The application built for the Bitmovin-AWS hackathon actually triggered 2 encodings, one for a static ladder and the other one with Per-Title. This allowed us to compare and contrast the two types of encodings. It goes without saying that you are unlikely to need to do this in a real-life application, but the principles remain the same. We will highlight in the remainder of this 3-part blog when a step is taken specifically to enable this demo use case.

Other Options

While the architecture discussed here takes advantage of many of AWS’s latest services and features, you might want to integrate the Bitmovin Encoder into an existing application that’s set up very differently. Fortunately, the encoder can be called from any codebase and Bitmovin offers SDKs and getting started guides for using the API.
For example, you don’t need to use Lambdas to call the Bitmovin API or API gateway to listen for the completed encoding jobs. You can easily call the encoder’s API from an application deployed to EC2 or ECS. Similarly, there’s no reason you have to use DynamoDB (or a NoSQL data store at all) if you prefer MySQL or Postgres.

What’s Next?

Now that you have a high-level view of how you can deploy Bitmovin Per-Title Encoding with Cloud Connect to your AWS account, you’re probably ready to see some real API calls so you can replicate this yourself. In the next part of this series, I’ll get more tactical, showing some of the code you can use to run this application. Finally, in the third part of this series, you can learn how to use Bitmovin Analytics to understand how your users interact with your content delivered through the player.
In the meantime, you can check out our API documentation or our step-by-step tutorial for deploying Cloud Connect to learn more. When you’re ready to implement Bitmovin, contact us so we can help you get started.

The post Cloud-based Per-Title Encoding Workflows (with AWS) – Part 1: Establishing the Architecture appeared first on Bitmovin.