When you open a live harbor cam and see a fishing boat sliding into port, that picture has crossed a surprising amount of technology in a few seconds. The same chain sits behind YouTube Live, a city’s traffic site and a hotel’s rooftop webcam. Once you can see the chain, everyday questions get easy answers: why a stream is delayed, why it sometimes drops to a blurry picture, why some cameras play on a phone but not on a website.
This page walks through every step, with a diagram, a protocol table and a latency comparison.
The whole chain in one picture
The good news for camera owners: you only have to get the first two steps right. Platforms such as YouTube handle the expensive part, serving the video to every viewer, for free.
Step 1: The camera captures
Light passes through the lens onto a sensor that records millions of pixels many times per second. A 1080p frame has about 2 million pixels; a 4K frame about 8 million. At 30 frames per second, raw 1080p video would be well over a gigabit per second, far too much to send anywhere. So the next step is essential. If you want the hardware side, see IP cameras explained.
Step 2: The encoder compresses
An encoder shrinks the video by hundreds of times using a codec. The universal codec is H.264 (AVC); H.265 (HEVC) saves roughly half the data at similar quality but is less universally supported, and AV1 is newer still. Codecs work by sending a full picture now and then (a keyframe) and, in between, only what changed. A still harbor view compresses beautifully; waves, rain and swaying trees need more data.
The encoder can be:
- Inside the camera, which almost every IP camera has. Some can also push a stream straight to a platform.
- A software encoder such as OBS on a computer, which pulls the camera’s RTSP stream and pushes it on.
- A small hardware encoder or a media server box that does the same job without a PC.
Two encoder settings matter most: the bitrate (data per second, see the bitrate calculator) and the keyframe interval. YouTube recommends a keyframe every 2 seconds and no more than 4.
Step 3: Ingest: getting the stream to a server
The encoded stream now travels over your internet connection to the platform’s ingest server. This is the only part of the journey that uses your upload bandwidth, and only one copy goes up no matter how many people watch.
Common ingest protocols:
- RTMP / RTMPS: the long-time standard for pushing live video to YouTube, Twitch and Facebook; RTMPS adds encryption. See RTMP explained.
- SRT: a newer protocol built to survive lossy, jittery connections such as 4G. YouTube lists SRT among options supported by some verified encoders.
- HLS ingest: YouTube also accepts HLS, which helps with newer codecs.
RTSP is usually not used here. RTSP is how recorders and software on your own network pull video from the camera. See RTSP explained.
Step 4: Transcode and package
The platform decodes your stream and re-encodes it into several qualities, for example 1080p, 720p, 480p and 360p. This “ladder” lets every viewer get the best quality their connection can handle. Then it packages each quality for delivery to browsers and apps.
The dominant web format is HLS (HTTP Live Streaming), published by the IETF as RFC 8216. HLS cuts video into short files called segments and lists them in a playlist that the player keeps re-reading. Apple’s HLS authoring specification recommends a target segment duration of 6 seconds. Because segments are just ordinary files over HTTPS, they can be cached and served by the same infrastructure that serves web pages, which is why HLS scales to millions of viewers. A similar format, MPEG-DASH, works the same way.
For very low delay, some services use WebRTC, the technology behind browser video calls, which can deliver video in under a second.
Step 5: CDN and player
A content delivery network keeps copies of the segments on servers in many cities. When you press play, your player fetches the playlist and segments from the nearest one. The player measures your connection and switches quality up or down as you go, which is why a stream sometimes turns blurry for a moment and then sharpens. That is called adaptive bitrate streaming.
On LiveLocation, we use the player the camera owner chose: YouTube’s embedded player, a road agency’s official stream, or a provider’s widget. We never re-host or record the video. See how to embed a live camera on your website.
Protocols at each step
| Protocol | Where it is used | Who starts the connection | Plays in a browser? | Typical delay |
|---|---|---|---|---|
| RTSP / RTP | Camera to recorder or software on a local network | The viewer pulls from the camera | No | Under 1 to 2 s |
| RTMP / RTMPS | Encoder to platform (ingest) | The encoder pushes | No (no longer) | A few seconds to ingest |
| SRT | Encoder to platform over unstable links | Either side | No | Configurable, often 1 to 3 s |
| HLS / DASH | Platform to viewers | The player pulls segments | Yes | Often 10 to 30 s |
| Low-Latency HLS | Platform to viewers | The player pulls partial segments | Yes (support varies) | Often a few seconds |
| WebRTC | Server to viewers, real-time | Negotiated | Yes | Under 1 s |
Delays are typical ranges, not guarantees; they depend on settings and networks.
Why live streams are delayed
Delay (latency) builds up a little at every step:
- Encoding: the encoder holds a few frames to compress them well.
- Upload: the stream crosses your connection to the ingest server.
- Transcoding: the platform re-encodes into several qualities.
- Segmenting: HLS must finish a segment before anyone can download it; with 6-second segments, that alone is several seconds.
- Player buffer: players usually wait for a few segments before starting, so a hiccup does not freeze the video.
For a scenic webcam, a 20-second delay does not matter: the sunset is the same sunset. For a sports event or a two-way conversation, it does, which is why platforms offer low-latency modes. YouTube, for example, lets you choose a latency setting for each stream; lower latency gives viewers less buffer, so it can mean more stalls on weak connections.
When a stream goes wrong: where in the chain?
Knowing the chain makes troubleshooting much faster. Match the symptom to the step:
| Symptom | Likely step | What to check |
|---|---|---|
| Stream keeps disconnecting | 3, ingest | Upload speed dips; lower the bitrate or use a wired connection |
| Picture is blocky in rain or waves | 2, encoder | Bitrate too low for a busy scene; raise it a little or lower resolution |
| Platform warns about keyframes | 2, encoder | Set the keyframe interval to 2 seconds |
| Viewers see buffering, you see fine | 5, CDN/player | Viewers’ connections; offer lower qualities (the platform usually does) |
| Stream works, website embed is blank | 5, player | Embedding disabled, wrong embed code, or blocked by consent settings |
| Stream stops at night | 1, camera, or power | Camera reboots when IR turns on; check PoE power and the UPS |
Snapshots: the lightweight alternative
Not every camera needs a video stream. Many weather, ski and traffic cameras upload a still image every minute or few minutes instead. The camera sends a JPEG to a web server by FTP or HTTPS, and the web page simply shows the latest picture. It uses a tiny fraction of the data, works on very slow links, needs no streaming platform and is easy to turn into a time-lapse. The trade-off is obvious: no motion, no sound, and the picture is always a little old. On LiveLocation, snapshot cameras are labeled with the age of their latest image, so you always know what you are looking at.
Pull vs push: a security point
There are two ways for a stream to leave a site:
- Pull: something on the internet connects into your network and asks the camera for video. That needs an open port, which is risky. See port forwarding vs P2P.
- Push: the camera or encoder connects out to a platform and sends the video. Nothing outside can start a connection to your camera. This is the safe default for public webcams.
Push out with RTMPS, keep the camera’s own interface private, and follow the camera security checklist.
What you need at the camera site
| Item | Why | Typical choice |
|---|---|---|
| Camera | Captures and usually encodes | Wired PoE IP camera |
| Encoder (if the camera can’t push) | Pulls RTSP, pushes RTMPS | OBS on a small PC, or a hardware encoder |
| Internet upload | Carries one copy of the stream | Bitrate plus 50% headroom |
| Platform | Ingest, transcoding, CDN, player | YouTube Live, or a paid streaming service |
| Power backup | Keeps the stream up in short outages | Small UPS for router, switch and encoder |
Our step-by-step guide, how to stream an IP camera to YouTube 24/7, puts all of this together.
Do these next
- Work out your bitrate and upload speed.
- Set up the push to YouTube.
- Submit your stream to LiveLocation.
Questions people ask
How does a live camera stream work?
The camera captures and encodes video, an encoder pushes it to a streaming server, the server transcodes it into several qualities and packages it (usually as HLS), and a CDN delivers it to each viewer’s player.
Why is my live stream 20 seconds behind?
Delay builds up at every step: encoding, upload, transcoding, cutting video into segments and the player’s buffer. Standard HLS streams are often 10 to 30 seconds behind; low-latency modes reduce that.
Do I need an encoder to stream a camera?
Every stream needs an encoder, but most IP cameras have one built in. You need a separate software or hardware encoder only if the camera cannot push a stream to your platform itself.
Does more viewers use more of my upload?
No, not when you use a platform. You upload one copy; the platform and its CDN serve every viewer.
What is HLS?
HTTP Live Streaming, an IETF-published format (RFC 8216) that cuts video into short segments listed in a playlist, delivered over normal HTTPS. It is how most live video reaches browsers and phones.
Sources
- RFC 8216: HTTP Live Streaming (IETF) (checked 2026-10-07)
- Apple: HLS authoring specification for Apple devices (checked 2026-10-07)
- RFC 7826: Real-Time Streaming Protocol Version 2.0 (IETF) (checked 2026-10-07)
- YouTube Help: Choose live encoder settings, bitrates and resolutions (checked 2026-10-07)
- YouTube Help: Create a live stream with an encoder (checked 2026-10-07)
- Adobe RTMP Specification 1.0 (2012), archived copy (checked 2026-10-07)
Last reviewed October 7, 2026 by the LiveLocation team. General information, not legal or electrical advice.