What Is VOD? Video on Demand Streaming and Delivery Explained

VOD, or video on demand, lets viewers choose prerecorded video content and watch it when they want instead of following a fixed broadcast schedule. A VOD service stores video files, prepares them for different devices and network conditions, and starts playback for that viewer when they press play.

Netflix movies, paid course libraries, sports replays, product tutorials, and recorded company town halls are all familiar examples. They may use different business models, but each gives the viewer control over what to watch, when to start, and usually when to pause, seek, or replay.

This guide explains what VOD is, how VOD streaming works, the main monetization models, the infrastructure a VOD platform needs, and how live video streams can become on-demand video content.

Video on demand is a media distribution model that gives each viewer access to a selected prerecorded asset on request. Unlike a linear channel, the program does not begin at one shared time for everyone. The platform authorizes and serves playback from a content library for each viewer request.

The asset may be a two-minute support video, a feature film, a recorded livestream, or a multi-hour training course. The defining characteristic is not length or genre. It is viewer-controlled access to stored video content.

VOD stands for video on demand. The abbreviation can describe the content, the service, or the delivery workflow. A publisher might refer to a VOD library, a VOD platform, or VOD delivery, but each use points back to prerecorded video that is available when the viewer requests it.

Short answer: live streaming follows an event as it happens. VOD streaming starts from a stored asset when an individual viewer chooses to watch.

Question	VOD answer
What content is delivered?	Prerecorded video files, including uploaded assets and recordings of live streams
Who controls the start time?	The individual viewer
How is it delivered?	Usually as adaptive HTTP video through an origin and content delivery network
How can it make money?	Subscriptions, advertising, one-time transactions, pay per view, or a hybrid model
What devices can play it?	Web browsers, mobile apps, smart TVs, streaming devices, and other supported clients
What does the platform manage?	Ingest, transcoding, storage, packaging, delivery, playback, access, analytics, and monetization

A complete VOD service is more than a folder of MP4 files. It combines media processing, content management, secure access, scalable delivery, and a player experience. The right design depends on the audience, devices, geographic reach, catalog size, video quality, and business model. Some teams buy managed streaming services, while others build their own VOD platform around modular infrastructure.

How VOD Streaming Works

A typical VOD streaming workflow moves a source video through six stages: ingest, encoding, packaging, storage, delivery, and playback.

1. Ingest or Record the Source

The workflow begins with a mezzanine file or a recording of a live video stream. A content creator may upload a finished master through a web interface, transfer it to cloud storage, submit it through an API, or configure a streaming platform to record a live session automatically.

The source should preserve enough quality for downstream processing. Starting from an already compressed, low-bitrate copy limits every rendition created from it.

2. Encode and Transcode the Video

Encoding transforms source media into a compressed output. Transcoding decodes an existing encoded source and re-encodes it to create renditions with different resolutions, bitrates, codecs, frame rates, or audio characteristics. Packaging handles manifests, segmentation, and container choices without necessarily re-encoding the media. A professional VOD platform normally produces an adaptive bitrate ladder rather than one universal file.

For example, the ladder may include 1080p, 720p, 540p, and 360p renditions. The exact settings should reflect the source, target screens, codec support, expected connection speeds, and quality goals. A well-designed ladder gives the player useful choices across expected network and device conditions. Adding poorly spaced or unnecessary renditions does not automatically improve playback and increases processing time and storage use.

3. Package the Renditions

Packaging divides the encoded video into small segments and creates manifests that tell the player what is available. Common delivery formats include HTTP Live Streaming (HLS) and MPEG-DASH.

Apple describes HLS as a technology for sending live and on-demand audio and video over ordinary web servers and CDNs. Its player can switch among available renditions as network conditions change.

4. Store and Originate the Assets

The platform stores source files, encoded renditions, manifests, segments, captions, thumbnails, and metadata. Storage may be local for a small deployment or cloud-based for scale, durability, and easier integration with media processing services.

