fix(util): handle compressed responses in downloadWithProgress (#803)

[ousamabenyounes]

Summary

Fixes #803.

downloadWithProgress (in @ffmpeg/util) tracks download progress from the
Content-Length header. When the server returns a compressed response
(Content-Encoding: gzip/br/…), Content-Length is the compressed size,
while fetch's body reader yields the decompressed bytes. The old code
compared that compressed total against the decompressed received count, so:

• progress events reported received > total (over 100%), and
• at the end total !== received threw ERROR_INCOMPLETED_DOWNLOAD, only
  masked by the arrayBuffer() fallback (the slow path, added in fix: avoid body stream already read on fallback #886).

This is exactly the root cause described in the issue.

Fix

Detect the encoding and, when the response carries a Content-Encoding other
than identity, treat the total as unknown (-1) — the same behaviour already
used when no Content-Length is present. Comma-separated encodings are handled,
and identity (which means no transformation) keeps the accurate total so
progress still works.

const compressed = (resp.headers.get(HeaderContentEncoding) || "")
  .split(",")
  .map((encoding) => encoding.trim().toLowerCase())
  .some((encoding) => encoding !== "" && encoding !== "identity");
const total = compressed
  ? -1
  : parseInt(resp.headers.get(HeaderContentLength) || "-1");

Test verification (RED → GREEN)

Added tests/util-download-progress.test.js, a Node/mocha test that stubs
fetch to return a response whose Content-Length (compressed) differs from
the decompressed body the reader delivers. Run it with:

npm run build --workspace=packages/util
npx mocha tests/util-download-progress.test.js

RED — on the unmodified branch (compressed Content-Length: 100, body of 300 decompressed bytes):

  1) downloadWithProgress content-encoding handling
       never reports received > total for compressed responses and returns the full payload:
      AssertionError [ERR_ASSERTION]: progress reported received > total (over 100%): [
        { "url": "http://localhost/core.wasm", "total": 100, "received": 200, ... },
        { "url": "http://localhost/core.wasm", "total": 100, "received": 300, ... }
      ]
      + expected - actual
      -[ { ...received:300, total:100... } ]
      +[]
  0 passing / 1 failing

GREEN — with the fix:

  downloadWithProgress content-encoding handling
    ✔ never reports received > total for compressed responses and returns the full payload
    ✔ still reports an accurate total for uncompressed responses
    ✔ keeps the accurate total for Content-Encoding: identity
  3 passing

The suite covers the compressed case (the bug), an uncompressed regression
guard, and Content-Encoding: identity (total preserved).

Scope

Behaviour change is limited to downloadWithProgress; the public signature of
downloadWithProgress/toBlobURL is unchanged. Uncompressed responses keep
their existing accurate progress.

[netlify]

✅ Deploy Preview for ffmpegwasm canceled.

Name	Link
🔨 Latest commit	8dd7dcf
🔍 Latest deploy log	https://app.netlify.com/projects/ffmpegwasm/deploys/6aa0382073dd7b00086185a9