Live and On-Demand Streaming: How It Works

Every time you watch a recorded lecture on your phone, tune into a live convocation ceremony from your hostel room, or listen to a podcast while travelling, you are using streaming technology. For libraries and educational institutions, streaming has become a core way to deliver knowledge – making lectures, archived events, and multimedia collections accessible to anyone with an internet connection. But what actually happens between the moment a video is captured and the moment it reaches your screen? This post breaks down how live and on-demand streaming work, the protocols that power them, and the best practices that keep playback smooth.

What is streaming? 🔗

Streaming is the process of transmitting audio, video, or multimedia content over the internet so that it can be consumed almost immediately, without waiting for the entire file to download. Unlike a traditional download, where the whole file must be saved to your device before you can open it, streaming sends the content continuously in small chunks. The player loads a few seconds ahead of what you are watching – a process called buffering – so playback continues smoothly even if the connection briefly dips.

There are two broad categories of streaming, and the difference comes down to when the content is created and delivered.

Live streaming 🔗

Live streaming transmits content in real time as it is being produced. The audio and video are captured, processed, and sent to viewers within seconds of the actual event. This makes it ideal for things like convocation ceremonies, guest lectures, news broadcasts, sports, and webinars. In a live stream, content is sent immediately from the cameras and equipment recording the event, rather than from servers storing pre-recorded files.

On-demand streaming 🔗

On-demand streaming, often called Video on Demand (VOD), delivers content that has already been recorded and stored. Viewers can access it whenever they choose. On-demand streaming lets users pause, rewind, and fast-forward at their convenience – the same way you watch a recorded class or a documentary. The two models are not mutually exclusive: many platforms automatically save a live broadcast and convert it into an on-demand recording, so anyone who missed the live event can watch it later.

Live webcasts: How real-time streaming works 🔗

A webcast is a live broadcast delivered over the internet to many viewers at once. Behind the seamless experience of watching an event unfold live, there are several distinct stages working together.

Capture 🔗

The process begins with capturing the content using cameras and microphones. For a news broadcast this means filming the event as it happens; in an educational setting it could be a lecture being recorded for remote students.

Encoding 🔗

Raw audio and video signals are far too large to send across the internet in their original form. Encoding converts these signals into a compressed digital format suitable for transmission. Specialised hardware or software called an encoder handles this, balancing quality against file size so the stream travels efficiently with minimal delay.

Transmission 🔗

The encoded stream is sent over the internet, usually through a Content Delivery Network (CDN) – a network of servers distributed across different locations. A CDN stores and delivers content from the server nearest to each viewer, which reduces latency and buffering. This is why a viewer in Chennai and one in Delhi can both watch the same event without noticeable lag.

Decoding and viewing 🔗

Finally, the stream reaches the viewer’s device, where the player decodes it back into watchable audio and video and plays it in real time. All of this happens within seconds, which is what makes a live stream feel “live.”

On-demand streaming: How pre-recorded content is delivered 🔗

On-demand streaming follows a similar technical pipeline but with one key difference: the encoding and storage happen before anyone watches. The content is recorded, encoded, segmented, and stored on a server in advance. When a user clicks play, the server begins sending the file in small chunks to their device.

This stored model is what powers subscription services and digital libraries alike. Subscription Video on Demand (SVOD) services give users unlimited access to a catalogue of content for a recurring fee, while educational repositories make recorded lectures and archived materials available to learners around the clock. For libraries, on-demand streaming is invaluable: a single recorded seminar can be encoded once and then served to thousands of users over months or years, turning a one-time event into a lasting resource. National platforms such as SWAYAM and NPTEL rely on exactly this model to deliver recorded course content to students across the country.

Streaming protocols and technologies 🔗

A protocol is the set of rules that governs how streaming data is packaged and transmitted between a server and a viewer’s device. Several protocols and technologies have shaped streaming over the past three decades. Understanding them helps explain why modern streaming is as reliable as it is.

HTTP Live Streaming (HLS) 🔗

HTTP Live Streaming (HLS) is the most widely used streaming protocol today. Developed by Apple and first introduced in 2009, it delivers both live and on-demand video over standard HTTP – the same protocol that powers ordinary web browsing. Because it runs over HTTP, it passes easily through firewalls and works on almost every device, from smartphones to smart TVs.

HLS works by breaking a video stream into short segments, typically a few seconds long, each stored as a small file. The protocol creates an index file that records the order of these segments and lists them at different quality levels. This index, a plain-text M3U8 playlist, tells the player which segments are available and where to find them. The player downloads the segments one after another and stitches them together for seamless playback.

