Mushroom Networks Streamer: One to Watch
Last week I caught up with Cahit Akin, co-founder and CEO of Mushroom Networks, to hear about Streamer—the newest product in their already established range of technologies that all share common capabilities focusing on link aggregation and bonding of multiple IP interfaces to present applications with a single high-capacity IP connection comprising multiple lower capacity links. As regular readers will know, I term those devices that integrate video (and/or audio) encoding, multiplexing, and link aggregation/channel bonding as Video Cellular Multiplexers, or "CellMux" for geek-chic brevity.
By my rough estimate, there are around 40 to 50 high-end CellMux products in the market today from about a dozen vendors, many of which you have already seen in these pages, and many of which are at various stages of review through my own benchmarking test process. They range from two-way, broadcast workflow-targeted systems designed to replace satellite news gathering trucks and production teams, to low-cost, webcast-focused systems designed to get a signal back in a cheap, compact, and purely functional way.
To really understand the Streamer product one has to go a little deeper than assume it is just another CellMux video workflow solution; strictly speaking the Streamer disrupts that clean line I have traditionally kept between what is a true CellMux, offering integrated video and audio streaming over multiple IP routes, and what is a link-aggregation device that simply offers multi-path channel bonding. (Fun isn’t it?)
So What's a CellMux, Anyway?
A true CellMux has a video compression capability: the input will typically be HDMI, SDI or Composite video. The device will compress the incoming raw video into (typically) H.264 video, using dedicated DSPs such as the DaVinci chips from Texas Instruments, or software-based compression on the controller computer’s CPU, and then multiplex that video via software into a transport stream such as MPEG-TS or sometimes RTSP or RTMP. Those streams are then usually segmented into chunks for adaptive bitrate transfer over the IP networks.
In CellMux, adaptive bitrate is pretty much a necessary feature since, unlike satellite or fiber based transmission, the network capacity is almost certainly expected to vary.
The IP layer is in turn presented to the application as a single resource, but underneath it a link-aggregation control protocol will algorithmically determine which link-layer path is "most available" for the next packet of video, and while it will simply report "packet sent, next packet please" back to the IP stack and the encoding application, in fact it will be working pretty hard to ensure that the optimal link-layer route is used on a packet-by-packet basis.
A CellMux setup will also consist of a remote "demuxer" device that receives each of the packets, and is typically located at the destination of the live video—or example in the TV studio, or on a high capacity link that will provide stable connectivity to the content delivery network (CDN). The demuxer receives the incoming video packets from what may look like multiple encoders on many different IP connections, but by combining each of the packets from the various paths (using a counterpart part of the link-aggregation protocol) a single video stream is "reconstituted" at this remote demuxer end and this can then in turn be forwarded to the target application which may render the video immediately onto a standard broadcast technology like an SDI cable, or alternatively forward it to a CDN or enterprise video server, or indeed the stream may be archived at the demuxer for later retrieval in a file-based workflow.
OK – perhaps that was a little heavy, but to understand at a technical level why the Mushroom Networks Streamer is an important and disruptive new entry in this niche we need to at least understand that broad picture!
Let us now compare this live video transmission using a generic CellMux described above and transfer of a recorded video file (or indeed any other file) over a "non-CellMux" link-aggregation system. In both types of systems, multiple IP connections—such as 3G/4G modems, Wi-Fi, and Ethernet—may be connected and bonded together by a link-aggregation process.
In the specific use case of live video and audio streaming, there is an inherent desire to ensure that packets are delivered in a "timely" manner to the remote end so that the packets can be reordered and delivered to the listener or viewer in a meaningful way – ie the stream must be watchable!
A CellMux has tight integration between the video encoding, the video multiplexing, the transport stream, IP, and the underlying layer 2 and layer 1 network systems—with oversight and control applications and communication protocols ensuring that there is feedback between these layers. This means that if the bandwidth drops on the IP layer, the muxer can switch to a different bitrate source, or if multiple network links fail altogether the frame rate of the DSP could be lowered while maintaining the compression so that the image quality is more suited to the remaining links (and so on and so forth).
This vertical integration from the capture of the raw video right through to the output of raw video at the remote demuxer end enables a wide range of optimization options and ensures that the video is delivered as well as it possibly can be.
Link Aggregators and Channel Bonding
Let us now take a look at non-CellMux devices.
The link-aggregation/channel bonding devices are less focused on video. Indeed they first evolved principally to bind multiple dial up and broadband links together to provide higher overall WAN connectivity to smaller offices that can afford cheaper ISDN and ADSL connections, but want to share the throughput levels that can only otherwise be obtained with expensive leased lines or similar "
"high end" connections. At the time they were first introduced the target applications were office workflow-targeted, such as email, web browsing, and file transfer, and while the overall throughput is indeed an aggregate, essentially they load balance requests over all the available links on a file by file or request by request basis. This means that while the overall throughput in and out of the office’s WAN connection is significantly larger than any one of the links could provide on its own, the "bitrate" of any individual file transfer’s throughput would not exceed the throughput available on the individual link through which it was being transferred.
Putting a few numbers (in a very simple model) an ISDN link-aggregator, with four 128Kbps ISDN links, may well be able to deliver around half a megabit per second of throughput for a hundred users all refreshing financial data into trading desk applications (hundreds of tiny byte-sized requests) but a video encoded at 256Kbps and streamed over this link will play back just as badly as if there was only one 128Kbps ISDN link and no other users. Or another way to look at it : It would have taken 2x real-time to transfer… a broken up jittery and un-watchable real-time experience.
Channel-bonding link-aggregators go beyond this and actually start to fragment the files into chunks and send the chunks of broken up file over the two (or more) links. Unlike simple link-aggregators that only require a single device at the office—and like a CellMux—these Channel Bonding technologies require a remote demuxer to which they are ‘virtually’ connected which then recombines the file and forwards it on to its destination – this demux device (or the application software such devices run) needs to be hosted somewhere in the Internet and itself needs a higher capacity upstream connection than both the aggregate of all the different inbound multiplexed routes combined, and the anticipated maximum outbound ‘single’ data throughput.
Each channel bonding device thus has a link-aggregation capability, and each CellMux in turn is built on a channel bonding device
However, unlike CellMux, the channel-bonding link-aggregators do not have any awareness of the application that they are being used for—they are "dumb pipe" routing systems not unlike VPN tunnels inasmuch as they simply move data from one end of the link to the other. Critically if a packet of data is transferred over a channel-bonded link and an error was detected, or if that packet simply never makes it to the other end, the receiving end point’s transmission control protocol (TCP) (or sometimes a proprietary UDP-based transmission control protocol within the channel bonding muxer/demuxer setup) will request that packet, and transmission will stop, later packets will be dumped and the transmission will "step back" to where the lost packet was in the sequence and restart. While this may be virtually unnoticeable in a file transfer where (for example) a 5% error rate over the link means that a file that could ideally have taken 20 seconds to transfer instead took 21 seconds to complete, if you are trying to stream a key sporting event, a 1-second pause in the live transmission every 20 seconds would become rapidly unwatchable for the end user.
How is Mushroom Networks' Streamer Different?
But now, assuming at least a significant part of the above makes sense, it becomes very straightforward to explain concisely where the Mushroom Networks Streamer fits into this eco-system!
The Streamer is a channel-bonding link aggregator with added "Video-Armor" control protocols that are able to optimize for RTMP or MPEG-TS transported video and audio.
Unlike "reliable TCP" of a channel-bonding device, where a dropped packet will automatically cause a the transmission to stop and jump back to the point where the packet was dropped, Video-Armor is "video aware" so can determine if a retry is required, or instead it may discard the packet altogether and notify the target application, while notifying the remote end. A small loss of a packet or two every now and then in a live stream is inconsequential so long as the action continues smoothly—the brain is fantastic at filling in the gaps providing the "flow" of the video or audio is continuous. All perceptual compression technologies such as the family of MPEG H.264 etc work this way anyway.
So let’s cut a long story short: What does this mean for a camera operator wanting to get the video signal back to the studio from the field?
Ultimately the key here is that the Streamer simply replaces your Internet Connection—and, unlike the other devices on the market—it leaves your workflow intact as far as the video encoding stage is concerned. Until Streamer arrived on the market the only way to get the benefit of Channel Bonding with live video was in a CellMux device.
Technically this means that while you are perhaps still reliant on MPEG-TS or RTMP as outputs from your encoder, you are not limited to the codec—and as the world migrates toward H.265/HEVC this may in-fact enable the first HEVC live encoding using cellular channel-bonded systems to be delivered some time ahead of when a fully integrated CellMux can do it.
This ability to separate out the codec may also have other advantages: MPEG-TS itself is a widely used, robust, and "fit for purpose" technology, with a number of capabilities that are not yet implemented in any CellMux: For example, many webcasters need to send multiple language streams with their video picture, and such a custom implementation would be simple with a Mushroom Networks Streamer.
Naturally this would mean that you would have a separate encoder and channel-bonding device, and to some extent the "all-in-one" portability of the typical CellMux is very much a key selling point which the Streamer would buck against.
If you already have your encoder workflow in place, the Streamer stands alone in the market as providing channel-bonding/cellular bonded capability.
As a final comment, at its extremely attractive price point ($5000 or thereabouts) the Streamer really only has one product to complete against: the Teradek Cube+Bond or the integrated Bond II.
As I write this I am just completing the benchmark for the Bond II, and Mushroom has promised me a Streamer (and some of their other products) to put through the benchmark in due course.
It will be interesting to see if there are any significant differentials in practical testing.
My conclusion: A great, disruptive new addition to the sector. Mushroom is one to watch.
Related Articles
TriCaster operators will be able to access Mushroom Networks Streamer control and feeback via the TriCaster user interface
07 Apr 2014
The name's Bond. Bond II. And it's a cellular bonding device and encoder that delivers terrific performance at a price point that's almost unbelievable.
07 Nov 2013