Live Stream M3U8 Download: Capture HLS Live Broadcasts in 2026

Updated 2026-05-10: Refreshed for the latest m3u8/HLS detection methods and Vidora extension v2.

Capturing a live HLS stream is a different problem from downloading a finished VOD. A VOD playlist is a static list with a clear endpoint. A live playlist is a moving window: segments are added every few seconds, old ones expire and get purged from the CDN, and the manifest itself changes constantly. If your tool tries to re-fetch a segment that is already gone, it fails silently or crashes.

This guide covers legitimate use cases: saving a live webinar you are authorized to record, archiving your own broadcast, keeping a backup of a live training session you paid for. It does not cover DRM-protected streams, and none of these methods work against Widevine or FairPlay.

1. Quick context: live HLS vs VOD HLS

If you want to understand what is m3u8 and HLS streaming in depth, we have a dedicated explainer. For the purposes of this guide, the key difference is structural.

A VOD m3u8 playlist looks like this:

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:10
#EXTINF:9.96,
https://cdn.example.com/seg-001.ts
#EXTINF:9.92,
https://cdn.example.com/seg-002.ts
...
#EXTINF:9.88,
https://cdn.example.com/seg-480.ts
#EXT-X-ENDLIST

Note the #EXT-X-ENDLIST tag at the bottom. That tag means the playlist is complete and will not change. A downloader can parse it once, queue all segments, and fetch them in parallel.

A live m3u8 playlist looks like this:

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:6
#EXT-X-MEDIA-SEQUENCE:18420
#EXTINF:6.00,
https://cdn.example.com/seg-18420.ts
#EXTINF:6.00,
https://cdn.example.com/seg-18421.ts
#EXTINF:6.00,
https://cdn.example.com/seg-18422.ts

No #EXT-X-ENDLIST. The #EXT-X-MEDIA-SEQUENCE tells you how many segments have already been published. The playlist only shows the latest 3 to 6 segments. A correct live downloader must poll this URL every few seconds, track which segments it has already fetched, and collect new ones as they appear - before the CDN deletes the old ones.

Live streams also frequently use AES-128 encryption. The EXT-X-KEY tag rotates: the encryption key changes every few minutes, and each new key has its own URI. Downloaders that do not handle key rotation break mid-capture. To learn more about encrypted live segments, see our guide on AES-128 encrypted streams.

2. Method 1: Browser extension while live

A browser extension running inside your authenticated session is the most reliable method for live streams. It inherits your cookies, your session tokens, and the Referer header the CDN expects. It handles key rotation by fetching each new EXT-X-KEY URI with the same credentials as the player. You get a clean MP4 at the end with no manual steps.

Step-by-step with Vidora

1. Install Vidora from the Chrome Web Store. Works on Chrome, Edge, Brave, and any Chromium-based browser.
2. Open the page hosting the live broadcast. Press play so the player fetches the live manifest. Vidora detects the manifest URL automatically - you do not need to find the m3u8 URL yourself.
3. Click the Vidora icon. The popup shows the live stream with available qualities.
4. Click Download. Vidora starts polling the manifest, collecting new segments as they publish, and writing them to disk as they arrive. A progress indicator shows the live capture in real time.
5. When the broadcast ends - or when you have captured enough - click Stop. Vidora muxes all collected segments into a single MP4 file and saves it to your Downloads folder.

Vidora handles the polling loop, segment deduplication, key rotation, and audio/video muxing transparently. If the stream has a separate audio rendition (common in adaptive HLS), Vidora fetches both and muxes them correctly. You do not need to worry about the manifest URL or DevTools extraction at all.

For a broader look at browser-based capture options, see our HLS downloader Chrome extension comparison.

Trade-offs

• Pros: handles key rotation automatically, inherits session credentials, no URL extraction required, muxes audio and video correctly, produces a clean MP4.
• Cons: Chromium-based browsers only, requires an install, cannot run headless or in a pipeline.