An origin responds when the CDN requests an asset that is not already cached near viewers. The origin and storage design should account for catalog growth, retention rules, versioning, regional requirements, and recovery from failure.

5. Deliver Through a CDN

A content delivery network caches popular segments at geographically dispersed servers. This shortens the path to the audience and reduces repeated requests to the origin. CDN delivery is especially important when a premium video release or recorded event attracts viewers in many regions at once.

Cache behavior depends on audience demand. A popular title may remain close to viewers, while a long-tail asset may require an origin fetch. Publishers should monitor cache efficiency, egress, start time, errors, and rebuffering rather than assuming that every CDN configuration performs the same.

6. Start Playback and Adapt Quality

When the viewer presses play, the application checks authorization, requests the manifest, selects an initial rendition, and begins downloading small segments. Adaptive bitrate streaming lets the player move to a higher or lower rendition based on observed throughput, buffer health, screen size, and device capability.

A good player also provides seek, pause, resume, captions, audio-track selection, error handling, and analytics. The viewer sees a simple play button, but the application is coordinating identity, business rules, delivery, decoding, and quality adaptation behind it.

Types of VOD and Monetization Models

The main types of VOD are usually classified by how viewers pay and how the publisher earns revenue. A single VOD platform can support more than one model, and many services combine them.

SVOD: Subscription Video on Demand

Subscription video on demand (SVOD) gives subscribers access to a content library for a recurring fee. Netflix is a familiar example. Other SVOD platforms serve fitness classes, professional education, niche entertainment, or corporate learning.

The model offers predictable recurring revenue, but the service must continually justify the subscription with valuable content, reliable playback, discovery features, and retention programs. Some subscriptions provide unlimited access, while others use tiers based on video quality, screens, regions, or catalog access.

AVOD: Advertising-Based Video on Demand

Advertising-based video on demand (AVOD) is an ad-supported video model that lets viewers watch video content for free or at a reduced cost while the service earns revenue from ads. Ads may appear before, during, or after the program.

AVOD depends on audience scale, ad inventory, targeting, measurement, and a tolerable viewing experience. The platform may need server-side or client-side ad insertion, ad decisioning, frequency controls, and protection against invalid traffic.

TVOD: Transactional Video on Demand

Transactional video on demand (TVOD) charges for a specific asset or access period. The transaction may be a rental, purchase, or pay-per-view event. A film rental, premium sports replay, or paid conference session can use this model.

TVOD does not require an ongoing subscription, but each purchase adds friction. The service needs clear entitlements, payment processing, refund rules, regional availability, and reliable access for the period the customer bought.

Hybrid and Free VOD Models

Hybrid models mix subscription, advertising, and transactions. A service might include a basic ad-supported catalog, offer an ad-free subscription, and sell early access to premium content. A business may also provide free VOD for marketing, support, employee training, or customer education without direct monetization. These monetization models can coexist within the same content library.

Choose a model based on the value of the content, audience willingness to pay, expected viewing frequency, acquisition cost, advertising demand, and operating expense. The correct answer is a business decision supported by platform capabilities, not a video format decision.

VOD vs Live Streaming, OTT, and DVR

VOD vs Live Streaming

Live streaming sends media as an event happens. VOD streaming serves a stored asset on request. Live video prioritizes capture-to-playback delay, synchronized participation, and resilience to events that cannot be retried. VOD content prioritizes dependable startup, seeking, quality, catalog access, and repeatable playback.

The two workflows can work together. A sports match, webinar, class, or town hall can be streamed live and recorded. After post-processing and metadata work, the same event becomes on-demand content for viewers who missed it or want to watch again.

VOD vs OTT

Over-the-top (OTT) describes delivery over the internet rather than through a traditional cable, satellite, or broadcast distribution path. OTT can include on-demand libraries, live channels, or both. VOD describes when and how the stored content is selected, so a service can be both OTT and VOD.

A branded OTT app on a smart TV may offer live programming beside an on-demand catalog. The terms overlap, but they are not synonyms.

VOD vs DVR and Catch-Up TV

