The Evolution of Live Streaming: From Java Push to WebRTC

The Java Push Era (Late 1990s to Early 2000s)

The first live video on the web was not video in any modern sense. It was a series of still images pushed from a server to a browser at low frequency, assembled client-side to simulate motion. Java applets handled the rendering. Connection speeds were measured in kilobits. The experience was terrible by today's standards, but it worked well enough that people paid for it.

At LiveCamNetwork, we were building on this infrastructure from around 2000. The technical challenge wasn't the streaming itself; it was the billing. Getting a browser to stay connected long enough to meter and charge for a session required architecture that didn't yet have a textbook. We built it anyway.

Windows Media and Flash (Mid 2000s)

Windows Media Player and, later, Adobe Flash changed what was possible. Compression improved dramatically. Widescreen resolution became viable. The player experience moved from clunky Java applets to embedded browser plugins that most users already had installed.

Flash became dominant for a simple reason: it worked consistently across operating systems and required no configuration from the viewer. RTMP (Real-Time Messaging Protocol) was the underlying transport, and it was solid. Flash's problems were not technical; they were architectural. The plugin model that made it easy to deploy also made it a security liability, and mobile devices never supported it.

When Apple shipped the iPhone without Flash support in 2007, the countdown began.

The Shift to HTML5 and HLS

The mobile problem forced the industry toward HTML5 video and HTTP Live Streaming (HLS). HLS works by breaking a stream into small chunks delivered over standard HTTP, which means it passes through firewalls and works on every device with a modern browser. The trade-off was latency: HLS introduced delays of 15 to 30 seconds, which made it unsuitable for interactive use cases like pay-per-minute cam platforms.

For broadcast and recorded content, HLS was a step forward. For live interactive sessions where the viewer and performer need to communicate in real time, it was not workable. That gap is what WebRTC was built to solve.

WebRTC and the Modern Era

WebRTC (Web Real-Time Communication) was standardised by the W3C in 2021, though Google had open-sourced the underlying technology a decade earlier. The key properties that changed everything: peer-to-peer connections established directly between browsers, sub-second latency, no plugin required, and native support in every major browser.

For interactive streaming platforms, WebRTC removed the last significant technical barrier. A performer and viewer can now establish a low-latency, encrypted video connection using hardware that costs a few hundred dollars, with no intermediary software installed on either side.

Streaming Servers and Infrastructure

The client-side story is only half of it. The server infrastructure that routes, records, and distributes streams has gone through an equally significant evolution. Early platforms ran on single servers with hard limits on concurrent viewers. Modern architectures use media servers that can distribute a single stream to thousands of concurrent viewers, transcode to multiple quality levels in real time, and record to storage simultaneously.

The cost of running this infrastructure has fallen by orders of magnitude. A platform that would have required a rack of dedicated hardware in 2005 now runs on a modest cloud instance or a well-specified dedicated server.

What Comes Next

The current frontier is not latency or quality; both are solved problems for most use cases. The interesting work is happening in three areas: spatial and volumetric video (3D capture that can be rendered from any viewpoint), AI-driven content generation and enhancement, and the infrastructure required to deliver immersive formats at scale.

WebRTC will remain the transport layer for interactive streaming for the foreseeable future. What changes is what it carries.