tips

How FlowPick Handles HLS and DASH Segments in the Browser

A current explanation of detection, segment fetching, remuxing, disk output, and the limits of FlowPick's local HLS/DASH workflows.
Updated
7 min read
# technical # hls # dash # remuxing # browser storage

A streaming page may request hundreds of short media segments rather than one MP4. Saving those segments as separate files is rarely useful. FlowPick's browser-local downloader tries to fetch the selected stream, preserve its audio/video timing, and write a playable output. This article describes the current local web pipeline, not every historical extension release or optional cloud path.

1. Identify the stream

An HLS .m3u8 or DASH .mpd URL is a manifest, not the completed video. It may refer to several quality levels, separate audio, short-lived URLs, and encryption information. FlowPick first needs a reachable manifest and a representation compatible with its downloader. Use the M3U8 analyzer or MPD analyzer to inspect a manifest you are permitted to access.

Browser playback alone does not prove a download will succeed. A source may require renewed authentication, reject separate requests, use DRM, or provide a codec that the selected output path cannot handle. FlowPick does not remove DRM or access controls.

2. Fetch and stage segments

The downloader requests the chosen segments and tracks their order and timestamps. A stream can contain audio and video in the same segment or in separate tracks. Those cases need different assembly paths. If a URL expires or a segment cannot be read, the job should report the failure; concatenating whatever bytes arrived would create a broken file.

Large downloads need a place to stage data. The local implementation can use browser storage such as OPFS and, where supported, direct file-system writing. A fallback that assembles a Blob uses much more memory, so availability and size limits vary by browser. The browser compatibility guide explains which workflows are available.

3. Remux instead of re-encode when possible

MPEG-TS segments can be remuxed into MP4 without decoding every video frame. The current web implementation uses mux.js for TS-to-MP4 handling and other browser-side code for fragmented MP4 and separate audio/video tracks; some paths use Mediabunny. It no longer uses the old FFmpeg WASM merging path described in earlier versions of this article. Exact assembly depends on the source container and the selected output path.

Remuxing changes the container, not the video or audio codec. An MP4 file carrying an unsupported codec may still fail in a player. Making H.264 from a different codec would require transcoding, which is separate work. Likewise, simply appending .mp4 to a filename does not convert the contents.

4. Save and verify

Where the browser allows it, FlowPick writes to a user-chosen file or directory. Other paths may use browser-managed downloads or temporary storage. After saving, open the file and check its duration, audio track, and seeking. If any of those fail, inspect the manifest, codec, missing segments, and the downloader's error message before retrying.

What this explanation does not claim

This is an architecture explanation, not a benchmark. Download time depends on network, segment count, source throttling, browser, disk, and any necessary post-processing. We have removed old remux-time figures because their inputs and logs were not published. We also do not claim that every HLS/DASH stream can become MP4.

For a direct-file workflow, see how to identify and save a direct MP4 or WebM URL. For background on browser codecs and storage, see WebCodecs, Workers, and OPFS.