VOB Splitting vs HLS and DASH Chunking Explained

This article explores the fundamental differences between legacy DVD VOB (Video Object) file splitting and modern HTTP streaming chunking protocols, specifically HTTP Live Streaming (HLS) and Dynamic Adaptive Streaming over HTTP (DASH). While both techniques divide larger video presentations into smaller, manageable files, they solve completely different engineering problems. By examining their architecture, splitting triggers, navigation mechanisms, and network capabilities, this guide clarifies why optical disc storage required static byte-level splits while the modern internet demands dynamic, time-aligned segments.

Purpose and Origins

VOB file splitting was designed for physical optical media governed by the DVD-Video specification in the mid-1990s. Its primary purpose was filesystem compatibility. Legacy filesystems common at the time, such as FAT16, FAT32, and the MicroUDF/ISO 9660 formats used on DVDs, could not reliably address files larger than 1 GB (or 2 GB depending on implementation). Consequently, the DVD standard enforced a strict 1 GiB (1,048,576 KB) upper limit per VOB file.

In contrast, HLS and DASH were engineered for modern internet transmission over standard HTTP protocols. Their goal is not to satisfy disk storage limitations, but to deliver smooth video playback across fluctuating network conditions to various client devices worldwide. Instead of dealing with spinning disc constraints, modern chunking provides the foundation for Adaptive Bitrate Streaming (ABR).

Split Boundaries: Byte-Size vs. Time-Aligned GOPs

The mechanism used to determine where a file breaks marks a major divergence between the two approaches:

Playback Coordination: IFO Files vs. Manifest Files

Neither system works by blindly guessing what file comes next; both use metadata maps, but in vastly different ways.

A DVD uses companion files, primarily .IFO (Information) files. The IFO file contains structural tables, navigation commands, audio/subtitle tracks, and sector offsets. The hardware or software player maintains a continuous playback buffer, pulling data seamlessly across split boundaries (e.g., from VTS_01_1.VOB to VTS_01_2.VOB) as if reading a single uninterrupted bitstream.

HLS and DASH rely on text-based web manifests—M3U8 playlists for HLS and XML-based Media Presentation Description (MPD) files for DASH. These manifests list the URLs of the media chunks (such as .ts segments or fragmented .mp4 chunks). The video player downloads the manifest, evaluates its network bandwidth, and downloads individual chunks via standard HTTP GET requests, dynamically queuing them in the playback buffer.

Adaptive Bitrate Switching and CDN Delivery

VOB files are completely static and single-rate. A set of VOB files represents a fixed-bitrate multiplexed stream. If a user’s environment changes, the file cannot adapt; playback simply halts if the read rate fails. Furthermore, VOB files are not designed for standard web caching, as their size makes them inefficient to deliver and cache over distributed Content Delivery Networks (CDNs).

HLS and DASH encode the source video at multiple quality levels and resolutions (renditions). Because every segment across these different renditions is split at the exact same timecodes and keyframe intervals, a player can dynamically switch to a higher or lower quality chunk at the next segment boundary if bandwidth fluctuates. Moreover, because segments are small, static, individual files, caching proxies and CDNs can efficiently store and distribute them close to end-users globally.