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.

Protocol and Codec Range

A cloud transcoding layer earns its place by sitting cleanly between whatever's feeding it and whatever's consuming it, without forcing a normalization step on either side. Ingest covers UDP unicast/multicast, RTSP, RTMP (pull and push), SRT, and HLS, with the same set available on output. Video decode handles MPEG2, H.264, and H.265, encode targets H.264 and H.265, and audio runs MPEG2, AAC, AC3, and MP4 on ingest, AAC, AC3, or MPEG2 on encode. In practice, that's enough range to take a legacy MPTS contribution feed in on one side and push an ABR ladder out the other, while a second channel on the same instance takes SRT in and feeds a legacy RTMP-based CDN, no separate conversion hop for either.

Ad Insertion and Content Protection

That range matters most once monetization enters the picture. SCTE-35 markers get inserted directly into the HLS/DASH manifest or into UDP output, 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.

Built to Stay Up

Input failover switches sources without dropping the channel when a feed goes down, no manual re-point required. Closed captions (608/708), DVB subtitles, and teletext all pass through intact, and both SPTS and MPTS are supported on the transport side, so compliance and accessibility metadata survive the transcode instead of getting silently stripped, the kind of failure that doesn't surface until a compliance audit or a viewer complaint does.

Every function above is exposed via API, which means none of this is locked behind a UI. Channel spin-up, teardown, and monitoring can be scripted against your own orchestration layer, the difference between managing five channels by hand and managing five hundred without adding headcount to do it.

The Cost Math

Here's where the cloud-vs-on-prem calculus from last week gets more concrete. Standing up equivalent capacity on general-purpose cloud infrastructure usually means paying for compute, and then paying again, separately, for someone to provision, monitor, scale, and configure failover on top of it. Brutus Cloud is priced below that baseline to begin with, and folds the management layer into the same cost instead of metering it as a second 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 operational overhead that normally gets priced in separately. That's the spec, and the economics, behind Brutus Cloud.

Talk to an Engineer about mapping it to your channel lineup.