3. Method 2: ffmpeg with -live_start_index

ffmpeg handles live HLS natively. The difference from VOD is the -live_start_index flag, which controls where in the live playlist ffmpeg begins fetching segments.

The problem with live HLS and ffmpeg by default

Without any special flag, ffmpeg tries to start from segment sequence 0 - the very beginning of the broadcast. By the time you run the command, those early segments are long gone from the CDN. ffmpeg hits 404 errors, logs warnings, and may abort. The fix is to tell ffmpeg to start from a recent segment.

The correct ffmpeg command for a live HLS capture

ffmpeg \
  -live_start_index -3 \
  -i "https://cdn.example.com/live/playlist.m3u8" \
  -c copy \
  -t 3600 \
  output.mp4

What each flag does:

• -live_start_index -3: start from the third-most-recent segment in the current manifest, avoiding 404s on purged segments.
• -c copy: mux without re-encoding. Preserves original quality and runs at download speed.
• -t 3600: stop after 3600 seconds (1 hour). Remove this flag to run indefinitely until you press Ctrl+C.

Adding session headers for authenticated streams

If the live manifest requires cookies or a Referer header, first extract the manifest URL via DevTools, copy the relevant headers from the request, and pass them to ffmpeg:

ffmpeg \
  -live_start_index -3 \
  -headers $'Referer: https://source.example.com/\r\nCookie: session=abc123\r\n' \
  -i "https://cdn.example.com/live/playlist.m3u8" \
  -c copy \
  -t 7200 \
  output.mp4

Handling reconnects and network blips

Live captures run for hours. Network blips happen. Add reconnect flags to tell ffmpeg to retry automatically:

ffmpeg \
  -live_start_index -3 \
  -reconnect 1 \
  -reconnect_at_eof 1 \
  -reconnect_streamed 1 \
  -reconnect_delay_max 5 \
  -i "https://cdn.example.com/live/playlist.m3u8" \
  -c copy \
  -t 7200 \
  output.mp4

ffmpeg and AES-128 key rotation

ffmpeg fetches each EXT-X-KEY URI as it encounters new entries in the manifest. For public key servers, this works automatically. For key servers that require the same session cookies as the manifest, you must pass those cookies to ffmpeg via the -headers flag. If the key server uses a different domain with different auth, you may hit 403s on key fetches even when segment fetches succeed - at which point the browser extension approach is more reliable. See our guide on decrypting segments protected with EXT-X-KEY for the full breakdown.

When ffmpeg is the right choice

• You want to run a capture unattended on a server overnight.
• You need to script capture from multiple streams in parallel.
• The live stream is publicly accessible or uses simple cookie auth.
• You are comfortable with a terminal and occasional 403 debugging.

4. Method 3: OBS Studio screen capture (fallback)

OBS Studio is a free, open-source screen recorder. It does not interact with the HLS manifest at all - it simply records what the video player renders on screen. This makes it a reliable fallback when the stream is behind heavy JavaScript token gating that ffmpeg cannot replicate, or when the platform uses multiple layers of auth that a browser extension has not been updated to handle.

Setting up OBS for a browser stream capture

1. Download OBS Studio from obsproject.com and install it.
2. In OBS, click the + button under Sources and add a Window Capture source. Select your browser window.
3. Set your output format in Settings > Output to MKV (more reliable for long recordings than MP4, which can corrupt on crash).
4. Set your video resolution to match the stream resolution (1920x1080 for a 1080p broadcast).
5. Click Start Recording in OBS, then start the live stream in your browser.
6. When the broadcast ends, click Stop Recording. Use File > Remux Recordings to convert the MKV to MP4.

Quality limitations

OBS captures the rendered video, not the original encoded stream. This introduces two quality penalties: the original video is decoded to display on screen, then OBS re-encodes it for the recording. Even at high bitrate settings in OBS, you will see slight quality degradation compared to capturing the raw segments. The output is also larger per minute than a direct segment capture.

