Skip to content

Media Transcoding Presets

CRUD screen for TranscodingProfile — list + create/edit, across all three categories (video/image/document) in one shared form.

  • Components: PlayoutAdmin/src/components/media/pages/TranscodingProfileList.jsx, PlayoutAdmin/src/components/media/sections/ProfileEditSheet.jsx
  • Backend reference: domain/media — schema, renditions vs settings, passthrough convention, and versioning are all documented there, not here

Not the same thing as Playback domain's own TranscodingPreset CRUD (live channel ABR ladders) — separate table, separate screen. See domain/media § Data Model.

API calls used

Call Used for Notes / limitation
GET /media/transcoding-profiles?category=<video\|image\|document> List page, one category tab at a time Ceiling/Type columns are computed client-side from renditions — the API doesn't return a pre-labeled type.
POST /media/transcoding-profiles Create category required, immutable after creation from this UI. Video requires renditions; image/document require settings (a real object — an explicit {} is how Passthrough is sent, never omitted).
GET /media/transcoding-profiles/:id/versions Version history list, shown on edit Read-only.
PUT /media/transcoding-profiles/:id?note=<changeNote> Edit Always creates a new version server-side — this form never sends a request that mutates a version in place. Existing Media rows keep whichever version they were processed with.

Full request/response schema, the renditions vs settings shape per category, and the passthrough detection rule the backend applies to whatever this form submits: domain/media and its OpenAPI spec.

Limitations

  • Category is locked after creation — no in-place conversion between video/image/document; would require delete + recreate.
  • No delete from this screen — only create/edit. The list shows assetCount, so a delete would need a guard (block or warn if assetCount > 0).
  • "Set as default for this category" is create-only — can't change the default after the fact from this form.
  • Passthrough detection on edit is a frontend heuristic (looksLikePassthrough: non-video category + absent settings on the fetched profile), not a stored flag — matches the backend's own parsed-fields check today, but could diverge if another writer starts saving profiles with partially-zeroed settings.

Save flow

sequenceDiagram
    participant Admin
    participant Sheet as ProfileEditSheet
    participant API as CoreAPI

    Admin->>Sheet: open (create or edit)
    alt editing
        Sheet->>API: GET /media/transcoding-profiles/:id/versions
        API-->>Sheet: version history
    end
    Admin->>Sheet: fill category-specific fields (renditions OR settings)
    Admin->>Sheet: toggle Passthrough (image/document only)
    alt create
        Sheet->>API: POST /media/transcoding-profiles {name, category, container?, renditions|settings}
    else edit
        Sheet->>API: PUT /media/transcoding-profiles/:id?note=... {renditions|settings}
        Note over API: always inserts a new TranscodingProfileVersion
    end
    API-->>Sheet: updated profile
    Sheet-->>Admin: onSaved() → list re-fetches

container is only shown/sent for category=video — hidden entirely for image/document, since nothing in their pipelines reads it (see domain/media for confirmation it's unused even in video's current pipeline, and is a candidate for removal there).