Implementing a video transcoding solution yourself: part 2
Limitations of the serverless transcoding function created in part 1
Transcoding videos is an extremely computation-heavy task: compared to images, where your serverless code might take at most a few seconds to finish even for large resizes, transcoding videos - even small ones - can take minutes!
This presents a problem: if you want to transcode a long video, for example a 10-minute video, you may reach the maximum execution duration allowed by your cloud function provider. AWS Lambda has a maximum execution time of 15 minutes per function invocation: anything that takes longer than this will be forcibly terminated.
If you're using x265/HEVC as your video codec, long videos being resized to more than 480p will cause your cloud function to time out, no matter what you do - it is too heavy a task for your cloud function to perform. The only realistic option left is to use a dedicated transcoding service.
Dedicated transcoding services
Most cloud providers have some form of transcoding service. AWS has Elemental MediaConvert, which lets you run "jobs" to transcode videos to different sizes, and provides an absolute ton of options.
Pros
- The dedicated service will be able to handle any task you throw at it, no matter how big
- As it has access to more powerful hardware, it will finish transcoding a lot faster
Cons
- It's a lot more expensive than using serverless code (for x265/HEVC, it'll cost around 400-500% more!)
Admittedly, the pros and cons are a bit of a moot point, as there aren't any other serious ways to transcode videos that your serverless code function can't handle.