A digital video recorder captures scheduled programming for later viewing. Catch-up TV makes recently broadcast programs available after transmission. Both create on-demand experiences, but a broader VOD service may contain original uploads, permanent libraries, courses, rentals, and recordings that were never part of a linear schedule.

Benefits and Tradeoffs of VOD

Benefits for Viewers

• Schedule control: viewers can start when convenient instead of waiting for a broadcast.
• Playback control: supported applications allow pause, seek, replay, and resume.
• Device choice: the same content can reach browsers, mobile devices, smart TVs, and streaming devices.
• Adaptive quality: the player can select a rendition suited to the current connection.
• Content discovery: search, categories, recommendations, and playlists make a large catalog easier to navigate.

Benefits for Publishers and Media Companies

Publishers can extend the useful life of live events, reach audiences in multiple time zones, and reuse video across subscriptions, transactions, ads, education, and support. A searchable content library can keep generating value after the original production or broadcast ends.

On-demand delivery also separates media preparation from viewing time. The platform can process the asset once, cache popular segments, and serve many individual sessions without requiring the source production to remain active.

Operational Tradeoffs

VOD creates ongoing storage, encoding, CDN, rights-management, moderation, accessibility, and content-operations costs. Large libraries require metadata governance and lifecycle policies. Premium video may also require authentication, entitlements, encryption, digital rights management, watermarking, or geographic restrictions.

More formats and renditions expand device reach but multiply assets. Higher quality improves the experience but increases bitrate and storage. The platform must balance quality, availability, security, and cost against the real needs of its target audience.

Common VOD Use Cases

Entertainment and Sports Libraries

Movies, episodic programs, creator catalogs, highlights, match replays, interviews, and documentaries are natural VOD content. Entertainment services often combine large catalogs, personalized discovery, parental controls, multiple audio tracks, subtitles, and monetization. For example, Netflix uses subscription plans to provide on-demand access to movies and TV shows, while Tubi offers a free, ad-supported library. Netflix also offers an ad-supported subscription tier, showing how one service can combine multiple monetization approaches.

Sports services can complement live coverage with full replays, condensed games, clips, press conferences, and archives. Rights windows and geographic rules are central to the delivery design. For example, NBA League Pass offers full game replays, condensed games, highlights, alternate feeds, and an archive dating to the 2012–13 season, while MLB.TV provides access to live out-of-market games and game archives. NFL+ Premium similarly provides full, condensed, and All-22 replays, with availability affected by regional and blackout restrictions.

Education and Employee Training

Universities, course creators, and large enterprises use VOD for lessons, demonstrations, compliance training, onboarding, and internal communications. These workflows may need progress tracking, chapter markers, searchable transcripts, quizzes, completion records, and integration with a learning management system.

Events, Marketing, and Customer Support

A virtual event can become a library of sessions after it ends. Marketing teams can publish product demos, case studies, and webinars. Support teams can turn repeated procedures into step-by-step video. Access may be public, gated for lead generation, restricted to customers, or reserved for employees.

What a VOD Platform Needs

A professional streaming platform should support the complete path from source media to a stable viewer session. A VOD streaming platform must also coordinate stored assets, playback entitlements, and catalog operations. Features should map to operating requirements, not a generic checklist.

• Content Management and Workflow APIs: The platform should ingest uploads and recordings, organize assets, manage metadata, generate thumbnails, apply retention policies, and expose APIs or webhooks for automation. Teams with a large content library also need search, taxonomy, versioning, ownership, approval, and publishing controls.
• Playback Quality and Device Support: Confirm codec, container, protocol, browser, mobile, connected-TV, and smart-TV support. Test adaptive bitrate behavior on strong and weak networks. Measure startup time, rebuffering, rendition changes, playback errors, and completion rather than judging video quality from one office connection.
• Security and Access Control: Security may include authenticated playback, signed URLs or tokens, password protection, role-based permissions, encryption in transit and at rest, DRM, domain restrictions, geographic controls, watermarking, and audit logs. The controls should match the value and rights of the content. No single control can prevent every form of copying. The practical goal is to enforce entitlements, reduce unauthorized access, meet contractual obligations, and make misuse detectable.
• Analytics and Quality of Experience: Business analytics answer what people watch, how they discover it, where they leave, and which model generates value. Quality-of-experience analytics measure startup time, rebuffering, bitrate, errors, and device or region differences. Both are needed to understand whether the VOD service is technically healthy and commercially useful.
• Accessibility and Localization: Captions, subtitles, transcripts, audio descriptions, keyboard operation, readable controls, and localized metadata expand access. Plan these assets during production and ingest. Adding them after a large catalog has accumulated is slower and more expensive.

