Delivering Live TV Over HTTP: Trial Runs of Broadcast Technologies

Delivering high-quality live video at scale usually forces a harsh compromise: you can either have low latency or high stability. In our latest R&D cycle for the Muvie platform, we set out to prove that with a highly optimized pipeline, you don’t have to choose.

To validate our custom RTMP-to-HTTP ingest and transcoding architecture, we conducted a rigorous glass-to-glass (end-to-end) latency test.

The Methodology

Measuring latency based on player telemetry is often deceptive because it ignores the crucial ingest and transcoding paths. To get the true glass-to-glass numbers, we used a synchronized UTC visual clock overlay (in OBS) and subtracted it from the UTC time rendered on the final player screen.

Crucially, we did not give the server an easy ride. All tests were conducted over an active multi-rendition ABR (Adaptive Bitrate) transcoding pipeline running at 60 FPS (processing 1080p, 720p, and 480p streams simultaneously).

The Benchmark: BBC R&D

For a real-world benchmark, we looked to the BBC’s official R&D White Paper on Low Latency DASH (WHP429). In their live broadcast trials at Wimbledon, they achieved a total end-to-end latency of 9 seconds. Our goal was to be comparable to it, as achieving lower latency matters only when its stable to majority of viewers.

The Results

By testing all four major delivery protocols through the exact same ingest pipeline, we recorded the following glass-to-glass latencies:

• Standard DASH: 17.43 seconds

• Standard HLS: 17.21 seconds

• LL-DASH (Low Latency CMAF): 6.15 seconds

• LL-HLS (Low Latency HLS): 5.30 seconds

• Bare MPEG-TS: 1.95 seconds

Analysis

1. The Standard Baseline (~17s) As expected, Standard HLS and DASH sit right around 17 seconds. Because these protocols rely on writing full multi-second segments to disk and buffering 3-4 of those segments on the player before playback begins, this represents the standard "safe" delay of modern HTTP streaming, It is completely possible to have lower latency than this, our server has configurable knobs for both playlist size for standard modes and segment size and part size for low latency modes. if we do not transcode and package only, it is possible to get lower glass to glass latency also, but that is not a realistic case, it is shown in trials to show utmost lowest possible but not always reliable, the player always need to have some buffer, we can click one screenshot that shows a low number, in practice it is not practical because each http request carries latency so playback would stall quick, which is what we do not want.

as you can see Dash reference stream has 4.77s buffer, which is loaded and its about to play while loading new segments.

2. Comparing the BBC Benchmark (~5.3s - 6.1s) The moment we enabled CMAF chunking and our Low Latency packaging specifications, latency plummeted. Our LL-DASH pipeline clocked in at 6.15s, while LL-HLS aggressively locked onto the live edge at a blistering 5.30s. Not only did both protocols easily clear the BBC's 9-second benchmark, but they achieved a true glass-to-glass latency that is equal to what most commercial players claim as their network-only latency.

this is BBC official test stream in dash official reference player.

Meanwhile, BBC actual low latency trials use a DVB alike epoch timeline with a very old Availablity Start Time so manifest effectively fetched once and segments fetched without manifest poll by computing the segment numbers. We have noticed their novel approach, there were similar approaches in other LL-DASH test streams also.

Below You can see Details of video and audio of this MPD used in official BBC Trial.

So We started tuning, and we were able to achieve similar technology usage with epoch based timing with configurable Latency Profiles, Time Shift Buffer, Min Shift Buffer Depth all in our configuration panel UI.

Below You can see Details of video and audio of this MPD used in our Trial

So we were able to achieve similar latency while being flexible for per stream easily.

3. The Raw Minimum (<2s) Finally, by bypassing manifest packaging entirely and piping the transcoder output directly via Bare MPEG-TS, we hit a remarkable 1.95 seconds. This proves that the absolute processing overhead of our RTMP bridge and Transcoder ABR transcoder is virtually zero.

Conclusion

Building a production-ready live streaming stack requires meticulous management of transcoder mutex contention, PTS/DTS timestamp rebasing, and player buffer tuning. These benchmark numbers prove that the Muvie pipeline is mathematically dialed in—we are successfully running a broadcast-grade, multi-rendition ABR transcode and delivering it to screens worldwide faster than traditional television broadcast.

Beyond raw performance, the architecture is designed for zero-friction operability. Scaling your ABR ladder is fully automated: simply specifying target resolutions in the Admin Panel instantly generates the necessary renditions, while core transcode parameters can be tuned on the fly. Furthermore, content protection is entirely seamless. By inputting your provider credentials, the system automatically provisions and applies DRM (supporting both CBCS and CTR encryption schemes) across all packaged formats (excluding raw MPEG-TS). There are no complex API calls or manual manifest manipulations required—just save the configuration, and the pipeline dynamically secures the stream. Built to be highly resilient, the ingest engine will automatically stabilize and process nearly any source feed, failing only on the most catastrophically garbled timelines, which is intended behavior whilst giving operator more control to repair such streams too.