4.5 KiB
4.5 KiB
Known limitations
This is the conservative 0.1.0 development 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.
- 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.
- 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.
- Core 0.12.10 has an Opus regression risk. Opus remains release-gated until non-empty, re-probeable ST and MT fixture outputs pass.
- 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 asapplication/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.1.0source 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.