Concurrent playback workloads
Concurrent playback capacity depends on the combined resource demands and timing of the actual session plans rather than only on a stream count.
A stream count says how many sessions exist. It does not say what work they require. A copied original source, an audio-only conversion and an HDR picture conversion have different processing and delivery demands.
Capacity needs the combined plans and their relevant shared resources.
An original resource-demand model
Let one unit represent each resource's available capacity. Use these invented per-session demand fractions:
| Session type | CPU | Video encoder | Storage | Network |
|---|---|---|---|---|
| A, lighter picture conversion | 0.15 | 0.20 | 0.05 | 0.08 |
| B, filter-heavy conversion | 0.45 | 0.40 | 0.10 | 0.15 |
| D, original-source playback | 0.01 | 0.00 | 0.04 | 0.12 |
The values are not benchmarks. They assume independent linear demand on the stated resources, solely to illustrate capacity reasoning.
One B plus two A sessions totals 0.75 CPU, 0.80 encoder, 0.20 storage and 0.31 network. It fits each declared unit capacity.
Two B plus three A sessions demand 1.35 CPU and 1.40 encoder, even though storage and network demand remain below one unit.
A demand above one means the model requests more than the available service. It is not a claim that an observed utilisation percentage can physically exceed 100%.
The most constrained sum controls the result
Unused network capacity cannot substitute for missing encoder service. Likewise, a powerful encoder does not create additional storage throughput.
Four D sessions in the same model require no video encoder demand but still add CPU, storage and network work. Direct Play is therefore a lighter conversion path, not zero shared-resource demand.
The media source matters too. Selecting another existing compatible representation can change both conversion and delivered bitrate. The resulting workload should be assessed for the selected session plan.
Starts and seeks are bursts
Several steady sessions can be healthy while simultaneous startup creates more contention. Opening resources, initialising codecs, preparing first output and filling buffers concentrate work in another interval.
Seeking can introduce another burst or restart. A previously comfortable buffer lead does not necessarily describe the newly requested destinations.
Throttling can reduce unnecessary future production after enough lead exists. It does not eliminate the need to obtain the first usable intervals for sessions that start together.
Real workloads need more evidence than linear addition
Actual stages can share engines, threads, memory paths or scheduling policies. Content difficulty varies over time, and a job's active demand can change when its output is throttled.
The original fractions provide a transparent model, not a universal estimator of how many Emby sessions a system supports. Observed tests need the actual sources, selected tracks, processing paths and time intervals.
See Also
- Transcoding bottlenecks
- Real-time transcoding and playback deadlines
- Direct Play in Emby
- Transcode throttling and producer lead
- Media source selection for playback