Inside Brutus Cloud: What Multi-Bitrate Transcoding, SCTE-35, and DRM Actually Look Like in Production
- 25 Aug, 2026
Cloud vs. on-prem is a framework decision, and we covered that one last week. Once it's made, the question stops being conceptual: what are you actually provisioning, and what does it cost to run?
Brutus Cloud runs the same transcoding engine as the on-premise Brutus, under a managed, elastic deployment model instead of installed hardware, same capability, different operational surface. Here's what that surface looks like once a channel is live, and what it looks like when there's no live channel at all.
Live: Ingest, Restream, and Transcode
A channel comes in over SRT, RTMP, or HLS. From there, Brutus Cloud restreams it out to multiple destinations simultaneously, SRT, RTMP, HLS, or DASH, so one ingest can feed a CDN, a social platform, and a distribution partner without three separate encode jobs. Transcoding runs to H.264, H.265, or AV1, across multiple resolutions in the same pass, which is what makes a single ingest usable as both a legacy-compatible feed and a bandwidth-efficient ABR ladder off the same source.
Closed captions and subtitles pass through the pipeline rather than getting dropped at the transcode step, which matters more than it sounds like it should the first time a compliance review catches a channel that's silently lost them.
Ad Insertion and Content Protection
SCTE-35 markers get inserted directly into the manifest, with splice_insert and time_signal landing where the downstream ad decision engine expects them. If you've had to work around a transcoder that drops or misaligns markers under load, this is the part worth pressure-testing before committing a channel lineup to it, get placement wrong and SSAI accuracy degrades before you even get to fill rate.
DRM runs inline in the transcoding path rather than as a bolt-on packaging step after the fact. For content under a licensing agreement that requires encryption at the point of transcode, that's not a checkbox, it's the detail that determines whether a given title can move through this pipeline at all.
Catch-Up and Rewind
Live channels also record as they go, which is what backs catch-up TV and rewind TV without a separate recording workflow bolted on the side. The same channel that's distributing live to end users over HLS or DASH is simultaneously building the archive that lets a viewer start twenty minutes late without missing the open.
VOD: MP4 In, HLS/DASH Out
Not everything is live. Brutus Cloud also takes MP4 uploads and converts them to HLS and DASH for VOD distribution, same output formats as the live side, so a platform serving both live channels and an on-demand library isn't running two different delivery stacks to do it.
What It's Built For
The combination points at three use cases specifically: live events that need reliable multi-destination restreaming without a control room's worth of encoding hardware on site, FAST channel distribution where SCTE-35 accuracy and multi-bitrate output do the monetization and reach work, and OTT channel distribution where the live and VOD paths need to share the same infrastructure instead of living in separate systems.
The Cost Math
Here's where the cloud-vs-on-prem calculus from last week gets concrete. Standing up equivalent capacity on general-purpose cloud infrastructure usually means paying for compute, and then paying again, separately, for hosting, for bandwidth, and for someone to provision, monitor, scale, and configure failover on top of all of it. Brutus Cloud pricing already includes hosting and bandwidth, not billed as usage on top of a base rate, and folds the management layer into that same cost instead of metering it as a second and third line item. If you'd rather not run it yourselves, having DVEO operate it costs next to nothing on top of the self-managed price, the same team that built and runs the on-premise Brutus is the one behind the console.
That changes what "managed" costs relative to "self-managed" in this specific comparison. The case for cloud was never just elastic capacity, it's elastic capacity without the hosting, bandwidth, and operational overhead that normally show up as separate charges. That's the spec, and the economics, behind Brutus Cloud.
Talk to an Engineer about mapping it to your channel lineup.