Project Architecture
This guide describes the Nuxt website in the current repository. The browser extension is a separate product component; this website also contains local media tools and optional account and cloud services.
Application structure
| Location | Responsibility |
|---|---|
app/pages/ and app/components/ | Routes, forms, tool interfaces, and shared navigation |
app/composables/useStreamMerge.ts | Browser media merge and output coordination |
app/utils/muxjsTransmux.ts | MPEG-TS/MP4 helpers using mux.js |
app/utils/ and app/workers/ | Media inspection, conversion tasks, storage ownership, and worker processing |
content/ | Documentation, articles, release notes, and legal content |
locales/ | Interface translations |
server/ | Nuxt server routes and build/server plugins |
fp-user/, fp-feedback/, fp-transcode-agent/ | Separate service implementations; not the local browser processing path |
public/ | Files published directly with the site; never store internal reports here |
Local media processing
A tool reads a selected local file or an accessible source URL. Parsing and inspection determine the available tracks and supported operations. The tool then dispatches the required processing and passes the output to a save workflow.
MPEG-TS remuxing uses mux.js helpers. Supported container and separate-track processing use Mediabunny; dedicated conversion tools use their own browser codec and worker paths. There is no useFFmpeg.ts module or FFmpeg WASM command-execution stage in the current website.
useStreamMerge exposes operations including mergeSegmentsStream, mergeAudioVideoStream, mergeFmp4Stream, and mergeCapturedMediaStreams. Their input requirements differ. A recording composed of independent MediaSource captures must not be treated as a single arbitrary concatenated MP4 buffer.
See Format conversion and Download engine.
Storage and tool handoff
A result can be held as a Blob, written to a user-approved location, or staged in OPFS according to the path in use. OPFS quota and filesystem permissions still apply. Tool handoff transfers a reference to supported prepared media between workflows and must retain that media until the receiving tool releases it.
The browser-download store distinguishes preparing a result, initiating a browser download, retrying it, and confirming completion. Do not report a successful saved file merely because a download link was clicked.
Recording workflow
The recording page provides the extension-associated MediaSource capture and browser recording workflows. A direct visit shows setup guidance; a capture session requires the relevant source and browser permissions. Captured media can then be passed to supported editing or conversion tools.
Content and rendering
Nuxt Content collections provide page data from content/. Nuxt pre-renders configured routes for deployment. Browser-only APIs must be accessed from the appropriate client lifecycle or worker, not during server rendering.
Page metadata, canonical URLs, language alternatives, and structured data are generated separately from tool execution. Static llms.txt and its linked Markdown are discovery outputs, not media-processing endpoints.
Local tools vs cloud services
Local tools process selected media on the device, but source-URL requests still contact the source host. Website analytics can run when configured. Account APIs and optional cloud transfers have separate data flows and must be labelled accordingly. See Privacy and security and the Privacy policy.
Development checks
Use the scripts in the root package.json for development, linting, and building. Regression tests live in tests/unit/. Test supported and unsupported media, cancelled tasks, storage exhaustion, and browser download retry paths. For generated metadata and sitemap checks, run python scripts/check-seo-output.py dist after building.
See Contributing, Browser compatibility, and Known limitations.