Local audio & video conversion
Inspect media inputs in-browser, check controlled codec capabilities and run a cancellable conversion state machine; no real transcode is produced this round.Processed locally · never uploaded
Operations
Audio format check & conversion model
Checks duration, channels, sample rate and header MIME for 10-second audio fixtures; opens only controlled-test WAV/MP3 combinations and emits a verifiable model report.
Short video to GIF model
Checks frames, dimensions and the 5-second cap for 5-second MP4/WebM fixtures; opens only controlled-test GIF options and verifies the output model.
Real examples and limits
Initial budgets: audio 50 MiB / 5 min, video 30 MiB / 15 s, GIF at most 5 s. Files of 100 MiB+ or longer than the budget are rejected before a worker is created. The filename extension must match the header-sniffed MIME — renaming is not conversion. Only input→output→option combinations recomputed successfully from this round's controlled fixtures are open; unverified combinations fail readably, with no silent extension swap and no vertd upload. One task at a time; cancel/dispose terminates the worker, clears the virtual FS and revokes Blob URLs. No real ffmpeg.wasm/ffprobe/browser decode is bundled, so a real browser File produces a readable "unavailable" error instead of a fabricated media file.
FAQ
Are files uploaded?
No. run() never calls fetch/apiFetch; upstream vertd daemon, Stripe, donation and analytics config were removed. Leftover config is detected and refuses to run.
Why is the download a text report, not a WAV/GIF?
No real codec is bundled this round: the testable deliverables are the media model, capability gate and worker state machine. The text report is controlled acceptance evidence, explicitly labelled as non-playable; real transcoding is listed as unverified.
Which combinations are open?
10 s 44.1 kHz stereo WAV→WAV, WAV→MP3, MP3→WAV; 5 s MP4→480px/10fps GIF and WebM→320px/8fps GIF. All are controlled-model fixtures, not real codec promises.
Can a second task start after cancellation?
Yes. The state machine releases the worker and Blob URLs after cancelled/failed/succeeded; a second task starts a fresh worker and replays all phases.
Why COOP/COEP?
Only the /app/ execution area keeps isolation (multi-thread worker / shared-memory reservation). Indexable content pages set no COEP so ads and embeds stay compatible; the manifest headersProfile is isolated-app.