VP, engineering, Ceeblue
With full realization of the Media over QUIC (MoQ) streaming potential several years off, providers of WebRTC platforms are positioned to seize the opportunities created by rising demand for real-time streaming solutions today. But the assertion that WebRTC platforms offer the only immediate route to real-time multidirectional streaming at mass scales is now challenged by Ceeblue .
Ceeblue, a Dutch company founded in 2017 that came to the September IBC show in Amsterdam touting its WebRTC platform and expertise in encoding, made the surprise announcement midway through the show that it was introducing a ready-to-deploy real-time interactive streaming option utilizing Hypertext Transport Protocol (HTTP) technology. The company said its Web Real-Time Streaming (WebRTS) platform is a software framework that operates on par with WebRTC performance using the Transmission Control Protocol (TCP) commonly employed with HTTP delivery, which is widely viewed as inimical to real-time streaming.
The development went largely unnoticed with no press reports and certainly no chance for expert review of the claims. But a live demo and detailed technical explanations offered by company officials made clear this is not something that should be dismissed out of hand.
The demo offered a metered accounting of end-to-end latencies registered by live side-by-side 1080p HD feeds of the animated short film Big Buck Bunny – one generated by the Ceeblue WebRTS streaming platform and the other by Ceeblue’s WebRTC platform. The two streams were uploaded from the show floor to the cloud with high-speed H.264-encoding supported by Ceeblue’s encoder and downloaded to side-by-side PC displays through the notoriously poor-performing IBC Wi-Fi network. The meter consistently registered 300ms end-to-end latencies on both feeds.
Ceeblue vice president of engineering Jonas Blotz described the WebRTS framework as a solution that the company claims to be the first framework designed from the ground up exclusively for live transport. While currently it only works with streams encoded for TCP delivery, Blotz said UDP in conjunction with support for QUIC, HTTP/3 and MoQ options is on the company’s roadmap.
WebRTS applies many latency-reducing mechanisms with what Ceeblue calls “partially reliable” streaming, which appears to mean the framework supports the same level of quality in terms of continuity in the face of packet losses and other disruptions that’s common to WebRTC and MoQ. While the framework operates on streams formatted for TCP delivery, it can be configured, depending on the user’s preferences, either to prioritize continuity using the retransmission with buffering support that TCP employs to maintain stream continuity or to make the stream partially reliable, selectively skipping frames, in order to prioritize real-time delivery.
Notably, with the choice to prioritize real-time delivery the approach taken by WebRTS doesn’t have the quality-diminishing impact one might expect owing to other mechanisms in play, Blotz said. These start with the framework’s support for the multiple bitrate/resolution profiles used with adaptive bitrate (ABR) streaming.
This ensures streams are reduced to lower bandwidth-consuming profiles in the presence of network congestion. It’s only when the lowest profile still doesn’t allow the flow to get through that the framework, rather than implementing TCP buffering, can be made partially reliable, causing the next available frames to be skipped imperceptibly in order to prevent delays.
Moreover, in the presence of such congestion as detected by device client software, the framework dumps lower-priority packets to ensure that nothing critical to a good user experience is missed in any skips over blocked packets. Ceeblue has implemented two versions of the framework to meet these requirements.
One supports what it calls Adaptive Push, which employs WebSocket technology to enable server-side detection of network congestion in interactions with the client player. The other approach, known as Adaptive HTTP, maintains a minimal degree of player-server interactions in conjunction with use of reduced durations of the “chunks” or elements of multi-frame fragments used in conventional HTTP streaming.
This allows Adaptive HTTP to use shorter intervals in the skipping process to the next unblocked content segment than the chunks created in the latency-lowering Chunked Transfer Encoding (CTE) process. CTE is an option requiring CDN support that’s available for use with the widely used approach to HLS and DASH streaming consolidation known as Common Media Application Format (CMAF).
Without spelling out what if any differences there might be in terms of latency or quality performance between Adaptive Push and Adaptive HTTP, Blotz said the company was offering the Adaptive HTTP option because it is compatible with CDNs. “One important thing was to really have broad CDN support,” he said.
Another factor contributing to the framework’s avoidance of delays caused by congestion involves stripping packet headers of all bits used to direct handling of file-based VOD content. As a live-only framework, WebRTS eliminates about 5% of the streamed payload both through the reduction in the volume of data in player/server communications related to changes in manifest files and through the containerless RTS format developed by Ceeblue, Blotz said.
Adding to the efficiencies, the framework can be implemented in browsers on the receive end, eliminating the need for plug-ins, noted Josh Bergen, business operations coordinator for Ceeblue. “We use browsers for client support through APIs that are part of the browser architecture,” he said, noting that Apple’s recent introduction of the Managed Media Source, an open interface for Safari, completed the list of possibilities across all the major browsers.
WebRTS is ready to deploy, Bergen said. “We have a customer providing a sports streaming service who’s adding support for interactive gaming using WebRTS,” he noted. “With 8,000 users on the service, anyone can play with WebRTS delivering content in real time and working over their output as well.”
Ceeblue, a Dutch company founded in 2017 that came to the September IBC show in Amsterdam touting its WebRTC platform and expertise in encoding, made the surprise announcement midway through the show that it was introducing a ready-to-deploy real-time interactive streaming option utilizing Hypertext Transport Protocol (HTTP) technology. The company said its Web Real-Time Streaming (WebRTS) platform is a software framework that operates on par with WebRTC performance using the Transmission Control Protocol (TCP) commonly employed with HTTP delivery, which is widely viewed as inimical to real-time streaming.
The development went largely unnoticed with no press reports and certainly no chance for expert review of the claims. But a live demo and detailed technical explanations offered by company officials made clear this is not something that should be dismissed out of hand.
The demo offered a metered accounting of end-to-end latencies registered by live side-by-side 1080p HD feeds of the animated short film Big Buck Bunny – one generated by the Ceeblue WebRTS streaming platform and the other by Ceeblue’s WebRTC platform. The two streams were uploaded from the show floor to the cloud with high-speed H.264-encoding supported by Ceeblue’s encoder and downloaded to side-by-side PC displays through the notoriously poor-performing IBC Wi-Fi network. The meter consistently registered 300ms end-to-end latencies on both feeds.
Ceeblue vice president of engineering Jonas Blotz described the WebRTS framework as a solution that the company claims to be the first framework designed from the ground up exclusively for live transport. While currently it only works with streams encoded for TCP delivery, Blotz said UDP in conjunction with support for QUIC, HTTP/3 and MoQ options is on the company’s roadmap.
WebRTS applies many latency-reducing mechanisms with what Ceeblue calls “partially reliable” streaming, which appears to mean the framework supports the same level of quality in terms of continuity in the face of packet losses and other disruptions that’s common to WebRTC and MoQ. While the framework operates on streams formatted for TCP delivery, it can be configured, depending on the user’s preferences, either to prioritize continuity using the retransmission with buffering support that TCP employs to maintain stream continuity or to make the stream partially reliable, selectively skipping frames, in order to prioritize real-time delivery.
Notably, with the choice to prioritize real-time delivery the approach taken by WebRTS doesn’t have the quality-diminishing impact one might expect owing to other mechanisms in play, Blotz said. These start with the framework’s support for the multiple bitrate/resolution profiles used with adaptive bitrate (ABR) streaming.
This ensures streams are reduced to lower bandwidth-consuming profiles in the presence of network congestion. It’s only when the lowest profile still doesn’t allow the flow to get through that the framework, rather than implementing TCP buffering, can be made partially reliable, causing the next available frames to be skipped imperceptibly in order to prevent delays.
Moreover, in the presence of such congestion as detected by device client software, the framework dumps lower-priority packets to ensure that nothing critical to a good user experience is missed in any skips over blocked packets. Ceeblue has implemented two versions of the framework to meet these requirements.
One supports what it calls Adaptive Push, which employs WebSocket technology to enable server-side detection of network congestion in interactions with the client player. The other approach, known as Adaptive HTTP, maintains a minimal degree of player-server interactions in conjunction with use of reduced durations of the “chunks” or elements of multi-frame fragments used in conventional HTTP streaming.
This allows Adaptive HTTP to use shorter intervals in the skipping process to the next unblocked content segment than the chunks created in the latency-lowering Chunked Transfer Encoding (CTE) process. CTE is an option requiring CDN support that’s available for use with the widely used approach to HLS and DASH streaming consolidation known as Common Media Application Format (CMAF).
Without spelling out what if any differences there might be in terms of latency or quality performance between Adaptive Push and Adaptive HTTP, Blotz said the company was offering the Adaptive HTTP option because it is compatible with CDNs. “One important thing was to really have broad CDN support,” he said.
Another factor contributing to the framework’s avoidance of delays caused by congestion involves stripping packet headers of all bits used to direct handling of file-based VOD content. As a live-only framework, WebRTS eliminates about 5% of the streamed payload both through the reduction in the volume of data in player/server communications related to changes in manifest files and through the containerless RTS format developed by Ceeblue, Blotz said.
Adding to the efficiencies, the framework can be implemented in browsers on the receive end, eliminating the need for plug-ins, noted Josh Bergen, business operations coordinator for Ceeblue. “We use browsers for client support through APIs that are part of the browser architecture,” he said, noting that Apple’s recent introduction of the Managed Media Source, an open interface for Safari, completed the list of possibilities across all the major browsers.
WebRTS is ready to deploy, Bergen said. “We have a customer providing a sports streaming service who’s adding support for interactive gaming using WebRTS,” he noted. “With 8,000 users on the service, anyone can play with WebRTS delivering content in real time and working over their output as well.”