When developers add video to a website, MP4 is often the first format they reach for.
It is simple, widely supported, and works with the native HTML <video> element:
```html id="cc8v1d"
For many projects, this is completely fine.
But as your application grows, you may start running into questions:
* Why does seeking sometimes feel slow?
* Why do users on slower connections experience buffering?
* How should I handle multiple video qualities?
* Should I continue serving MP4 files?
* When does HLS make more sense?
Let's look at the practical differences between MP4 delivery and HLS streaming.
## MP4 Is a File Format, HLS Is a Streaming Protocol
The first important distinction is that MP4 and HLS aren't exactly the same type of technology.
MP4 is a multimedia container format.
A typical video might look like:
```text id="5nftgo"
video.mp4
Your browser requests the file from a web server, object storage service, or CDN.
HLS (HTTP Live Streaming), on the other hand, delivers video through playlists and smaller media segments.
A simplified HLS structure looks like:
```text id="v3zvdq"
video/
├── master.m3u8
├── 1080p/
│ ├── playlist.m3u8
│ ├── segment001.ts
│ ├── segment002.ts
│ └── segment003.ts
├── 720p/
│ ├── playlist.m3u8
│ ├── segment001.ts
│ └── segment002.ts
└── 480p/
├── playlist.m3u8
└── segments...
Instead of treating the entire video as one object, playback can happen through a sequence of smaller pieces.
## How Basic MP4 Delivery Works
Imagine a 600 MB video stored at:
```text id="eg1xj7"
https://cdn.example.com/videos/tutorial.mp4
The browser can request the media using HTTP.
Modern servers may support byte-range requests, which allow the browser to request specific portions of the file.
A request could conceptually include:
```http id="w8k82o"
Range: bytes=5000000-9999999
This means MP4 delivery isn't necessarily equivalent to downloading the entire file before playback.
Properly configured MP4 delivery can work surprisingly well.
For smaller sites and straightforward use cases, it may be all you need.
## What HLS Changes
With HLS, the player first requests a playlist.
For example:
```text id="zeybq2"
master.m3u8
That playlist can reference several quality levels:
```text id="lqhh6p"
1080p
720p
480p
The player then downloads small segments as playback progresses.
Conceptually:
```text id="th3v2p"
Player
|
v
master.m3u8
|
+---- 1080p playlist
|
+---- 720p playlist
|
+---- 480p playlist
|
v
Media Segments
This architecture makes adaptive bitrate streaming possible.
Adaptive Bitrate Streaming
Adaptive bitrate streaming is one of the biggest reasons to consider HLS.
Suppose you create three versions of a video:
```text id="rj40nq"
1080p -> 5 Mbps
720p -> 2.5 Mbps
480p -> 1 Mbps
A viewer starts with a strong internet connection, so the player selects 1080p.
Then their connection becomes unstable.
Instead of repeatedly buffering the high-bitrate stream, a compatible player may switch to 720p or 480p.
When network conditions improve, it can switch back to a higher quality.
Conceptually:
```text id="o0y7sn"
Fast connection
|
v
1080p
|
Connection slows
|
v
720p
|
Connection worsens
|
v
480p
The goal is not simply to maximize resolution.
The goal is to keep playback running smoothly.
Seeking
Seeking is another important part of video UX.
Imagine someone is watching a 60-minute tutorial and jumps directly to minute 45.
With a streaming architecture, the player can request segments around the new playback position.
Instead of thinking about one giant video file, you're dealing with smaller media chunks.
This can make streaming systems easier to optimize for interactive playback.
MP4 can also support efficient seeking when HTTP range requests are correctly configured, so HLS isn't automatically faster in every situation.
Infrastructure matters.
HLS Requires More Processing
There is a tradeoff.
Uploading one MP4 is easy:
```text id="zkjvmk"
Upload
|
v
video.mp4
An HLS workflow may require:
```text id="0av0h4"
Original Video
|
v
Encoding
|
+---- 1080p
|
+---- 720p
|
+---- 480p
|
v
HLS Packaging
|
v
Playlists + Segments
This means you may need:
- FFmpeg or another encoder
- processing workers
- temporary storage
- multiple output files
- job queues
- error handling
- additional storage
- cleanup logic
That's considerably more infrastructure than uploading an MP4.
A Simple FFmpeg Example
For experimentation, FFmpeg can generate HLS output.
A very simplified command might look like:
```bash id="on1oz9"
ffmpeg \
-i input.mp4 \
-c:v libx264 \
-c:a aac \
-hls_time 6 \
-hls_playlist_type vod \
output.m3u8
This demonstrates the basic concept, but a real production pipeline usually needs more work.
You may need multiple resolutions, bitrate controls, keyframe alignment, job retries, validation, monitoring, and storage integration.
Production encoding pipelines deserve their own architecture.
## Video Infrastructure Can Become Its Own System
This is where many developers underestimate video.
At first:
```text id="qxuh2n"
Upload -> MP4 -> Website
Later:
```text id="60q1y4"
Upload
|
v
Queue
|
v
Encoder Workers
|
+---- 1080p
+---- 720p
+---- 480p
|
v
HLS Packaging
|
v
Object Storage
|
v
CDN
|
v
Player
Now you're operating a media-processing system in addition to your application.
That may be worthwhile for a video-focused product.
For other applications, it may be unnecessary operational complexity.
## Build It Yourself or Use a Platform?
There are roughly two approaches.
### Build Your Own Pipeline
A self-managed architecture might include:
```text id="ehx8pv"
Application
|
Upload API
|
Object Storage
|
Job Queue
|
FFmpeg Workers
|
HLS Outputs
|
CDN
|
Video Player
The benefit is control.
You decide:
- encoding settings
- segment duration
- storage provider
- CDN
- player
- authorization model
- monitoring
The downside is that you also operate everything.
Use Dedicated Video Infrastructure
If video isn't the core engineering problem your team wants to solve, a dedicated video streaming platform such as FileMoon is another approach worth evaluating.
A video platform can move parts of the upload, storage, processing, and delivery workflow outside your main application.
The right choice depends on your requirements.
For a video startup, building custom infrastructure may be strategically important.
For an application that simply needs reliable video playback, maintaining an entire encoding pipeline may not be the best use of engineering time.
Player Compatibility Matters
HLS support also depends on the browser environment.
Safari has native HLS support.
For other modern browsers, JavaScript libraries such as hls.js are commonly used where Media Source Extensions are available.
A simplified implementation looks like:
```javascript id="1cqj0q"
const video = document.getElementById("player");
const source = "/video/master.m3u8";
if (video.canPlayType("application/vnd.apple.mpegurl")) {
video.src = source;
} else if (Hls.isSupported()) {
const hls = new Hls();
hls.loadSource(source);
hls.attachMedia(video);
}
In production, you'll also want to think about errors, retries, analytics, autoplay policies, subtitles, accessibility, and mobile behavior.
## Storage Is Different With HLS
One MP4 video might correspond to one primary file.
HLS can generate many objects.
For example:
```text id="43b85b"
1 original video
3 quality variants
hundreds or thousands of segments
multiple playlists
If you process thousands of videos, object count can become significant.
This affects:
- storage design
- backup strategy
- deletion jobs
- synchronization
- CDN caching
- migration tooling
When deleting a video, you need to make sure all related outputs are removed.
Don't Ignore the Original File
Another design decision is whether to keep the original uploaded video.
For example:
```text id="k7xq2b"
uploads/original/video123.mp4
streams/video123/master.m3u8
streams/video123/1080p/...
streams/video123/720p/...
streams/video123/480p/...
Keeping the original makes it possible to re-encode later.
But originals can consume substantial storage.
Deleting them reduces storage costs but removes your highest-quality source.
There isn't one correct answer.
It depends on your product and retention requirements.
## When MP4 Is Enough
Use straightforward MP4 delivery when:
* your video library is small
* traffic is relatively low
* you don't need adaptive quality
* videos are short
* operational simplicity matters
* your current playback experience is already good
Don't introduce a complicated streaming architecture just because large platforms use one.
Solve the problem you actually have.
## When HLS Makes More Sense
Consider HLS when:
* videos are long
* users have varying network speeds
* mobile viewing is important
* buffering is becoming a problem
* you need multiple quality levels
* your application is becoming video-heavy
* streaming quality is central to the product
The larger your video operation becomes, the more valuable a specialized streaming architecture can become.
## Measure Before You Optimize
Before rebuilding your video system, collect data.
Useful metrics include:
```text id="v0rt8h"
startup_time
buffer_ratio
playback_errors
average_bitrate
watch_time
seek_latency
completion_rate
If users already have a fast and reliable experience with MP4, migrating everything to HLS may add complexity without solving a meaningful problem.
If users are constantly buffering, however, the data may justify investing in adaptive streaming.
Final Thoughts
MP4 and HLS both have legitimate places in web development.
MP4 is simple, widely compatible, and can work very well with correctly configured HTTP range requests and CDN delivery.
HLS adds a more sophisticated streaming model, particularly when adaptive bitrate playback and multiple quality levels become important.
The key is not to choose the technology that sounds more advanced.
Choose the simplest architecture that reliably solves your users' playback problems.
And when your video pipeline starts becoming an entire product of its own, decide whether operating that infrastructure is actually part of your application's core value.
Top comments (0)