How Do You Actually Download an .mpd Video?

Rajesh — Fri, 18 Sep 2026 17:32:26 +0000

You open DevTools → Network, start the video, and finally find what looks like the media request.

Perfect.

Except instead of this:

video.mp4

you find this:

manifest.mpd

You open it...

And instead of a video, you're staring at a wall of XML.

So now what?

The `.mpd` file isn't actually the video

An MPD file is essentially a map describing how a DASH stream is delivered.

It may describe:

Multiple video resolutions
Separate audio tracks
Different codecs
Subtitles
Initialization segments
Hundreds of media segments
Timing information
Protected/DRM-backed streams

So downloading:

manifest.mpd

does not mean you've downloaded the video.

You've downloaded something closer to the instructions a media player uses to reconstruct it.

A simplified picture looks like this:

                    manifest.mpd
                         │
          ┌──────────────┼──────────────┐
          │              │              │
          ▼              ▼              ▼
      Video 1080p     Video 720p      Audio
          │              │              │
          └──────────────┴──────┬───────┘
                                │
                                ▼
                        Browser / Player
                                │
                                ▼
                         ▶ Final playback

The browser makes that look effortless.

It isn't.

"Fine. I'll just download the video stream."

This is where things get interesting.

With MPEG-DASH, video and audio are often delivered separately.

What appears to you as one video might actually be:

1080p video stream
        +
English audio stream
        +
hundreds of video segments
        +
hundreds of audio segments

Your browser handles all of this quietly while you watch.

If you try to save it yourself, the process can become:

MPD
 │
 ▼
Discover available streams
 │
 ▼
Choose video quality
 │
 ▼
Choose audio track
 │
 ▼
Download initialization data
 │
 ▼
Download media segments
 │
 ▼
Reconstruct video + audio
 │
 ▼
Mux both streams
 │
 ▼
Final file

That's quite a long way from:

Right click → Save video as...

Then you discover FFmpeg

Naturally, the next search is usually something like:

download mpd using ffmpeg

And sometimes...

it works immediately.

Nice.

Then you try another video:

HTTP error 403 Forbidden

But here's the confusing part:

The exact same video is playing perfectly inside your browser.

So why can the browser play it while FFmpeg can't access it?

The URL isn't always enough

Your browser may already have much more context than the MPD URL itself.

For example:

Cookies
Authorization
Referer
User-Agent
Temporary tokens
Request headers
Session state

The page may also make several requests before it ever discovers the MPD.

So copying:

https://example.com/video/manifest.mpd

from the Network tab and using it somewhere else doesn't necessarily reproduce what the browser is doing.

The manifest URL may:

Expire after a short time
Require cookies
Expect particular headers
Depend on an authenticated session
Reference media URLs that are also temporary
Contain separate audio and video representations

And if the stream is protected, there may be additional playback and authorization requirements involved.

A simplified comparison:

BROWSER

Page
 │
 ├── Session
 ├── Cookies
 ├── Headers
 ├── Tokens
 │
 ▼
manifest.mpd
 │
 ▼
Video plays ✓


DIRECT TOOL

manifest.mpd
 │
 ▼
Missing required context
 │
 ▼
403 Forbidden ✗

That is why:

"I have the MPD URL" does not always mean "I have everything needed to process the stream."

So the hard part isn't really `.mpd`

The MPD format itself isn't necessarily the biggest problem.

The real complexity is everything surrounding it.

A practical downloader may need to:

Detect the media
       │
       ▼
Understand the manifest
       │
       ▼
Identify available representations
       │
       ▼
Preserve request/session context
       │
       ▼
Select compatible audio + video
       │
       ▼
Download segments reliably
       │
       ▼
Recover from failed requests
       │
       ▼
Reconstruct streams
       │
       ▼
Mux everything
       │
       ▼
Produce a usable file

And ideally...

The person using it shouldn't need to know any of this.

They just want their authorized video available locally.

This eventually became a project

I found myself repeating the same process again and again:

DevTools
   │
   ▼
Network
   │
   ▼
Find MPD
   │
   ▼
Inspect requests
   │
   ▼
Try FFmpeg
   │
   ▼
403
   │
   ▼
Check headers/session
   │
   ▼
Try again

It worked.

But it wasn't exactly convenient.

So I started building a desktop application around this problem.

I called it MuxScope video downloader .

The idea behind MuxScope

I wanted the user's side of the workflow to be much simpler:

Paste the video page URL
          │
          ▼
Detect available media
          │
          ▼
Choose quality
          │
          ▼
Download

Simple.

Internally?

Not so simple.

MuxScope video downloader is designed around several kinds of web-delivered media:

Normal web video
HLS / .m3u8
MPEG-DASH / .mpd
Certain DRM-protected streaming scenarios

The goal is to handle the streaming complexity behind the scenes instead of making someone manually inspect manifests, identify streams, manage segments, and mux the result every time.

If you're curious, you can find the project here:

MuxScope video downloader

The interesting part wasn't building "a downloader"

What surprised me most wasn't FFmpeg itself.

It was learning how differently websites deliver video.

Something that looks like this:

▶ Play

may actually involve:

Web page
   │
   ▼
Player configuration
   │
   ▼
API request
   │
   ▼
Temporary authorization
   │
   ▼
Manifest
   │
   ├─────────────┐
   ▼             ▼
Video          Audio
   │             │
   └──────┬──────┘
          ▼
Hundreds of segments
          │
          ▼
Browser media pipeline
          │
          ▼
        ▶ Play

And the viewer never sees any of it.

That's what makes this problem interesting from an engineering perspective.

There's another rabbit hole...

While testing HLS streams, I ran into another situation.

The .m3u8 works perfectly inside the browser.

You copy the URL.

You give it to FFmpeg.

And:

403 Forbidden

Again.

Except the reason isn't always what you'd expect.

That's probably what I'll write about next:

Why does an .m3u8 URL work in the browser but return 403 Forbidden in FFmpeg?

There are some interesting browser and networking details hiding behind that one.

If you're working with HLS, DASH, FFmpeg, browser networking, or media processing, I'd be interested to hear about the strange edge cases you've encountered.

you can find MuxScope Video downloader here: Download MuxScope

Note: Only download or process content you own or are authorized to access and save. Availability depends on the website, media configuration, authorization, and applicable access restrictions.

DEV Community: Rajesh

How Do You Actually Download an .mpd Video?

The `.mpd` file isn't actually the video

"Fine. I'll just download the video stream."

Then you discover FFmpeg

The URL isn't always enough

So the hard part isn't really `.mpd`

This eventually became a project

The idea behind MuxScope

The interesting part wasn't building "a downloader"

There's another rabbit hole...

Why does an `.m3u8` URL work in the browser but return `403 Forbidden` in FFmpeg?

DEV Community: Rajesh

How Do You Actually Download an .mpd Video?

The .mpd file isn't actually the video

"Fine. I'll just download the video stream."

Then you discover FFmpeg

The URL isn't always enough

So the hard part isn't really .mpd

This eventually became a project

The idea behind MuxScope

The interesting part wasn't building "a downloader"

There's another rabbit hole...

Why does an .m3u8 URL work in the browser but return 403 Forbidden in FFmpeg?

The `.mpd` file isn't actually the video

So the hard part isn't really `.mpd`

Why does an `.m3u8` URL work in the browser but return `403 Forbidden` in FFmpeg?