Streaming video isn't a blob you can't download

HLS and DASH look complicated from the outside: manifests pointing to hundreds of little segments, adaptive bitrates, AES-128 keys. They're actually the most downloadable format around, as long as you treat them like a list, not a stream.

Parallel segments

AES-128

Segment decryption

HLS & DASH

The manifest is the hard part

People see a video player sipping bytes in real time and assume they're watching something inherently live, a stream they can only watch and never copy. That isn't what's going on. The player is working through a text file.

HLS uses .m3u8 playlists pointing at .ts or .m4s segments. DASH uses .mpd, an XML document describing segment templates. Different surface syntax, same idea underneath: here is a list of files, fetch them in order, and you have the video.

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-STREAM-INF:BANDWIDTH=2500000,RESOLUTION=1280x720
720p/index.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=1100000,RESOLUTION=854x480
480p/index.m3u8
#EXT-X-KEY:METHOD=AES-128,URI="key.bin",IV=0x...
#EXTINF:6.0,
segment-001.ts
#EXTINF:6.0,
segment-002.ts

Once you stop thinking about it as a stream, the download problem gets a lot smaller: parse the manifest, fetch the URLs, append the bytes. Veloxar's M3U8Parser and MPDParser do exactly that, and HLSDownloader and DASHDownloader hand the resulting segment list to the same download machinery that pulls a plain HTTP file.

Eight segments, adaptive

A 30-minute video might be split into 300 six-second segments. Doing them sequentially is pointless; the TCP handshake tax alone would kill throughput. So HLSDownloader pulls up to eight segments in parallel per download.

Eight isn't a magic number, it's a ceiling. The same rate-limit tracker that governs chunked HTTP downloads governs segment fetches: if a CDN returned a 429 during a previous download, the next HLS pull from that host starts with fewer concurrent segments and walks back up only if the host stays quiet. I didn't want segment downloads special-cased as a separate kind of traffic. It's the same traffic, drawing from the same budget.

Quality is what's in the URL, not what's on the button

A manifest typically lists four to six variants: 240p, 360p, 480p, 720p, 1080p, sometimes higher. The naive picker grabs the one with the biggest BANDWIDTH attribute and calls it done. That works until you hit a site that labels a 480p file as "HD" because the word polls well, and you find yourself downloading a soft version of the video when a sharper one was sitting one line up in the playlist.

Veloxar runs variant selection through a quality ranker that trusts numeric resolution in the URL over cosmetic labels. A URL segment containing 1080 outranks a button that says "Full HD" every time, because the label is marketing and the URL is the file. The same ranker is used across every crawler plugin, which means the HLS picker, the progressive MP4 picker, and the direct-link picker all agree on what "best" means before anything hits the network.

AES-128 is not DRM

Some HLS playlists declare an EXT-X-KEY tag pointing at an AES-128 key. The first time you see it, it looks scary; the word "encryption" tends to trigger a reflex that the file is locked. It isn't. AES-128 segment encryption is plain HLS. The key URL is right there in the playlist, the decryption is standard, and any compliant client (ours included) fetches the key, caches it per playlist so it isn't re-fetched for every segment, and decodes segments as they arrive.

AES-128 in a playlist means "encoded with a key the manifest tells you how to get." Widevine and FairPlay mean "encoded with a key a license server will never give you." These are the same word for two categorically different things. Confuse them and you either give up on downloadable content or waste hours on content that was never going to be downloadable in the first place.

When a stream is actually DRM-protected, Veloxar detects it and fails fast with a message that says so, instead of grinding through segments that will never decode. That distinction is its own story; see fail fast on Widevine if you want the deeper version.

Streaming to disk, not to RAM

The tempting implementation of a segmented download is: fetch every segment into memory, decrypt what needs decrypting, concatenate, write. That works for a 50 MB clip and explodes for a 5 GB archival rip. Memory use grows linearly with file size and the OS starts paging halfway through.

Veloxar handles the two cases differently. Encrypted segments have to be decoded before their bytes are useful, so they land in a segment-sized buffer, get decrypted, then get appended to the target file. Unencrypted segments skip the buffer entirely and stream directly to disk as bytes come off the socket. A 5 GB pull is bounded by segment size (usually a few megabytes), not by total file size. You can run dozens of HLS downloads in parallel without ever caring how big any of them are.

Knowing the size before you start

A plain HTTP download sends a Content-Length header and the UI shows you the size. HLS doesn't. There is no single file to ask about; there's a list of a few hundred. You could HEAD each one to add up the bytes, but that's N extra round trips for a number the manifest already implies.

Each variant's BANDWIDTH is an average bitrate. Multiply by total duration and you have a size estimate that's usually accurate to within a few percent. Veloxar computes that estimate the moment the manifest lands and shows it in the UI before the first segment is fetched, so the user knows they're committing to a 4 GB pull and not a 400 MB one. Nobody likes finding out halfway through that they misread the number.

Honest speed, not per-segment theater

The last small thing that makes segmented downloads feel wrong in most clients is speed reporting. A naive implementation measures throughput per segment: the fast ones briefly show 99 MB/s, the slow ones briefly show 200 KB/s, and the UI flickers between the two like a broken instrument. The number is technically correct and practically useless.

Veloxar publishes a smoothed speed across all in-flight segments. The value on screen is the aggregate rate at which bytes are landing on disk, not whichever segment happened to finish a millisecond ago. It stays readable and it tracks reality, so nobody has to squint at a number that jumps two orders of magnitude twice a second.

In the player

You paste a link to a video page. Veloxar finds the manifest, picks the sharpest variant its ranker can justify, and starts pulling eight segments at once. The size you saw in the UI is the size you end up with on disk, give or take a rounding error. AES-128 playlists download like anything else; you never had to think about the key.

No flickering speed meter, no running out of RAM on a long video, and no ending up with a 480p file after a site told you it was 1080p. The manifest was a list the whole time. We just treated it like one.