How to Build a VOD Streaming Workflow

1. Define the Audience and Service Requirements. Start with audience locations, expected concurrent viewers, source volume, publication speed, target devices, monetization, rights, retention, accessibility, analytics, and availability goals. A private employee-training library has different requirements from a global subscription video service.
2. Design the Encoding Ladder. Create renditions that cover the audience without wasting bandwidth or storage. Validate resolution, bitrate, frame rate, codec, audio, segment length, and keyframe alignment. Include enough range for weak mobile connections and large screens, but do not assume that more renditions always improve the result.
3. Test the Complete Viewer Journey:

• Ingest: confirm large uploads, interrupted transfers, live recordings, and metadata handling.
• Processing: validate rendition output, captions, thumbnails, manifests, and failed-job recovery.
• Authorization: test valid, expired, shared, and unauthorized access attempts.
• Playback: use representative browsers, phones, smart TVs, network conditions, and locations.
• Scale: load-test origin, APIs, entitlement services, and CDN behavior for a major release.
• Operations: verify dashboards, alerts, logs, support workflows, backups, and recovery.
  

Launch with measurable service-level objectives. Track availability, startup success, time to first frame, rebuffering, error rate, and publishing delay. A platform is not ready simply because a sample video plays.

How to Set Up Live-to-VOD Streaming with Red5 Pro

A basic live-to-VOD workflow with Red5 Pro has three stages: record a live stream, convert the finished FLV recording to MP4, and serve the resulting file to viewers. The media server and post-processing workflow can run on the same Red5 Pro host, so a separate transcoding service or third-party storage provider is optional rather than required.

The steps below assume a Linux installation at /usr/local/red5pro and use the default live application. Back up configuration files before editing them, and confirm paths and plugin options against the documentation for your installed Red5 Pro version.

What You Need

• A Red5 Pro server with the live application enabled.
• FFmpeg on the Red5 Pro host. Red5 Pro uses it to convert completed FLV recordings to MP4.
• A publisher, such as the Red5 Pro WebRTC SDK, an iOS or Android SDK, or an RTMP encoder such as OBS.
• A compatible player, such as a browser for MP4 playback or VLC for FLV, MP4, and HLS VOD.

Step 1: Record a Live Stream

Red5 Pro writes a completed recording to the application’s streams directory, such as webapps/live/streams/stream1.flv. You can request recording for an individual stream from the publisher or enable automatic recording for supported ingest workflows on the server.

Record an individual WebRTC stream. Set streamMode to record or append in the Red5 Pro WebRTC SDK publisher configuration. Use record to start a new recording, or append when the workflow must continue an existing recording.

const config = {
  host: 'your-server.example.com',
  app: 'live',
  streamName: 'stream1',
  streamMode: 'record' // 'live', 'record', or 'append'
}

Automatically record supported ingest streams. If the server should record applicable broadcasts regardless of the publisher request, set the following property in conf/red5.properties, then restart Red5 Pro:

broadcaststream.auto.record=true

While publishing, Red5 Pro places recording-related files in the application’s streams directory. After publishing stops, the finished FLV file appears there. See the Red5 Pro recording guide for the current WebRTC and mobile SDK examples.

Step 2: Convert the Recording to MP4

Modern browsers do not natively play FLV, so browser-based VOD generally requires HLS or an MP4 conversion. Red5 Pro can run its OrientationPostProcessor after the FLV writer finalizes a recording, using FFmpeg to create an MP4.