Audio sync with OBS

OBS captures audio from the system audio output (or a browser audio capture, depending on your OS). On Windows, use the Desktop Audio source in OBS. On macOS, you need a virtual audio driver (BlackHole, Soundflower) to route browser audio to OBS. On Linux, route PulseAudio to an OBS input. If you see audio drift in a long OBS recording, check that your video and audio sources are set to the same sample rate (48000 Hz by default in OBS).

When OBS is acceptable

• The stream uses JavaScript token rotation that ffmpeg and extensions cannot replicate.
• You only need the recording for personal reference and slight quality loss is acceptable.
• You already have OBS installed and want a quick solution without installing additional tools.

For streams that are actually in DASH format (you see .mpd in the manifest URL instead of .m3u8), the HLS-specific methods above will not work. Check our DASH MPD downloader guide instead.

5. Comparison table

For most users, the browser extension is the right answer. It handles the full complexity of live HLS without any manual steps. ffmpeg is correct for server-side or headless capture when you can access the key server. OBS is a last resort when the other two methods hit auth barriers.

If you want to compare more options, see our roundup of free m3u8 downloader tools.

6. Troubleshooting: segments dropped, audio drift, key rotation

Segments dropped (404 errors in ffmpeg)

The CDN purged those segments before ffmpeg could fetch them. Live CDNs typically keep segments available for only 30 to 90 seconds after publication. Two causes:

• You started ffmpeg too late and tried to fetch early segments from the beginning of the broadcast. Fix: use -live_start_index -3 to start from recent segments only.
• ffmpeg is running too slowly and falling behind the live edge. This happens on slow networks or when the output disk is too slow. Fix: write to a faster disk, or reduce the number of parallel output streams if you are muxing to multiple formats.

Audio drift in the captured file

Audio drift in long live captures comes from two sources: encoder-side timestamp jitter in the source stream, or a mismatch introduced by the capture tool concatenating segments without checking presentation timestamps. For ffmpeg, add -af aresample=async=1000 to the output to resync audio to video during remux. This compensates for small drift without introducing noticeable artifacts. If the drift is severe (more than a second per hour), the source encoder has a clock sync problem that no downstream tool can fully fix.

EXT-X-KEY rotation breaks the capture

If your ffmpeg capture suddenly produces garbled audio and video mid-stream, the key rotated and ffmpeg could not fetch the new key. Check the ffmpeg output for lines like HTTP 403 or decryption key not found. Two fixes:

• Add the session cookies to the -headers flag. The key server likely requires the same credentials as the manifest.
• Switch to Vidora, which handles key rotation inside your authenticated session transparently. See our guide on AES-128 encrypted streams and EXT-X-KEY handling for the technical details.

The captured file has no audio

The live manifest has a separate audio rendition listed in the master playlist. ffmpeg needs the master playlist URL (the one that lists multiple quality levels), not the individual media playlist URL, to detect and fetch the audio track. To find the m3u8 URL of the master playlist, look in the Network tab for the first m3u8 request that contains EXT-X-STREAM-INF lines with different bandwidth values. That is the master. The individual quality playlists are listed under it and do not include the audio track list.

OBS recording has a black frame on the live stream

Some streaming players use hardware-accelerated video rendering that bypasses the standard window composition. OBS Window Capture cannot see hardware overlays. Fix: in your browser settings, disable hardware acceleration for GPU-rendered video (Chrome: Settings > System > Use hardware acceleration when available). This forces the player to use software rendering, which OBS can capture normally.

The live broadcast has already ended - can I still download it?

If the platform converted the broadcast to a VOD recording after the event ended, you can convert the m3u8 to mp4 using the standard VOD methods - the manifest will have an EXT-X-ENDLIST tag and all segments will remain available. If the segments were purged immediately at stream end, there is nothing left to fetch. You would have needed to capture during the live window.

7. Frequently asked questions