H5Live is based on three primary modules: a
live stream reader, a live stream segmenter and
multiplexer, and a live stream delivery module.
“The live stream reader connects to existing
live streams, with H.264 Video and AAC Audio
supported based on RTMP,” says Lietz, adding
that H5Live can also connect to WebRTC sour-
ces based on UDP.
The modular segmenter/multiplexer differs
from existing HLS or DASH segmenters, since
it focuses on frame-based delivery independent from H.264 group of picture (GOP) length
or file chunks. According to Lietz, the benefit
is that live streams based on fragmented MP4
(fMP4) can be assembled to be fully compatible
to standard HLS.
In addition, the segments can be repurposed to use media source extensions and
WebSockets working on newer versions of the
Chrome and Firefox, or even sent as MP4-like
streams to “dumb” devices like set-top boxes that don’t inherently allow HLS or HTML5
A final approach, taken by id3as, is to use
multiple TCP sessions.
“Where others are looking to make UDP
more like TCP,” says Dom Robinson, co-
founder of id3as (and contributing editor to
Streaming Media), “we’ve taken the opposite
approach. TCP is one of the best protocols
out there, but it lacks some of the benefits of
UDP, so we’ve brought those bits over to a TCP
Robinson and partner Adrian Roe have de-
vised a scheme that uses multiple TCP ses-
sions that are bonded together, rather than
the traditional way that Unix and other inter-
net-centric approaches use link aggregation.
In some ways, this bonding approach is reminiscent of the way that telecom bonding works.
If you remember old-school 64Kbps ISDN lines
(also known as BRI lines), each of these B channels had its own 8 to 10Kpbs channeling and
handshake bits. But when bonded together to
create 384Kbps or even a multi-megabit connection as a primary line (PRI) there was no
need for each B channel to negotiate its own
handshake. So the PRI handled connectivity,
freeing up those extra 8–10Kbps on each of a
dozen or more lines.
The id3as team calls their approach GRIT,
and they offer a more flexible bonding solu-
tion. Any of the TCP sessions or “channels”
While the id3as concept isn’t new, having
been tried in the field for the last 3 years, it
has seen considerable interest of late from
those that don’t want to move away from TCP
While this article deals primarily with transmission and the world of transport protocols,
that’s only the middle of the story, which begins with coding, packaging, and multiplexing.
In order to create a stable and scalable communication system, both encoder and player
need to be aware of potential latency pitfalls
as well as points at which to avoid these pitfalls
via the use of buffering.
We tend to think of buffering as a bad thing,
but with live streaming often used in unstable
environments like mobile networks, there’s a
need for “relief valves” at various points in the
process. This need lends itself to buffer control
to avoid frame dropping. Buffer control also
has the added benefit of keeping latency down
in all network situations, even those pesky unstable mobile networks.
In addition, there may be a need for short-term adaptive bandwidth control to “smooth
out” wide variations in bandwidth at any given
point in the delivery process.
The downside is that these technologies
may ultimately have a greater impact on the
user experience than just the underlying transport protocol.
As such, it is key that the industry solve a
holistic transmission problem, with interop-erability in mind, rather than just solving for
one middling-sized part of the equation.
Tim Siglin is a streaming industry veteran and longtime
contributing editor to Streaming Media magazine.
Comments? Email us at email@example.com, or check
the masthead for other ways to contact us.