Local media method
How browser-local media processing works
Browser-local media tools can inspect, decode, transform, encode, and verify files without sending selected media to an Aftermath conversion server. The boundary is useful, but browsers do not all support the same codecs or performance limits.
On this page
A file container is not the same as its codecs
MP4, MOV, WebM, and audio file extensions describe containers or common conventions. The browser still needs to understand the actual video, audio, and metadata tracks inside the selected file.
A local tool should report unsupported media clearly rather than uploading it to a hidden fallback. That means a route may work on one browser or device and decline the same source on another.
| Observation | Meaning | Safe next action |
|---|---|---|
| Container opens but a track fails | The browser lacks a compatible decoder or encoder path. | Keep the source and try a supported local tool or desktop workflow. |
| Output is much smaller | Compression changed encoded data and may change visible or audible quality. | Play or listen to the completed file. |
| Device becomes slow | Large media can consume memory, CPU, storage, or battery. | Use a shorter source, lower target, or a capable local application. |
The result receipt matters
A useful media result describes the output duration, bytes, dimensions, format, tracks, selected settings, and any warnings. Those values make it possible to compare the new file with the source without exposing the media itself to a remote service.
Playback remains essential. Technical values do not reveal every visual artefact, audio issue, or timing problem.
No-upload does not mean no limits
Local processing keeps selected bytes in the current browser workflow, but it still relies on browser APIs, codec support, device memory, battery, and the selected source. Browser extensions, other applications, and later sharing are outside that boundary.
The correct product behaviour is to state an unsupported state rather than promise conversion for every file.
When a desktop tool is a better fit
Long-form editing, uncommon codecs, exact codec control, multi-track work, and production-scale encoding may need a specialist local application. The browser tool remains useful for focused, private tasks where the current browser supports the source.
Desktop tools and commands
Use a local tool