1. Enable the post processor. In conf/red5-common.xml, configure the flv.impl bean with the OrientationPostProcessor writer post processor:

<bean id="flv.impl" class="org.red5.io.flv.impl.FLV">
  <property name="cache">
    <ref bean="object.cache"/>
  </property>
  <property name="writerPostProcessors">
    <set>
      <value>com.red5pro.media.processor.OrientationPostProcessor</value>
    </set>
  </property>
</bean>

2. Configure FFmpeg. In conf/cloudstorage-plugin.properties, leave services empty for conversion without a cloud upload, set the FFmpeg path used by your installation, keep local recordings if required, and allow enough time for the longest expected recording to finish transcoding.

# Conversion only, without cloud upload
services=

# Confirm this path for your installation
ffmpeg.path=/usr/local/red5pro/ffmpeg

# Keep the local recording after processing
delete.recordings=false

# Set this near the maximum expected recording length
max.transcode.minutes=60

The same properties file contains the FFmpeg command template. Its faststart option moves MP4 metadata so playback can begin before the entire file downloads. Review the current cloud-storage plugin properties reference before changing the supplied template.

3. Restart and test. Restart Red5 Pro, publish a test stream in record mode, and stop the publisher. After post-processing finishes, confirm that stream1.mp4 appears alongside stream1.flv in webapps/live/streams/.

Open http://your-server:5080/live/mediafiles to retrieve the JSON list of available FLV and MP4 recordings. When the cloud-storage plugin is configured, this endpoint can also list files stored in the connected cloud bucket.

Step 3: Play the Recording

Play an MP4 in a web page. For a local recording served by the application, use a standard HTML video element. Use HTTPS and the configured secure port when the page itself is served over HTTPS.

<video controls src="https://your-server:5443/live/streams/stream1.mp4"></video>

Test with VLC. Open the recording URL as a network stream. VLC can play FLV, MP4, and HLS VOD, which makes it useful for checking the original recording and the converted output.

Subscribe through a Red5 Pro client. Include the file extension in the stream name, such as stream1.flv or stream1.mp4. Red5 Pro uses the extension to distinguish a recorded file from a live stream. Follow the recorded-file subscription guide for client-specific examples.

Optional: Move Recordings to Cloud Storage

For distributed or autoscaled deployments, configure the Red5 Pro cloud-storage plugin to upload completed recordings to Amazon S3, Google Cloud Storage, Microsoft Azure Blob Storage, DigitalOcean Spaces, or a supported custom provider. This requires provider credentials and bucket settings in conf/cloudstorage-plugin.properties, the appropriate post processor in conf/red5-common.xml, and application-level cloud-storage configuration.

Set delete.recordings=true only if Red5 Pro should remove the local recording after a successful upload. See the cloud-storage documentation for provider-specific requirements and file-management options.

Quick Troubleshooting Checks

• No finished recording: confirm that the publisher uses record or append, or that the relevant server-side automatic recording setting is enabled.
• FLV but no MP4: confirm that the writer post processor is enabled, the FFmpeg path is correct, and the Red5 Pro logs do not report a post-processing error.
• Short recordings convert but long recordings fail: increase max.transcode.minutes to match the approximate maximum recording length.
• Recording does not play: confirm the file exists in /live/mediafiles, use the correct extension, and avoid loading an HTTP media URL from an HTTPS page.

Red5 Pro VOD Documentation

• Recording and VOD overview
• Play recordings with third-party players
• Build a live-to-VOD workflow with HLS and cloud storage

FAQs

Conclusion

VOD gives viewers control over when prerecorded video starts while the platform manages the complex work of ingest, transcoding, packaging, storage, delivery, authorization, and adaptive playback.

A strong VOD strategy begins with audience and business requirements, not a feature list. Choose the monetization model, device reach, quality targets, security controls, and live-to-VOD workflow first. Then test the complete system under representative network and traffic conditions before committing to production.