The real strength of HLS is adaptive bitrate streaming. When a connection degrades mid-stream, the player silently switches to a lower-quality version of the same content, then switches back up when bandwidth improves. This is why a video on a weak mobile connection keeps playing – at reduced quality – instead of freezing. A newer variant, Low-Latency HLS (LL-HLS), reduces the delay between capture and playback to just a few seconds for more interactive live events.

RealVideo 🔗

RealVideo is one of the earliest streaming technologies, and looking at it shows how far the field has come. Developed by RealNetworks and first released in 1997, it was among the first formats to bring video streaming to a mass audience. RealVideo used the Real Time Streaming Protocol (RTSP) to set up and manage connections, while sending the actual video data through RealNetworks’ own proprietary transport method. In the late 1990s and early 2000s, many universities adopted RealVideo and its audio counterpart, RealAudio, to stream lectures and live campus events to students. Its proprietary, plugin-dependent nature eventually limited its compatibility, and it was overtaken by open, HTTP-based standards.

Flash Media Encoder and RTMP 🔗

For much of the 2000s, Adobe Flash dominated online video, and the Flash Media Live Encoder was a common tool for capturing and encoding live streams. It worked alongside the Real-Time Messaging Protocol (RTMP), originally developed by Macromedia (later acquired by Adobe) to stream audio and video between a Flash player and a server. RTMP was valued for its low latency.

The landscape shifted when Flash was discontinued in 2020 and RTMP fell out of favour for direct playback. However, RTMP did not disappear entirely. It is still widely used today for ingest – that is, carrying a stream from an encoder to a media server or platform – before the content is repackaged into a player-friendly format like HLS for final delivery.

Best practices for streaming 🔗

Delivering a stream that looks good and plays without interruption requires careful attention to a few technical factors. Whether you are a library setting up a webcast or an institution archiving lectures, these practices matter.

Bandwidth considerations 🔗

Bandwidth – the amount of data that can travel over a connection per second – varies enormously between viewers. A student on campus fibre and another on a patchy mobile network cannot be served the same single-quality stream successfully. The solution is adaptive bitrate streaming, which prepares multiple versions of the content at different quality levels. The player continually monitors network conditions and adjusts the stream accordingly, ensuring uninterrupted playback at the best quality each viewer’s connection can support. Using a CDN to deliver content from a nearby server further reduces buffering for a geographically spread-out audience.

Encoding settings 🔗

Choosing the right encoding settings is a balancing act. If the bitrate is set too high, viewers may experience stalling and buffering; if set too low, the video shows distracting compression artifacts. The standard approach is to create a bitrate ladder – a set of renditions ranging from low resolution for slow connections to high resolution for fast ones. Variable Bitrate (VBR) encoding helps here by adjusting the data rate based on how complex each part of the video is, allocating more data to fast-moving, detailed scenes and less to simple ones. Modern codecs like H.264 and H.265 (HEVC) compress video efficiently, delivering good quality at lower data rates.

User experience optimization 🔗

Beyond raw technical settings, the goal is a smooth Quality of Experience (QoE). Buffering and rebuffering interruptions are a leading cause of viewers abandoning a stream, so minimising them is the priority. Practical steps include matching segment sizes to your audience’s typical connection, offering an audio-only fallback for very weak networks, and ensuring the player works across the devices your users actually own. Monitoring analytics – tracking where buffering happens and how often quality switches occur – lets you continually refine the setup. For an educational audience that may be accessing content on inexpensive smartphones over mobile data, designing for lower-bandwidth conditions is especially important.

What do you think? If your library or college were to start streaming events and lectures, would you prioritise live webcasts for engagement or build an on-demand archive for long-term access? And how might the bandwidth realities of your own region shape the encoding choices you would make?

References

1. https://www.cloudflare.com/learning/video/what-is-streaming/
2. https://www.akamai.com/glossary/what-are-streaming-media-services
3. https://vocal.media/01/live-streaming-vs-video-on-demand-decoding-the-differences
4. https://www.muvi.com/blogs/video-encoding-bitrate-optimization/
5. https://cloudinary.com/guides/live-streaming-video/vod-streaming-versus-live-streaming-versus-ott-the-modern-video-economy
6. https://swayam.gov.in/
7. https://www.wowza.com/blog/hls
8. https://getstream.io/glossary/hls-protocol/
9. https://www.dacast.com/blog/hls-streaming-protocol/
10. https://en.wikipedia.org/wiki/RealVideo
11. https://www.servers.com/news/whitepapers/history-of-streaming-through-protocols
12. https://www.dacast.com/blog/adaptive-bitrate-streaming/
13. https://developer.att.com/video-optimizer/docs/best-practices/adaptive-bitrate-video-streaming
14. https://imagekit.io/blog/adaptive-bitrate-streaming/