LM-Kit OneDocs2026.8.10lm-kit.com
Documents

Audio and Video Transcription

POST /lmkit/v1/audio-transcription turns spoken content into text with a local speech model: recordings, meetings, voicemails, and, when ffmpeg is present on the server, video files directly, whose audio track is extracted and transcribed in place. The response carries the full transcript and an average confidence score, and nothing ever leaves the machine, which is the whole point of transcribing interviews, support calls, and internal meetings here.


1Three ways to send the recording#

The recording is... Send it as Why
Small, already in your hands JSON body with input_format Base64EncodedFile One self-contained call; base64 inflates the file by a third and is buffered whole, so keep it for short clips
Large or long Raw multipart upload to POST /lmkit/v1/audio-transcription/file (form field file) Streamed to disk, no inflation: the recommended path
Already on the server JSON body with input_format FileIdentifier naming a fileId from POST /lmkit/v1/files/upload Upload once, transcribe (and process) many times

All three are bounded by the configured Max upload size (default 100 MB) and behave identically past the door. An oversized payload answers 413 with the remedy: use the multipart or upload-first path.

2Video goes in as-is#

With ffmpeg available, video containers (mp4, mov, mkv, webm, avi, and more) are accepted directly: the audio track is demuxed and transcribed. Two honesty contracts keep this predictable:

  • GET /lmkit/v1/audio-transcription/capabilities reports whether ffmpeg is present and the exact list of decodable extensions, so a client decides up front whether to send a recording as-is or transcode it first. Without ffmpeg, the advertised set falls back to the formats the built-in decoders guarantee on every platform.
  • A video that declares no audio track answers 422 with that reason, up front, instead of a cryptic decoder failure minutes into the job.

3Long recordings ride the jobs contract#

Transcription time follows recording length. When processing exceeds the configured sync timeout, the call answers 202 Accepted with a job_id; poll GET /lmkit/v1/jobs/{job_id} for progress and the finished transcript, or force the async path from the first byte with the Prefer: respond-async header. The contract, its retention, and its failure taxonomy are Errors, Retries, and Jobs.

4Choosing the model#

The request's optional model field names a speech model by its catalog id; omitted, the server's default speech model answers (the default-model slots live in the admin console, and the catalog carries speech models in several sizes, trading speed for accuracy). Everything about capacity, memory, and concurrent load is the same inference capacity story as every other model here.

5The same capability, other doors#

6When something refuses#

Symptom Meaning Remedy
413 on the JSON endpoint The base64 body outgrew the upload ceiling Send the raw file to /audio-transcription/file, or upload once and pass the fileId
422 naming a missing audio track The video's own structure declares no audio There is nothing to transcribe; check the source file
A format is rejected ffmpeg is absent on the server The capabilities route lists what decodes today; install ffmpeg or transcode client-side
404 on a FileIdentifier The upload expired or the id is wrong Uploads live on a retention clock (Where Data Lives); re-upload

7Stated plainly#

  • One endpoint, three doors: inline base64 for clips, multipart for real recordings, upload once and reference for pipelines.
  • Video is a first-class input when ffmpeg is present, and the capabilities route tells you the truth about the decodable set before you send anything.
  • Long recordings become jobs instead of timeouts, and every refusal names its remedy.
  • Transcripts stay local and feed the rest of the platform: analysis, search, and agents.