Understanding the requirements
A client came to us with a request for implementing a more cost-effective video hosting solution that would replace the service which was being used at the time. Besides reducing the cost, the main goals were to maintain the same viewing experience for the viewers and to keep the existing video uploading flow for our client’s staff. This meant that our first step had to be an assessment of the key features that made the existing solution an appealing initial choice for our client.
The service which was already in use advertises itself as a ‘video marketing software’ that takes care of hosting your videos, while at the same time providing you with an easy-to-use embeddable and customizable video player and analytics. Per today’s industry standards, it transcodes the uploaded content to multiple resolutions and bitrates for different use cases and environments, which are served as adaptive streaming playlists. This ensures that the viewer gets the optimum video quality based on their available resources (bandwidth, screen size, CPU, etc.) at any given moment, without interrupting playback. Having a smooth viewing experience was extremely important to our client, whose e-learning platform heavily relies on serving its content in the form of instructional videos.
Content security was also high on the top of the priority list - with the original solution, our client was offered privacy controls for each video in the form of password protection and domain restrictions. This meant that our replacement needed to make sure that videos can’t be downloaded or opened outside of the client’s website.
Since our client had an existing AWS account, right at the start they mentioned that they wanted to utilize it by storing all of their video content on S3. We wanted to take it one step further and implement the entire stack (that would take care of video transcoding as well) using nothing but AWS services. Considering the sheer number of them, it doesn’t come as a surprise that Amazon everything we needed in the form of S3, ElasticTranscoder, Lambda, and SNS.
At the same time, we didn’t want to overlook other hosting services that come as existing solutions. Such ready-to-use products are more expensive than solutions that require a certain level of technical prowess for integration, but if they offer the same things as the existing solution for a lesser price, we figured they were worth looking into.
One such service had fees for advanced subscription plans that were significantly cheaper than what our client was paying at the time. Despite the lower price, the core features greatly overlapped with those of the more expensive platform - privacy (password protection, domain-level privacy), analytics (Google Analytics integration, engagement stats), a certain level of video player customization (support for adding your logo, control modifications), and multiple video quality versions. Unfortunately, it also came with monthly and yearly storage limits; a dealbreaker for customers that are uploading long high-quality videos regularly.
Going with automatic transcoding setup on AWS
Going with automatic transcoding setup on AWS, taking everything into account, our client opted for the AWS option. In order to implement the entire flow, we needed to utilize the following four services:
- S3 - for storing original videos and their transcoded versions
- ElasticTranscoder - for video transcoding
- Lambda - for automatically running a script that will create a new transcoding job after a file has been uploaded to S3
- SNS - for letting our server know that the transcoding has (or hasn’t) completed
What we ended up with was a seamless process, which from the staff’s perspective worked the same as before - all that was needed from them was a simple file upload via the staff’s interface. Everything else was being taken care of in the background. The upload to S3 would trigger our Lambda script, which would create a transcoding job. Once that job was successfully done, SNS would let our server know that the adaptive streaming playlist is ready to be used, and the link to its location would be stored in our database. This URL could then be used in whatever video player our client deemed as the appropriate replacement.
The biggest advantage of going down the AWS route was certainly its pay-per-use policy. If no videos have been uploaded during the entire month, our client wouldn’t have to pay anything because there’s no monthly subscription fee like there is with most, if not all video hosting services.
Also, having set up our custom transcoding presets and Lambda script, we acquired complete control over transcoding derivatives, giving us the ability to customize the video quality according to our client’s standards - nothing more, nothing less, just exactly what they want.
On the other hand, setting up a stack like this was much more time-consuming than going with an alternative professional hosting service - instead of having a preconfigured flow, we needed to manually set up different services so that they can communicate with each other, making the entire process automated. This included a lot of back-and-forth with preset configurations before we found our perfect setup. On top of that, we needed to make sure that the integration was fitting well into our client’s app. It’s also important to mention that this approach required a separate video player integration, unlike the full-service hosting solutions, which come with their own players.
Those solutions are an excellent choice for those who don’t have a development team at their disposal. They are extremely easy to set up and use, and they offer a plethora of features. However, as fully-developed products, they often allow just surface-level customizations. Going for a solution like AWS gives you an option to cherry-pick exactly what you need without having to pay something you don’t need or use.