Files
av-tools/docs/KNOWN_LIMITATIONS.md

5.1 KiB

Known limitations

This is the conservative 0.2.1 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.1 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.