Short answer: observe, don't guess. Start playback, let the player make its requests, and capture that request list: it contains the real media addresses, the renditions offered, and whether audio arrives separately. Then download and combine locally. A browser's own network panel shows you the same traffic, but it hands you raw parts and no assembly — which is why the observation step and the muxing step are the whole job.
Why the player is the best source of truth
Modern delivery hides the file. Media may arrive in pieces and be fed to the media element through Media Source Extensions, so there is no address in the page markup to copy. The player nonetheless has to request bytes from somewhere, and those requests are the ground truth: they carry the session authority, the rendition list, and the segment order.
Two ways to see the traffic
| Approach | What you get | What you still must do |
|---|---|---|
| Browser DevTools → Network, filtered by media | Every request the page made, with headers | Copy each part, keep the order, and mux yourself |
| Desktop tool pointed at the page | A list of detected media, rendition choices, and a queue that fetches and writes the file | Verify the result |
| Paste-a-link service | Nothing useful on session-bound streams | Find another route |
DevTools is the right tool for understanding a page; it is a poor tool for finishing a download, because a 400-segment programme is not a copy-paste job. Use it to diagnose, use the app to fetch.
The workflow
Play the video, all the way through at least once
Requests fire lazily and step up in quality as the buffer fills. Playing through means the top rendition appears in the traffic at least once, which is what makes it selectable later. See highest-quality downloading.
Capture with the page address, in the same session
Point a desktop tool at the URL that is playing, not at a share link. If the site needs a login, the tool has to operate with that session — copying cookies into some third-party box is both a security problem and the usual cause of a mysterious failure. The reasoning is on the login-required page.
Identify the shape of what you captured
One file request means a progressive download. A manifest plus many small parts means adaptive: HLS (see HLS to MP4) or DASH (see DASH MPD). If two request families appear, one video and one audio, that is separate-track delivery and you will mux.
Download with tracks together
Downloading only the video family is the single most common way to end up with a silent file. Confirm the tool has both representations before it starts, not after.
Verify the result like a reviewer
Open the file and check three things: duration matches the video, audio is present and in sync, and the last few seconds exist. A truncated file is the signature of missing tail segments; drift is a timestamp issue — both fixable, both invisible to a progress bar.
Streaming video with separate audio and video tracks
Some players swap only the video track when bandwidth changes and keep one audio track, because that is cheaper: fewer bits, one decoder, and stable lip-sync behaviour. The consequence is a directory of .m4s video parts and a parallel set of audio parts. Combining them is a copy operation, not a conversion:
ffmpeg -i video.mp4 -i audio.m4a -c copy -map 0:v -map 1:a merged.mp4
which is the same command used in the no-audio troubleshooting page. Codec support details are in FFmpeg's formats documentation, and browser-side codec parameter syntax in MDN's codecs parameter reference.
When observation returns nothing
- You analysed a paused page — play it first (this is the number one cause; see detecting no media).
- The media lives in an embedded frame, and you targeted the outer page — covered in downloading embedded video.
- The delivery is protected. Encrypted streams fed to an EME-capable player are outside everything described here.
FAQ
How do I download a video stream from a browser player?
Play it, capture the requests the player makes, choose the rendition, and download and combine the parts locally — the requests are the only reliable source of the real addresses.
Can I use DevTools to download the video?
You can find the URLs there, but you then fetch and order every segment yourself. Use DevTools to diagnose, and a downloader to finish.
Why are audio and video separate?
Adaptive streaming swaps only the video track when bandwidth changes. It means one extra fetch and a mux step, not a broken download.
Do I need to re-encode after merging?
No. Stream copy preserves the encoded data; re-encoding only when a target device genuinely requires it.
The capture shows nothing — what now?
Play the video first, check you targeted the frame or page that actually plays it, and confirm the page works in your session at all.
Does this work for protected streams?
No. DRM-encrypted media and paywalled access controls are out of scope for this method.