Roku has been a dominant streaming-stick platform in the US for over a decade and the dominant smart-TV OS in the US for several years. The only supported development language for Roku apps (called "channels") is BrightScript — a proprietary, BASIC-like language with no other use case. To ship on Roku, OTT operators must maintain a BrightScript codebase alongside their iOS, Android, web and TV apps.
The Video playback model in BrightScript uses a Video SceneGraph node. Point it at an HLS or DASH URL, set DRM parameters, and Roku's native player handles the rest. The native player supports HLS (live and VOD), DASH, Widevine, PlayReady, multi-audio, captions, content steering (since Roku OS 12) and most other features OTT services need. The ABR algorithm and decoder are baked into Roku OS, similar to AVPlayer on Apple.
The pain for OTT engineering teams is that BrightScript is a single-vendor language with limited tooling, no shared ecosystem with other platforms, and a learning curve unrelated to anything else. Some teams use abstraction frameworks (Roku Developer SDK, third-party tools) to share logic with other platforms; others maintain Roku separately. The strategic question — given Roku's US market share — is whether to invest in first-class Roku support or to skip it.
The book · Volume 3 of 7
Video Streaming: A Complete Guide to Video Delivery: From ABR and CDNs to Players, WebRTC, DRM, and the Economics of Streaming
BrightScript is the only way onto Roku, so a Roku app means a separate codebase and its own playback quirks. Volume 3 covers the player side this work depends on in detail: players across platforms, ABR behavior, recovery after stalls, subtitles, DRM and QoE monitoring. Written by Nikolay Sapunov, CEO at Fora Soft.
Building a Roku channel in BrightScript alongside your other apps?
We will scope your Roku app in BrightScript, including playback, DRM and analytics, and give you a timeline and estimate. 250+ video products shipped since 2005.
