This documentation describes how a catalog owner integrates with StreamEdge Media: how source files are ingested, how they are transcoded into an adaptive bitrate ladder, how the resulting renditions are cached at the edge, and how a page embeds a player against the resulting manifest.
The pipeline is split into four independent stages: ingest, encode, distribute, and deliver. Each stage can be reasoned about on its own, and each one reports its status separately on the status page.
A minimal integration has three parts:
Source assets are submitted per catalog, one file per asset, along with a small metadata record:
asset_id: night-market-ep04
title: Night Market — Episode 4
source_container: mp4
source_codec: h264
duration_seconds: 1584
library: originals-2026Accepted source containers are mp4, mov, and mkv. Source video should use a progressive (non-interlaced) frame structure; interlaced sources are rejected at ingest with a validation error rather than being silently encoded.
Live channels are ingested as a continuous stream against a scheduled channel identifier rather than a fixed-duration asset. The same encoding profile mechanism applies, but renditions are produced continuously instead of once.
An encoding profile defines the rendition ladder produced for every asset in a library. A typical general-purpose profile looks like this:
profile: general-purpose-v1
renditions:
- height: 360 bitrate_kbps: 800
- height: 480 bitrate_kbps: 1400
- height: 720 bitrate_kbps: 2800
- height: 1080 bitrate_kbps: 5000
segment_seconds: 6
manifest_format: adaptive-hlsRenditions below 480p are optional and can be dropped for catalogs where viewers are known to have consistently fast connections. Segment length affects both start-of-playback latency and cache efficiency; 6 seconds is a reasonable default for on-demand catalogs, while live channels commonly use shorter segments.
| Content type | Suggested top rendition | Suggested segment length |
|---|---|---|
| Long-form on-demand | 1080p | 6 seconds |
| Short-form vertical | 720p | 4 seconds |
| Live event | 1080p | 2–4 seconds |
Once encoded, renditions and their manifest are replicated to regional edge caches ahead of expected demand for popular catalogs, and on first request for long-tail content. A request for an asset is always served from the nearest healthy region; if that region reports degraded status, delivery falls back to the next-nearest region automatically.
Segment files are treated as immutable and cached for long periods. Manifests are cached for a short period so that newly published renditions or corrected metadata become visible without requiring a manual cache clear.
A page embeds playback using a standard HTML video element pointed at the manifest URL for an asset. No platform-specific script is required for basic adaptive playback in browsers with native support for the manifest format:
<video controls poster="night-market-ep04/poster.jpg">
<source src="night-market-ep04/manifest.m3u8" type="application/vnd.apple.mpegurl">
Your browser does not support embedded playback of this asset.
</video>For browsers without native adaptive manifest support, catalogs typically pair this markup with a general-purpose playback library of their own choosing; that choice is outside the scope of this document.
The status page reports current operating status per region across ingest, encoding queue depth, and edge delivery, along with a 30-day uptime overview and a 90-day incident history. There is no separate monitoring API described in this reference set — the status page is the canonical source.
When a region shows elevated encoding queue depth, already-published renditions continue to be served normally from cache; only newly submitted assets in that region experience a longer time to become available.
The reference pipeline described here applies one profile per library for predictability. Per-asset overrides are a common extension for catalogs with mixed content types, but are outside the scope of this reference documentation.
Viewer requests in that region are automatically redirected to the nearest region reporting operational delivery status, as described under Delivery & caching.
At least 90 days, as shown on the status page.
No. Interlaced sources are rejected at ingest time with a validation error, as noted under Content ingest.
For platform health and maintenance information, check the status page. Operational documentation is maintained in this reference section.