Wowza Streaming Engine transcoding guide targets high-concurrency CPU-only deployments
Wowza has published technical guidance for optimizing Wowza Streaming Engine on CPU-only infrastructure to handle high-concurrency WebRTC transcoding. The recommendations focus on decoder implementation, audio codec pairing, memory allocator tuning, and horizontal scaling strategies for camera fleet deployments.
Key Takeaways
- High-load production tiers require at least 6 CPU cores and 16-32 GB of RAM for concurrent WebRTC sessions.
- Setting MALLOC_ARENA_MAX to four times the core count on Linux prevents memory crashes during frequent stream churn.
- WebRTC delivery requires Opus or PCM audio, necessitating separate renditions for HLS paths which use AAC.
- Explicitly setting the decoding implementation to 'default' avoids invisible overhead from failed hardware acceleration attempts.
Why It Matters
Optimizing Wowza Streaming Engine transcoding for CPU-only environments allows operators to scale horizontally using standard cloud instances rather than expensive GPU-equipped hardware. By enforcing 720p resolution and removing B-frames at the source, engineers can significantly reduce the per-session compute tax that often leads to cascading failures in high-concurrency camera fleets. This shift toward WHIP and WHEP signaling further enables the use of standard load balancers, moving the industry away from complex sticky-session routing. Watch for whether these software-based optimizations can maintain sub-second latency as source resolutions move toward 4K in industrial monitoring use cases.
Additional Context
The economic case for CPU-based transcoding has come under increasing scrutiny as operators scale concurrent stream counts. Mayflower, a streaming infrastructure provider handling over 10,000 incoming streams and more than one million outgoing streams, documented its migration from CPU-only transcoding to ASIC-based hardware in a detailed technical analysis. The company found that CPU-only transcoding on Dell R940 servers produced only 20 simultaneous streams per server at a per-stream cost of $1,000, meaning that scaling to 10,000 incoming streams would have required 500 servers at a total capital expenditure of $10 million. After transitioning through NVIDIA T4 GPUs and ultimately to ASIC-based VPUs, Mayflower reduced its server count to 38 and cut total transcoding costs to under $1.5 million while dropping power consumption by over 90 percent. This trajectory illustrates the cost ceiling that Wowza's CPU optimization guidance aims to delay or avoid for operators who cannot yet justify dedicated transcoding hardware.
Wowza's positioning within the broader transcoding hardware landscape was further highlighted in Streaming Media magazine's buyers' guide to hardware transcoders, which benchmarked cloud-based transcoding options for a hypothetical 100-channel FAST service. The guide referenced Wowza's own performance data for NVIDIA T4-powered g4dn instances and AMD Alveo U30-equipped VT1 instances, measuring simultaneous 1080p30 stream capacity across different cloud configurations. The analysis computed encoding ladder workloads at 1.87 times the base 1080p stream count, providing a framework for comparing CPU-only software transcoding against hardware-accelerated alternatives. Wowza's new guidance on limiting source resolution to 720p and removing B-frames directly addresses the workload multiplier problem identified in that comparison.
The WHIP and WHEP signaling protocols that Wowza recommends for its high-concurrency deployments have gained traction across the real-time streaming ecosystem. Dolby's OptiView platform, which evolved from the Millicast acquisition, supports WHIP-based WebRTC ingestion with H.264, H.265, VP8, VP9, and AV1 video codecs alongside Opus audio at bitrates from 6 kb/s to 510 kb/s. The platform also supports SRT and RTMP ingest for tools that have not yet adopted WHIP, reflecting the same protocol transition challenge that Wowza's guidance addresses. Dolby added WHEP support for standardized WebRTC playback in early 2024, enabling multi-vendor interoperability for WebRTC-based services, which aligns with Wowza's recommendation to use standard load balancers instead of sticky-session routing for WHIP and WHEP signaling.
Read full article at wowza.com
Enjoy our coverage?
Add StreamingMeme as a preferred source on Google to see more of our streaming news at the top of your Search results.
Add as preferred source