Five stages, each a separate program. An ingest process takes the source feed. An encoder turns raw video into H.264 or HEVC. A transcoder produces the lower rungs so a phone on cellular gets something it can play. A packager cuts the encoded output into short segments and writes a manifest listing them. Finally your player fetches the manifest, requests segments in order and decodes them, ideally on the device's hardware decoder rather than the CPU. The player is the only stage you install. Everything upstream belongs to the service, which is why switching apps fixes interface problems and almost never fixes video that stops.

1. 1Ingest: source feed arrives
2. 2Encode: raw video becomes H.264 or HEVC
3. 3Transcode: lower rungs for weaker connections
4. 4Package: segments plus a manifest
5. 5Player: fetch, decode, display

A live stream is not a continuous pipe. The packager writes segments of roughly six seconds and the player keeps a small queue of them. Anything that interrupts delivery for less than the queue length is invisible; anything longer becomes a visible freeze, because there is nothing left to play. This is why latency behind a broadcast is measured in seconds rather than milliseconds, and why a stream can stall while a speed test still reports plenty of headroom. It also explains the buffer setting. A larger buffer hides more jitter but adds delay, while setting it to none reduces lag and often helps on a stable connection. Neither setting creates bandwidth the line does not have.

Map the symptom to the stage before changing settings. One channel broken while the rest play is a source or ingest problem at that single feed. A whole group failing points at the server side rather than your house. Everything stalling at once is the line, the player or a dead session, and switching away to another channel and back is the test that separates them, because recovery on switch-back means the session stalled and bandwidth was never the cause. Audio without video, or video that plays in one app but not another, usually means the decoder: the device cannot handle that codec profile in hardware. Crashes right after an app update are their own recurring cause and are worth ruling out first.

Codec choice sets the bandwidth bill. H.264 is the safe default because nearly every device decodes it in hardware. HEVC delivers comparable quality at roughly half the bitrate, which is why 4K feeds lean on it, but older sticks and some TV apps fall back to software decoding, then run hot and drop frames. Practical numbers: 4K runs about 15-25 Mbps, 1080p about 5-8 Mbps. If a 4K feed stutters while the 1080p version of the same channel is clean, you have found a decoder or bandwidth ceiling rather than a broken service. Telling your player to prefer the lower rung is a legitimate fix, not a compromise, on a screen under 55 inches.

Roughly 7 GB an hour at 4K and about 3 GB an hour at 1080p. Four hours of evening viewing in 4K lands near 28 GB, which matters on a metered connection or a rural plan with a cap. A household using 1-5 simultaneous connections multiplies that, so two 4K streams plus a tablet can pass 40 GB in an evening. Most people never look at this until an overage notice arrives. If your plan is capped, set secondary screens to prefer 1080p; the difference is hard to see on a bedroom TV and it roughly halves the data. A library of 219,577+ VOD titles is easy to work through without noticing the running total.