DEV Community

Cover image for How Do You Actually Download an .mpd Video?
Rajesh
Rajesh

Posted on AI-assisted

How Do You Actually Download an .mpd Video?

#development #software #tutorial

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

Perfect.

Except instead of this:

video.mp4
Enter fullscreen mode Exit fullscreen mode

you find this:

manifest.mpd
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

That's quite a long way from:

Right click → Save video as...
Enter fullscreen mode Exit fullscreen mode

Then you discover FFmpeg

Naturally, the next search is usually something like:

download mpd using ffmpeg
Enter fullscreen mode Exit fullscreen mode

And sometimes...

it works immediately.

Nice.

Then you try another video:

HTTP error 403 Forbidden
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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

So copying:

https://example.com/video/manifest.mpd
Enter fullscreen mode Exit fullscreen mode

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 ✗
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

may actually involve:

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

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
Enter fullscreen mode Exit fullscreen mode

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.

Top comments (0)