Skip to Content
BackendMedia and AI Pipelines
Media lifecycle

Capture stays responsive. Heavy work moves off the request path.

The browser owns live capture; R2 owns media bytes; Postgres owns durable state; workers and providers create derivatives, speech, translations, and evidence-grounded summaries.

Recording pipeline

01
Capture in the browser

MediaRecorder and the composition canvas create a master WebM while optional clean source tracks remain available for local download or editing.

02
Choose local or cloud behavior

Guest and free sessions download locally. Paid sessions can upload after the API confirms entitlement and storage capacity.

03
Upload safely

Small files can use multipart form upload. Larger recordings use an initiate → signed part URL → complete/abort multipart R2 flow.

04
Create durable metadata

The server inserts or updates the tenant-owned recording and, when enabled, creates a processing manifest/job.

05
Process derivatives

Workers can create optimized WebM/MP4, HLS, thumbnails, waveform, duration, manifests, clips, versions, and requested exports.

06
Publish authorized playback

Authenticated or public share routes authorize the viewer, then return signed/gateway delivery without exposing R2 credentials.

Processing state

recording_processing_jobs tracks queued, dispatched, running, completed, and failed work. Reliability behavior includes:

  • Worker heartbeat/liveness rows.
  • Lease timestamps and stale-running recovery.
  • Bounded retries with failure persistence.
  • Idempotent object keys and processing manifests.
  • Separate acceptance and staging-gate scripts for upload, processing, egress, R2 CORS, and playback caching.

The UI should surface a meaningful state—uploading, processing, ready, failed, or retrying—instead of assuming the final file exists immediately after upload.

Live speech-to-text

Translation

Live translation crosses a server-side provider boundary. The production target uses NVIDIA NIM only for translation; errors are surfaced instead of silently routing to an undeclared local translation provider. Participants choose their own display language, and translated caption history can be retained with a saved meeting when the plan and visibility settings allow it.

The product distinguishes:

  • Original speech recognition.
  • Original-language caption correction and timing.
  • Translation into the viewer’s selected language.
  • Bilingual vs translated-only display.
  • Durable transcript/translation storage vs ephemeral live captions.

Meeting summaries

Meeting summaries are independent, resumable background jobs:

  1. The owner enables caption capture for selected intervals.
  2. Transcript entries are persisted with room ownership and timing.
  3. Closing an entitled transcript queues summary work.
  4. A worker claims bounded blocks, saves progress, renews leases, and retries failed work.
  5. NVIDIA NIM produces evidence-grounded block summaries and a final professional brief.
  6. The owner sees status and can explicitly regenerate when entitled.

The summary contract includes traceable transcript context and structured output such as overview, topics, decisions, action items, risks, and follow-up. Missing evidence should remain missing rather than being invented.

Recording intelligence

Deterministic transcript processing provides normalization, title, summary, chapters, action items, and search text without requiring an external AI provider. An optional OpenAI Responses API path can provide richer structured intelligence and recording Q&A when explicitly configured and allowed by the aiSummaries capability. Deterministic behavior remains the fallback.