Flex Stream Processor

The Flex Stream Processor (FSP) service integrates FFMPEG for transcode, frame accurate clipping, technical metadata extraction, and MP4 file stitching.

It is an optional service that may require a specific infrastructure deployment depending on your workload:

  • Customers with light, constant, predictable transcoding workload might many use static FSP instances.
  • Customers with heavier, more volatile transcoding workload may use orchestrated elastic FSP instances.

Cloud Cost Consideration

Cloud-based computing instances are expensive, even more for large ones. If you have a constant processing workload, ensure that your instances are right-sized, not to spare unnecessary money.

Additionally, it is vital (economically speaking) that you ensure that FSP instances are located in the very same region (possibly zone) than the media assets they are trying to process (read and write operations). Not doing so would induce huge egress costs.

Static FSP Instances

When constant predictable transcoding workload is expected, it makes sense to use static FSP instances.

Static FSP instances consist of a pool of dedicated metal or virtual machine instances, meant to process media assets (hence consuming lots of CPU and memory resources). Once a new media asset is scheduled to be processed, Flex will schedule the task to one of the available (understand idle) FSP instances from the pool.

It is important to right-size the FSP pool understanding that:

  • The more CPU, the fastest individual media processing will be.
  • The more FSP instances, the more media assets can be concurrently processed.
  • FSP instances are pre-allocated and always running, resources (and possibly money) will be consumed even when idle.
  • If no FSP instance is available, media processing will be delayed until one becomes ready again.

Elastic FSP Instances

When a more dynamic, unpredictable transcoding workload is expected, static FSP pool may not be convenient enough and elasticity comes in handy.

Use Cases

Possible non-exhaustive use cases for elastic FSP are:

  • You need to batch processing of 100's TB or PB, once per quarter and nothing in between.

  • Sports organizations requiring to process match content after live playout as-fast-as-possible, at all cost, within the next few minutes with maximum processing capabilities.

In such scenario, manually provisionning virtual machines and scaling up is not good enough.

Flex can then harness the power of Kubernetes-based orchestration to spin up ready-to-use FSP instances, extending the pool size to whatever size is needed. With cost control in mind, it is then possible to define minimum and maximum FSP pool size, and multiple types of instance specifications, which will automatically adjust based on your current workload.

This requires use of Cloud-based Kubernetes cluster but allows scaling from a small couple of FSP instances (minimum) for mostly-idle time ranges to several hundreds of FSP instances (maximum threshold) for peak times.