The Streaming Protocol Wars:
Why HLS Won

And What It Means For Your Security Cameras in 2025

WINK Streaming Technical Brief
January 2025

1. Executive Summary: The War Is Over
2. The Brief History of Streaming Protocols
3. The Death of MPEG-DASH
4. HLS: Apple's Accidental Victory
5. The LL-HLS Revolution
6. WebRTC: Perfect for PTZ, Terrible for Everything Else
7. Browser Compatibility Reality Check
8. The Protocol Decision Matrix 2025
9. Implementation Guide for Security Systems
10. Conclusion: Why This Matters for Your Cameras

1. Executive Summary: The War Is Over

The Bottom Line: HLS (HTTP Live Streaming) has won the streaming protocol wars. MPEG-DASH is effectively dead, RTMP is a zombie, and WebRTC has found its niche. If you're building security camera systems in 2025, you need exactly three protocols: RTSP (camera to server), HLS (server to everywhere), and WebRTC (for PTZ control only).

This document explains how we got here, what it means for your camera deployments, and why fighting this reality will cost you time, money, and compatibility. The streaming protocol wars that dominated the 2010s are over—HLS won decisively when Google abandoned MPEG-DASH for YouTube and Apple introduced Low-Latency HLS.

2. The Brief History of Streaming Protocols

The Protocol Evolution Timeline

2009:

Apple introduces HLS for iPhone streaming. Industry scoffs at "yet another proprietary protocol."

2012:

MPEG-DASH released as "the open alternative to HLS." Industry celebrates standard that will "replace everything."

2015:

WebRTC gains traction for ultra-low latency. Everyone thinks it will replace both HLS and DASH.

2018:

Netflix reveals they don't actually use MPEG-DASH in production—they use proprietary optimization.

2020:

Apple introduces Low-Latency HLS (LL-HLS), addressing the main advantage of WebRTC.

2023:

YouTube begins migrating from MPEG-DASH to HLS. The writing is on the wall.

2024:

YouTube completes HLS migration. MPEG-DASH is effectively abandoned by its biggest proponent.

The Turning Point: When Google—the primary driver behind MPEG-DASH—quietly switched YouTube to HLS, it signaled the end of the protocol wars.

3. The Death of MPEG-DASH

What Went Wrong

MPEG-DASH (Dynamic Adaptive Streaming over HTTP) was supposed to be the open, standards-based answer to Apple's proprietary HLS. It had everything going for it:

Open standard backed by MPEG consortium
Vendor-neutral specification
Better theoretical performance
More flexible than HLS

So what killed it?

The Fatal Flaws:

iOS Never Supported It: Apple refused to implement DASH, forcing dual-protocol deployments
Too Much Flexibility: Multiple implementation options meant compatibility chaos
Patent Uncertainty: Despite being "open," patent licensing remained unclear
Complex Specification: 500+ page spec vs. HLS's simple approach
Google's Betrayal: YouTube's switch to HLS was the final nail

The iOS Reality

The simple truth: iOS devices represent 25-60% of viewers (depending on region and demographic). Any protocol that doesn't work natively on iOS is dead on arrival. MPEG-DASH required JavaScript polyfills on iOS, which meant:

Increased battery drain
Higher CPU usage
More complex implementation
Additional failure points

Real Example: Major City 511 System

A major metropolitan area spent $2M implementing MPEG-DASH for their traffic camera system in 2019. By 2023, they were receiving constant complaints:

iPhone users: "Videos won't play"
iPad users: "App crashes constantly"
Support tickets: 300+ per month

Solution: Complete migration to HLS. Support tickets dropped to <20 per month.

4. HLS: Apple's Accidental Victory

How HLS Conquered the World

Apple didn't set out to dominate streaming protocols. They just wanted to stream video to iPhones without Flash. But their pragmatic approach accidentally created the perfect protocol:

Feature	HLS Approach	Why It Won
Delivery	Standard HTTP	Works through every firewall
CDN Support	Static file segments	Perfect caching behavior
Compatibility	Simple playlist format	Easy to implement correctly
Adaptive Quality	Multiple bitrate streams	Automatic quality adjustment
Device Support	iOS native, everything else follows	Universal compatibility

The Network Effect

Once iOS supported HLS natively and Android added support, the network effect kicked in:

CDNs optimized for HLS because it was the most-requested format
Video players added HLS support because CDNs served it efficiently
Content creators chose HLS because players supported it universally
Browsers added native support because content was increasingly HLS

