Download Engine Architecture

This page describes the online download and merge implementation in this repository. Browser-extension capture and optional cloud-transfer services have their own execution environments; do not assume they share every browser-page constraint or saving path.

Full data flow view

1. The tool parses the supplied source and presents the available streams or tracks.
2. Download tasks retrieve supported segments and report progress or a source error.
3. Media processing preserves playback order and handles supported encryption and container formats.
4. Merge helpers remux supported tracks or write supported TS segments.
5. Output is saved through an available file-writing or browser-download path.

A downloaded segment is not necessarily a completed playable file. Initialization data, timestamps, track compatibility, and successful finalization also matter.

Segment processing and DASH processing

app/composables/useStreamMerge.ts coordinates merge operations and reports stages such as downloading, muxing, writing, and interleaving. Its APIs accept supported segment buffers or asynchronous generators. The source tool is responsible for providing the correct inputs.

MPEG-TS conversion uses mux.js helpers in app/utils/muxjsTransmux.ts. Supported MP4 and separate-track operations use Mediabunny. Fragmented MP4 needs its initialization information, and separate video and audio must both be available. Recording captures can contain independent inputs with repeated initialization segments and require their own normalization path.

Supported AES-128 HLS processing uses supplied or accessible key material and valid source data. This is not a DRM bypass, and an encryption marker is not evidence that a stream can be decrypted. See Video sniffing and Known limitations.

File writing module

The implementation chooses among capabilities exposed by the active browser and workflow:

OPFS is staging storage, not the user's Downloads folder. Preparing a result or opening a download prompt does not prove that a file has been saved. The browser-download store retains retryable results until the workflow confirms completion and releases them.

Memory safety management

Streaming and staging reduce the need to assemble every segment into one in-memory buffer, but do not guarantee constant memory usage or unlimited file size. Demuxing, indexes, encoding, captured buffers, and export paths can allocate additional memory.

Before a large task, check available storage and choose a supported save location. Avoid running several large conversions at once. If permission is revoked, storage fills, or the tab closes, a task may fail even after its network requests succeeded.

Retry, cancellation, and error handling

Retry is appropriate for some transient network failures. Repeating a request does not repair an expired URL, missing permission, a missing segment, or an incompatible codec. Use the source tool's retry controls and inspect the failing stage rather than raising concurrency without limit.

Cancellation propagates through supported operations with an abort signal. Intermediate data and output ownership must be released by the workflow; do not delete a staged asset while another tool still retains it. Progress, output preparation, and browser save confirmation are separate states.

Performance and diagnostics

There is no single throughput or safe file-size limit across devices. Compare a small authorized sample first. Record source type, segment count, browser, output mode, and failing stage; remove credentials and private query parameters before sharing logs.

Local browser processing and optional cloud transfer are different paths. See Privacy and security, Format conversion, Browser compatibility, and Project architecture.