Media Conversion
Video and audio uploaded by users is converted into formats that play reliably rather than being served as received.
Where to find it
Architect Panel → Configuration:
- Site Settings — the File Uploads and Audio/Video Conversion groups
Architect Panel → Data:
- File Stores — the stores themselves, and View File Store on a row
- Large Uploads — in-progress and stalled upload sessions
- File Import Routines — watched sources and their mappings
Why convert at all
A file recorded on a phone is in whatever format that phone produces, at whatever size and quality it chose. Served directly it may not play in some browsers, and it is usually far larger than it needs to be.
Conversion produces something that plays everywhere and downloads in a reasonable time.
How it is configured
An endpoint address for the conversion service, set in the installation’s settings. Conversion happens away from the platform, which is right — it is heavy work that would otherwise occupy the application.
It is asynchronous
A file is uploaded, queued, converted and becomes available. That gap matters to your interface: a user who uploads a video and immediately expects to play it will find it is not ready.
Say so rather than showing a broken player.
Conversion costs money
It is charged by duration and output. A workflow allowing long videos, or producing several outputs per file, costs proportionally. Worth knowing before you allow hour-long uploads.
Set sensible limits
Most business uses need a short clip rather than an hour of footage. A duration limit is easier to explain up front than an unexpected bill afterwards.
Watch for failures
Conversions fail — a corrupt file, an unsupported codec, an interrupted upload. A failure that nobody notices is a record with a video that will never play, and the user believes they attached it successfully.
Surface conversion state in the interface rather than only in a log.
Keep or discard the original
A decision worth making deliberately. Keeping it doubles storage and gives you something to re-convert from; discarding it saves space and means a failed conversion is unrecoverable.
For anything that matters, keep the original.
Test with a real phone video
Not a sample file. Something recorded on a modern phone, in portrait, several minutes long. That is what your users will actually upload.
Worked example
An organisation limits uploads to three minutes, converts asynchronously with the state shown on the record, and keeps originals. A failed conversion is visible on the record rather than only in a log, so the user is asked to re-upload rather than discovering months later.
Recommendations
- Set a duration limit before allowing uploads.
- Show conversion state in the interface.
- Keep originals for anything that matters.
- Test with a real phone recording.