Ask three engineers how video should get from an application to a website, and you will usually get five protocols, two arguments, and one whiteboard full of arrows that look like a subway map designed during a power outage. Video delivery has that effect on people. Everything sounds simple until someone says, “Let us just stream it to the browser,” and suddenly the room is full of RTSP, HLS, WebRTC, SRT, transcoding, and regret.
The real problem is that people often treat video delivery as one task when it is actually three. First, the application has to send video somewhere. Second, the server has to receive it and decide what to do next. Third, the viewer has to play it on a website, in a mobile app, or in an operator console. These are related problems, but they are not the same problem. The architecture only starts to make sense when those layers are separated.
A good streaming system is rarely built around one universal protocol that does everything well. It is built around the much less glamorous idea that each stage has its own job. The application publishes the stream. The media server handles the stream. The client receives the stream in whatever format makes sense for that platform. It is not magic. It is division of labor, which remains one of the few engineering ideas that still works as advertised.
Start at the source, not at the player
The usual mistake is to begin with the website player. Teams start comparing browser technologies, player libraries, and page latency before they have even decided how the source application will publish the stream. That is like shopping for a garage door before you have built the house.
The first real decision is always the source side. How will the desktop application send video outward? Will it push a continuous stream to a media server? Will it generate segments itself? Will it use a protocol designed for stable local networks or one built to survive the internet’s daily mood swings?
Once that question is answered, the rest of the architecture becomes clearer. The publishing protocol does not need to match the viewing protocol. In fact, it often should not. A format that is convenient for a desktop application to send is not automatically suitable for a browser to receive. That is why the healthiest designs usually work in two stages. First, the application sends video to a media server. Then the media server repackages or transcodes that video for the final client.
The three roles every sane architecture needs
A stable streaming system usually has three distinct components.
The first is the source. This can be a desktop application, an agent, or any process generating live video. Its job is to publish the stream and move on.
The second is the media server. This is the middleman with actual responsibilities. It accepts incoming video, repackages it when possible, transcodes it when necessary, and redistributes it in formats suitable for browsers, mobile apps, or other clients.
The third is the application server. This is where authentication, permissions, interface logic, stream selection, session handling, and business rules belong. It is not there to act like a live encoder with delusions of grandeur.
This separation matters because media workflows become fragile when one component tries to do everyone else’s job. A desktop client should not become a miniature CDN. A web backend should not pretend it is a full media pipeline unless that was the plan from day one. When each layer stays in its lane, the system becomes easier to scale, easier to debug, and much less likely to collapse under the weight of one extra feature request.
RTSP and RTP still matter, but not where people want them to
RTSP and RTP are often the first protocols people mention, especially in video surveillance and network camera environments. That is not surprising. RTSP has been around forever, cameras speak it fluently, and many devices treat it as their natural language. RTP, meanwhile, remains a common transport inside professional real-time media systems.
The problem is not that they are bad. The problem is that people keep trying to drag them directly into browser playback and then act surprised when the browser reacts like it was handed a VHS tape.
RTSP is useful between devices and servers. It is a practical ingestion protocol for cameras, encoders, and recorders. But as a final playback format for a website, it is awkward. Browser support is poor, NAT traversal is messy, and provider filtering can make internet delivery unreliable. Once you try to make RTSP behave nicely in a web player, you usually end up adding proxies, converters, gateways, or other creative devices whose main purpose is to apologize for RTSP’s presence.
RTP is similar. It is perfectly at home inside controlled environments, but it is not a friendly direct answer for web playback. It needs help. Often a lot of help.
That makes RTSP and RTP useful inside the pipeline, but rarely ideal at the edge where users actually watch video.
Why RTMP refuses to die
RTMP has been declared obsolete so many times that it now qualifies as vintage infrastructure. Yet it continues to survive because it still solves a practical problem very well: publishing a stream from an application to a server.
RTMP is simple. The model is familiar. The tooling is mature. For a desktop application that needs to send video reliably to a media server, RTMP is still one of the easiest options to implement and maintain. You point the application at the server, give it a stream key, and the stream goes where it should. There is value in that kind of boring predictability.
Its weakness is on the delivery side, not the ingest side. RTMP is no longer a great format for browser playback, and few architects truly want it to be. But as an input protocol, it remains perfectly respectable. A desktop application can publish in RTMP, and the media server can then turn that stream into HLS or WebRTC for actual viewers.
This is why RTMP keeps showing up in real systems. Not because it is trendy, but because it still knows how to get the job done without writing a memoir about the experience.
Why SRT often makes more sense over the internet
If RTMP is the dependable old workhorse, SRT is the protocol that shows up wearing boots and carrying tools. It was designed for real networks, not theoretical ones. That matters.
Once video has to cross unstable links, remote sites, provider filtering, jitter, packet loss, or all the other features the internet generously includes at no extra charge, SRT starts looking very attractive. It is built to handle difficult conditions better than simpler publishing protocols. In environments where the application and server are separated by geography, carrier networks, or plain bad luck, SRT is often the stronger choice.
This does not mean RTMP becomes useless. It means the decision depends on the network. If the path between application and server is short, controlled, and predictable, RTMP may be the simplest solution. If the path is long, noisy, or unreliable, SRT usually looks like the more professional answer.
For modern systems with remote publishers, distributed sites, or nontrivial network conditions, SRT has become one of the best candidates for ingest.
HLS is great for viewers and annoying for publishers
HLS is one of the most practical formats for website playback because it fits naturally into web infrastructure. It runs over ordinary HTTP, works well with caching and proxies, and scales far more gracefully than lower-latency alternatives. If the goal is to serve many viewers through a website with a reasonable level of operational calm, HLS is hard to beat.
The trouble begins when someone decides the desktop application should generate HLS directly.
That sounds efficient on paper. In practice, it means the application must encode the stream, split it into segments, maintain a playlist, delete expired media chunks, publish new ones continuously, and keep everything synchronized. In other words, the application stops being a publisher and starts moonlighting as a small media server. This is rarely the path to peace.
Direct HLS from the source can work in narrow scenarios, but in most serious systems it is the wrong layer doing the wrong work. It is usually cleaner to let the application publish a continuous stream through RTMP or SRT and let the media server generate HLS on the output side.
HLS is best treated as a delivery format, not as the thing your desktop application should lovingly assemble file by file in the middle of a busy workday.
Where WebRTC earns its reputation
WebRTC enters the conversation when latency matters more than comfort. If the viewer needs video that feels almost live, WebRTC is often the right answer. It is the technology people reach for when a delay of several seconds is unacceptable, as in operator consoles, interactive monitoring, or two-way communication scenarios.
That speed, however, is not free. WebRTC is more demanding on the server, more complex in networking terms, and generally less pleasant to scale to large viewer counts than HLS. It is excellent when responsiveness matters most, but it is rarely the cheapest or calmest choice for large-scale public delivery.
That makes WebRTC a powerful specialist rather than a universal default. It belongs in designs where low latency is the top priority. It does not belong in every architecture just because someone likes the phrase “real time.”
The codec problem nobody enjoys discussing
Protocols get the headlines, but codecs often decide whether the architecture will behave or file a complaint.
H.264 remains the most practical codec for broad web playback. It is widely supported, well understood, and generally accepted by browsers and playback frameworks without drama. It is not exciting anymore, but infrastructure tends to prefer mature adults over gifted children who keep breaking furniture.
H.265 is more efficient and can offer better compression, which makes it attractive for storage and transport. The problem is compatibility. Browser support is inconsistent, WebRTC support is even less comfortable, and the moment a website player needs H.264 while the source arrives in H.265, transcoding enters the story.
That is where the budget starts sweating.
Why H.265 can quietly become a server problem
If the source application publishes H.265 and the final viewer needs H.264, the media server cannot solve that by simple repackaging. It must fully decode and re-encode the stream. That is expensive.
One or two streams may be manageable. A few dozen begin to matter. At larger scale, this becomes one of the defining infrastructure costs in the entire system. Without hardware acceleration, transcoding many simultaneous streams is less an architectural feature and more a controlled fire.
That is why architects need to think about codecs early, not late. If the final target is a browser, especially through WebRTC, then standardizing on H.264 earlier in the pipeline can save enormous processing cost on the server. Pushing H.265 all the way to the center of the system and only then discovering that browsers are not cooperative is a classic way to turn a media server into an expensive room heater.
The common architecture patterns
One of the most sensible patterns is application to RTMP or SRT, then media server to HLS, then website playback. This is stable, scalable, and easy to justify. The application publishes with a straightforward protocol, the media server prepares HLS, and the browser receives something it understands. Latency is not minimal, but the design is usually robust and friendly to larger viewer counts.
A second strong pattern is application to RTMP or SRT, then media server to WebRTC, then website playback. This is the choice for lower latency. It delivers faster video to the end user, but the media server pays for it in complexity and load. This is often the right answer for control rooms and operator-facing systems, not necessarily for general public distribution.
A third pattern, less common but sometimes useful, is direct HLS generation by the application and delivery through ordinary HTTP storage. It can work in tightly constrained scenarios, but it puts too much responsibility on the source side and usually ages poorly as the number of streams increases.
In practice, the most successful systems are rarely the cleverest. They are the ones that keep the source simple, the media pipeline centralized, and the client delivery tailored to the actual platform.
HLS for scale, WebRTC for speed
The old tradeoff remains true. HLS is easier to scale. WebRTC is faster.
If a website needs to serve many viewers with predictable infrastructure cost, HLS is usually the safer option. It fits naturally into caching layers, CDNs, and standard web delivery models. The downside is latency, which is typically measured in seconds rather than fractions of a second.
If a viewer needs near-live response, WebRTC is often the better answer. But that performance comes with more operational pressure. The server has more work to do, network behavior becomes more sensitive, and viewer growth becomes harder to absorb cheaply.
This is not a philosophical question. It is a business and engineering tradeoff. Scale or speed. Calm or immediacy. In many systems, both are needed, which is why some architectures provide HLS for general viewing and WebRTC for operator screens.
Why mobile apps change the picture
Things become more interesting when the viewer is not a browser but a native mobile application. Browsers live within a specific set of restrictions around codecs, playback APIs, and transport behavior. Native apps have more freedom. They can use platform decoders directly, support formats that browsers do not, and make more efficient use of device capabilities.
That can reduce the amount of server-side transcoding required. A stream that is inconvenient for a website might be perfectly acceptable in a mobile app. This means the mobile path can sometimes be lighter and cheaper than the browser path, even when both viewers are watching the same source content.
Still, native apps do not make network problems disappear. Sending raw RTSP or RTP over the public internet to phones is still a good way to rediscover why media engineers keep antacid tablets nearby. A server-side media node usually remains useful. The difference is that the mobile client may allow a less painful codec and delivery strategy than a browser would.
This is why mobile should be treated as its own client category, not as a browser with nicer icons.
What a practical choice looks like
If the goal is a reliable website with normal latency and sensible scalability, the most defensible choice is usually RTMP or SRT on ingest and HLS on delivery. RTMP fits simple and stable environments. SRT is the better option when the network is difficult or remote.
If the goal is low latency, then RTMP or SRT on ingest and WebRTC on delivery becomes more attractive. That design is faster, but it also demands stronger server planning, more attention to codecs, and more careful scaling.
If the incoming stream is H.265 and the final audience is in a browser, then the transcoding cost must be calculated before anyone starts drawing pretty architecture diagrams. If that cost is ignored, the project will eventually rediscover it the expensive way.
If a native mobile app is part of the platform, it should have its own delivery strategy. That can save processing power, reduce conversion overhead, and open the door to more flexible codec handling.
The part everyone learns eventually
There is no universal best protocol because there is no universal best job. RTSP and RTP are still useful inside device and server environments. RTMP remains a practical way to publish from applications. SRT is often the strongest ingest protocol when the network is less than ideal. HLS continues to be the safe choice for broad website delivery. WebRTC remains the answer when delay matters more than convenience. H.265 is efficient, but it can trigger compatibility and transcoding costs the moment a browser enters the story.
Good video architecture is not built by falling in love with one protocol and forcing it into every room of the house. It is built by answering three boring but essential questions. How will the source publish the stream? What must the media server do with it? And where will the viewer actually watch it?
Once those answers are clear, the architecture usually stops looking mysterious. And that is a genuine achievement in streaming, a field where even simple diagrams often look like they were assembled by someone trying to escape through the ceiling.