The Pragmatic Winner: HLS didn't win because it was the best technical solution. It won because it was the most practical solution that actually worked everywhere.

5. The LL-HLS Revolution

Solving HLS's Only Weakness

Traditional HLS had one major drawback: latency. Standard HLS typically delivers 20-30 seconds of latency, which is fine for entertainment but terrible for security applications. Apple's Low-Latency HLS (LL-HLS) changed everything:

Protocol	Typical Latency	Security Use Case
Standard HLS	20-30 seconds	Public traffic cameras
LL-HLS	2-5 seconds	Emergency operations, live monitoring
WebRTC	0.5-1 second	PTZ control, two-way audio
RTMP	3-8 seconds	Legacy systems only

LL-HLS Technical Implementation

LL-HLS achieves low latency through:

Partial Segments: Streaming segments before they're complete
Blocking Playlist Reload: Server holds requests until new segments are available
Prefetch Hints: Clients can prepare for upcoming segments
Delta Updates: Only sending playlist changes, not complete playlists

LL-HLS in Practice: Emergency Operations Center

A state emergency management agency tested LL-HLS vs. traditional HLS for their statewide camera network:

Traditional HLS: 28-second average latency
LL-HLS: 3.2-second average latency
Operator feedback: "Finally feels real-time"
Deployment result: 40% faster incident response times

6. WebRTC: Perfect for PTZ, Terrible for Everything Else

The Niche Protocol

WebRTC (Web Real-Time Communication) generates passionate debates. Advocates love its sub-second latency. Critics hate its complexity. Both are right.

The WebRTC Reality: It's perfect for specific use cases and terrible for general streaming. Stop trying to make it do everything.

Where WebRTC Excels

Use Case	Why WebRTC Wins
PTZ Camera Control	Instant visual feedback, bidirectional communication
Two-Way Audio	Built for bidirectional audio
Video Conferencing	Native browser support, peer-to-peer
Interactive Applications	Ultra-low latency response

Where WebRTC Fails Miserably

Recording: WebRTC streams can't be easily recorded server-side
CDN Distribution: Peer-to-peer doesn't scale to thousands of viewers
Firewall Traversal: STUN/TURN servers required, complex NAT handling
Mobile Battery: Significantly higher power consumption than HLS
Reliability: Connection drops require complete re-negotiation

The Hybrid Approach: Traffic Management Center

A DOT implemented both protocols strategically:

LL-HLS: Wall displays, public website, mobile apps (hundreds of viewers)
WebRTC: Operator PTZ control stations only (5-10 concurrent users)

Result: Sub-second PTZ control with scalable public distribution

7. Browser Compatibility Reality Check

What Actually Works in 2025

Protocol	Chrome	Safari	Firefox	Edge	Mobile
HLS	✅ Native	✅ Native	✅ Native	✅ Native	✅ Universal
LL-HLS	✅ Native	✅ Native	⚠️ Partial	✅ Native	✅ iOS/Android
WebRTC	✅ Native	✅ Native	✅ Native	✅ Native	✅ Universal
MPEG-DASH	✅ Native	❌ JS Only	✅ Native	✅ Native	⚠️ Android Only
RTMP	❌ Flash Dead	❌ No Support	❌ No Support	❌ No Support	❌ No Support

The Compatibility Winner: HLS is the only protocol that works natively on every modern device without polyfills, plugins, or workarounds.

The iOS Factor

Safari on iOS remains the compatibility kingmaker:

HLS: Perfect, hardware-accelerated playback
WebRTC: Excellent for bidirectional use cases
MPEG-DASH: Requires JavaScript, uses more battery, less reliable
RTMP: Completely impossible (Flash never existed on iOS)

8. The Protocol Decision Matrix 2025

The Simple Decision Tree

    NEED TO STREAM VIDEO IN 2025?
    │
    ├─ Camera to Server?
    │  └─ Use RTSP (or RTMP from legacy systems)
    │
    ├─ Server to Browsers/Mobile?
    │  ├─ Latency > 5 seconds acceptable?
    │  │  └─ Use Standard HLS
    │  └─ Need 2-5 second latency?
    │     └─ Use LL-HLS
    │
    ├─ Need bidirectional communication?
    │  └─ Use WebRTC
    │
    └─ Everything else?
       └─ You probably don't need it

Security Camera Specific Recommendations

