Audio & Video

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.

Videos Without Audio

A setting decides whether uploaded video is checked for an audio track before conversion.

Where to find it

Architect Panel → Configuration:

• Site Settings — the File Uploads and Audio/Video Conversion groups

Why it matters

Some conversion configurations expect an audio track and fail outright on a video that has none. The failure is at conversion, after the upload succeeded, so the user sees nothing wrong and the file never becomes playable.

Checking first means the situation is handled rather than discovered.

Silent video is common

More common than people expect:

• Screen recordings made without microphone permission.
• Security and dashboard camera footage.
• Drone and inspection video.
• Clips edited to remove audio.
• Animations and screen captures.

If your users upload any of those, this is not an edge case.

Leave the check on

It costs a moment before conversion and removes a failure mode that is otherwise invisible. There is no good reason to turn it off other than a conversion configuration that genuinely handles silence.

The alternative failure is silent

Which is the point. Without the check, the record has a video attachment, the user believes it worked, and it does not play. Nobody finds out until somebody tries to watch it — often much later, when it mattered.

Test it deliberately

Upload a video with no audio track. Confirm it converts and plays, or that it fails with a message somebody sees. Either outcome is acceptable; silence is not.

Tell users what is supported

Next to the upload field. A sentence on accepted formats, duration and whether silent video is fine prevents most of the failures rather than handling them.

Watch the conversion failures

A pattern of them is usually one source — a particular camera, a particular team, a particular recording method. That is fixable at the source rather than in the configuration.

Consider whether you need video at all

Video is expensive to store, convert and serve, and much of what people upload as video would be better as photographs. Worth asking before enabling it broadly.

Worked example

An organisation collecting inspection footage found conversions failing for one team, who were recording on a device that captures no audio. The check was already on, so the failures were visible and were resolved by adjusting the conversion configuration rather than being found months later.

Recommendations

• Leave the check on.
• Test with a silent video deliberately.
• Say what is supported next to the upload field.
• Look for a common source behind repeated failures.