Video fundamentals / Technical guide
Understanding Video Bandwidth
“It is only one video file” says almost nothing about the load it places on a system. A playback machine must read, decode, process and output that file in real time. Resolution matters, but frame rate, bit depth, chroma sampling, codec and the number of simultaneous streams can matter just as much.
Bandwidth has more than one location
Storage bandwidth is the rate at which compressed media is read from disk. Decode bandwidth describes the work required to turn that media back into frames. GPU memory and bus traffic increase as frames are processed, composited and sent to outputs. A network adds another limit when media or signals travel between machines.
A fast disk cannot compensate for an unsupported decoder, and a powerful GPU cannot repair a network link that is already saturated.
The variables that change the load
- Resolution: more pixels per frame increase image data.
- Frame rate: more frames must be delivered every second.
- Bit depth: more precision per channel increases data and processing requirements.
- Chroma sampling: 4:4:4 retains more color information than 4:2:2 or 4:2:0.
- Codec: heavy compression can reduce file size while increasing decode complexity.
- Stream count: a codec that plays easily once may fail when twelve files start together.
Compressed data rate is not output data rate
A file may occupy a modest number of megabits per second on storage and still expand into a much larger uncompressed image inside the playback pipeline. That is why internet-delivery bit rates are not a useful sizing rule for a media server.
Conversely, a high-data-rate mezzanine codec can be easier for the CPU or GPU to decode because it was designed for production rather than minimum delivery size. The trade is larger storage and greater sustained read performance.
Estimate, then test the real composition
Begin with the expected resolution, frame rate, codec and data rate for every simultaneous file. Add the outputs, effects, live inputs and any content that starts on the same cue. This creates a useful estimate, but it is not the final proof.
Test on the intended hardware with the actual playback application. Run the busiest section repeatedly, watch frame delivery and storage behavior, and leave headroom for operating-system activity and late content changes. A benchmark of one file in a media player is not a show test.
Delivery questions for content teams
- What is the exact canvas and frame rate?
- Which codec and profile are approved for the playback platform?
- How many files can play at once?
- Is alpha required?
- Will the server crop one large canvas or play independent surfaces?
- What is the deadline for a full-duration validation render?