Use Case	Recommended Protocol	Why
Public traffic cameras (511 systems)	Standard HLS	Scales to millions, works everywhere
Emergency operations center	LL-HLS	Low latency without WebRTC complexity
PTZ control interfaces	WebRTC	Instant feedback required
Mobile security apps	LL-HLS	Better battery life than WebRTC
Video walls	LL-HLS	Reliable, scales to many displays
Recording/forensics	RTSP to server, HLS for playback	Direct recording, universal playback

9. Implementation Guide for Security Systems

The Three-Protocol Architecture

Modern security camera systems need exactly three protocols working together:

Complete Implementation Stack

    [IP Cameras] 
         │ RTSP
         ↓
    [Video Server/Transcoder]
         │
         ├─ HLS → [CDN] → [Public Access, Mobile Apps]
         ├─ LL-HLS → [Operations Center, Emergency Response]  
         └─ WebRTC → [PTZ Control Stations]

Technical Implementation Details

HLS Configuration

    Segment Length: 4-6 seconds (standard)
    Playlist Depth: 3-5 segments  
    Bitrate Ladder: 400Kbps, 800Kbps, 1.5Mbps, 3Mbps
    Codec: H.264 Main Profile
    Audio: AAC-LC (if needed)

LL-HLS Configuration

    Segment Length: 1-2 seconds
    Partial Segment Length: 200-500ms
    Playlist Depth: 6-8 segments
    Prefetch: 2 segments ahead
    Delta Updates: Enabled

WebRTC Configuration

    Video Codec: H.264 (hardware acceleration)
    Audio Codec: Opus
    STUN Servers: Required for NAT traversal
    ICE Gathering: Aggressive mode
    Connection Timeout: 5 seconds max

CDN Considerations

For public camera access, CDN configuration is critical:

Cache Headers: Segments should cache for their duration
Origin Shield: Protect video servers from direct hits
Geographic Distribution: Edge locations near viewers
Bandwidth Limits: Prevent individual users from monopolizing bandwidth

10. Conclusion: Why This Matters for Your Cameras

The New Reality: The streaming protocol wars are over. Trying to support every protocol is expensive and unnecessary. Focus on HLS for distribution, LL-HLS for operations, and WebRTC for control—everything else is legacy.

What This Means for Your Projects

If you're implementing security camera systems in 2025:

Stop building MPEG-DASH support—it's dead weight
Migrate away from RTMP—it's a security risk and compatibility nightmare
Embrace LL-HLS—it's the future of real-time streaming
Use WebRTC strategically—perfect for control, terrible for distribution
Design for HLS-first—universal compatibility trumps theoretical performance

The Economic Reality

Protocol proliferation costs money:

Development Time: Supporting multiple protocols means multiple codebases
Testing Complexity: Every protocol needs testing on every device
Support Burden: More protocols = more failure modes
Infrastructure Costs: Transcoding to multiple formats uses server resources

Real Cost Analysis: City Camera System

A major city compared two approaches:

Approach	Protocols Supported	Development Cost	Support Tickets/Month
"Support Everything"	HLS, DASH, RTMP, WebRTC	$800K	150+
"HLS + WebRTC"	HLS, LL-HLS, WebRTC	$300K	20-30

Savings: $500K development + $180K/year reduced support costs

Future-Proofing Your Investment

The protocol landscape is finally stabilizing:

HLS will remain the universal distribution standard
LL-HLS will become the default for real-time applications
WebRTC will dominate bidirectional use cases
Everything else will fade into legacy support

Build your systems around these three protocols, and you'll have a future-proof architecture that works everywhere, scales efficiently, and minimizes support headaches.

Final Warning: Don't let perfect be the enemy of good. HLS isn't the theoretically best protocol—it's the practically best protocol. And in 2025, that's what matters.

About WINK Streaming

WINK Streaming provides video distribution infrastructure for security and surveillance systems. Our platform automatically handles protocol translation, delivering every stream in HLS, LL-HLS, and WebRTC as needed.

Protocol Support:

Input: RTSP, RTMP, SRT, H.264/H.265
Output: HLS, LL-HLS, WebRTC, RTSP
Automatic transcoding to optimal formats
Built-in CDN for public distribution
Universal compatibility across all devices

Stop fighting protocol compatibility—let us handle it for you. Learn more at wink.co

The Streaming Protocol Wars:Why HLS Won

Table of Contents