# Known limitations

This is the conservative 0.2.0 release baseline. A capability appearing in
FFmpeg output does not remove these product/browser/resource limits.

## Functional

- The editor is a sequential light editor: no overlapping tracks, arbitrary
  compositing, collaborative state or professional nonlinear workflow.
- Remote URLs/protocols, live capture, DRM/encrypted media and server-side
  transcoding are outside scope.
- Fast stream-copy trim can start at a nearby keyframe; it is not promised
  frame-accurate. Accurate mode requires decoding/re-encoding.
- Stream-copy concatenate works only when selected streams and codec/container
  parameters are compatible. Other input needs normalized re-encoding.
- Crossfades are uniform fade/triangular-curve transitions on normalized
  sequential joins, not arbitrary transition effects or overlapping timeline
  tracks. They require enough material on both sides of every internal edit.
- Re-encoding is not lossless. PCM/FLAC can preserve decoded audio samples but
  cannot restore information already lost in a source.
- Metadata removal is best effort. Muxers may add structural/encoder fields,
  unknown structures can remain, and this is not an anonymity guarantee.
- Subtitle support is text/container/filter-dependent. No OCR or universal
  bitmap-subtitle conversion is promised; burn-in never fetches remote fonts.
- Projects omit source bytes by default and therefore require local-file
  reattachment after reopening.
- The operation queue is bounded to eight scheduled items, runs one FFmpeg
  operation at a time and exists only in page memory. Reloading or closing the
  page discards queued work.
- A file-generating batch and its managed result collection are bounded to 255
  outputs, leaving the 256th ZIP entry available for an optional export report.
- Scene analysis scans the source until it finds the requested changes or
  reaches the end, retains at most 100 exact PTS results and can therefore take
  about as long as a full decode. It does not begin an export implicitly when
  no frame meets the chosen threshold.
- Labelled contact sheets require a core with `drawtext`; the reviewed local
  font does not make that filter available on a core that omits it.
- Preview proxies are bounded, lossy H.264/AAC derivatives for local playback;
  they do not replace the source or guarantee that every browser can play the
  result.

## Format and browser

- There is no “all FFmpeg formats supported” claim. The active core gates
  presets from runtime formats/codecs/encoders/filters.
- FFmpeg-readable output may be download-only because browser media elements
  support fewer container/codec combinations.
- Browser support, codec policy and memory differ across Chromium, Firefox and
  Safari and across desktop/mobile versions.
- The reviewed 0.12.10 core profile passes the non-empty Opus encode/re-probe
  gate in isolated Chromium ST and MT runs. That evidence is not a
  cross-browser or every-input Opus guarantee.
- MT needs HTTPS, COOP/COEP/CORP and `SharedArrayBuffer`. ST fallback works
  without isolation but is not a guarantee that a large job fits.
- Top-level navigation is supported; iframe embedding is not.

## Resource and performance

- ffmpeg.wasm documents a 2 GiB input ceiling; the application uses stricter
  1.5 GiB hard input/total and 1 GiB estimated-output defaults. Practical
  limits may be far lower.
- Only one FFmpeg job runs at once. Core startup downloads/instantiates roughly
  32 MiB of WASM and capability discovery adds latency.
- To bound retained native heap state in long heterogeneous sessions, an idle
  core is refreshed before its seventeenth media execution and before a fourth
  contact sheet. The queue and completed results survive, but that next job
  pays core startup and capability discovery latency again.
- WebAssembly can be substantially slower than native FFmpeg and has no
  supported hardware encoder.
- Mobile/background-tab throttling, browser quota eviction and page
  termination can interrupt a job. Progress is an estimate.
- OPFS/IndexedDB are origin-private, quota-managed and not guaranteed durable.

## Deployment and release

- A Portal deployment must permit `media-src 'self' blob:`, serve WASM as
  `application/wasm`, retain the isolation headers and cache only versioned
  FFmpeg assets as immutable. These are deployment requirements and require
  verification against the live container.
- The application is GPL-3.0-or-later and its native legal files and pinned
  source identities are included in the release record. Publish the production
  ZIP/checksum, exact `v0.2.0` source and FFmpeg Corresponding Source bundle
  together; development-only smoke artifacts must not be distributed.
- Chromium covers a broad real pinned-core ST operation matrix, a real MT
  H.264/AAC conversion, MT-to-ST fallback, nested static/Toolbox-context
  loading and one two-size ST/MT performance baseline. Firefox, Safari, mobile,
  exhaustive MT feature parity and repeated performance measurements remain
  unrecorded. Live Portal container/header verification is a deployment gate.

See `docs/FORMAT_SUPPORT.md`, `docs/PERFORMANCE.md`,
`docs/PORTAL_REQUIREMENTS.md` and `docs/RELEASE.md` for testable detail.