LiveU LU500 Road Test
In the hope that many of you have already read earlier installments in my cellmux road test series, I will avoid going too deep in reiterating the overall process. But some background and introduction is in order.
Cellmux (cellular multiplexer) systems combine video encoding and channel-bonded link aggregation, typically of multiple cellular data paths, to enable (potentially) high-quality live video to be broadcast from anywhere within the combined cellular networks’ footprints.
Cellmux are typically used for news gathering, but increasingly they are also being used for sport journalism and as an increasingly frequent alternative to traditional satellite outside broadcast.
There are about 8 to 10 vendors worldwide, and the underlying workflow is more or less common to all of them, yet each has nuances, including codec implementation, overall link capacity, antenna design, server-side features, and modularity (or conversely tight integration) of the core video encoding, channel-bonding and link-aggregation capabilities.
Since this niche is small, and vendors’ operational bases are globally distributed, it is not always that easy to compare the systems side-by-side: It is virtually impossible to get all the units into the same room at the same time, and even if we did, they would all contend for the available cellular data paths, so any attempt to do a "shoot out" among the vendors would actually be more of a "shoot at" the mobile service operators.
That is where the StreamingMedia road tests come in. Over the past three years we have been iteratively developing a test that focuses on the various devices ability to maintain a live video path from a moving vehicle (something that is uniquely possible with cellmux devices) back to a remote location—notionally your streaming media encoder origin or perhaps news-feed aggregation point.
We have evolved a route from my home office in Brighton, England through some suburban and rural areas to the neighboring of Lewes and back, passing through a known cellular dead spot of radio frequency propagation interference caused by the local geography. Critically we look for the way the devices handle the dead spot, whether they fail, and if they fail outright, how quickly they recover.
Note that these tests will refer to the video quality in broad terms (excellent/usable/degraded/unusable) but, because my own company develops encoding platforms, I try to avoid publishing critiques of other companies' encoding in these pages. Accordingly the road tests are focused on the unique selling point of cellmux systems: IP-based data transports suitable for ad-hoc/mobile backhaul/contribution of live video in production TV and streaming media workflows.
Anyone who has looked into cellmux technology will have come across LiveU. Indisputably the market leader in the sector, LiveU have since 2006 developed an established client base across 60 countries. Their technology has been used for many groundbreaking news and high-profile events, including the World Cup, the Olympics, political campaigns, disaster news coverage, and extreme sporting events.
The LU500 is the current flagship product. This is how the company describes it on its website:
Weighing around 1 kg (2.2 lbs) LiveU’s new LU500 offers the ultimate combination of high performance and portability. This small sized unit is powered by LiveU’s new multi-processor video encoding engine and fourth-generation patented bonding algorithms. With boot time under a minute, the LU500 is essential to journalists broadcasting rapidly changing events and fast action scenes.
The system on its own can support up to 8 internal 3G/4G LTE modems and additionally two LAN, and Wi-Fi connections. This means that the LU500 can be connected at the same time to local broadband, VSAT, Ethernet, and up to eight cellular network providers, giving the user scope to aggregate more than enough capacity to deliver even 1080p HD video.
In addition, where conditions are operationally challenging, it is possible to combine the LiveU Xtender (essentially an external antenna) with a further six USB modems to boost the signal diversity and availability even further.
The system contains an internal three-hour battery, hot swappable support for external industry standard batteries, and can obviously be powered by mains.
It is small enough to be belt worn (with a strong belt!), backpack worn (the traditional cellmux fashion, originally popularized by LiveU), or even camera mounted (if you have a big camera!).
While small and compact, the system is robustly built, and is undoubtedly field ready. It has been doubtlessly built with war correspondence, extreme-sports and even cameramen in mind!
Paul Shepherd of LiveU, and Matt Stringer of Garland Partners brought a system into my office for the road-test.
We ran four tests in total, however most of my analysis in this article is focused on the fourth (second LU500 road test), because we have the complete video for comparison. I will cover the failover elsewhere, and I will comment on the LiveU Xtender in the summary toward the end.
- An initial road-test of the LU500 unit
- Some failover testing between the VSAT Wi-Fi and cellular links (which will be covered in a separate article with a wider focus to include VSAT)
- A road test with LiveU Xtender
- The second road-test the LU500, because we simply failed to press record on the initial road test and needed the archive to correlate the data to the resulting video output.
The LU500 encoded (from an HDMI bullet camera source), multiplexed the encoded source , and contributed the signal to their remote server system, which for the first three tests was located in my office on my domestic broadband, and for the second road test was run using the server located at the Garland Partner offices.
As you will see further on, in order to try to create something of a level playing field for the different vendors, I like to try to take a network packet capture of the received stream using technology such as TCPDump and Wireshark. In my mind this process provides some degree of fixed external perspective as we look at each vendor's technology, rather than simply relying on data their own reporting systems provide.
Accordingly our road tests generate an awful lot of data. Reducing this into something meaningful and useful for our readers is quite involved. In many ways we only scratch the surface, too; so, for example, we could go way beyond the analysis below and produce detailed views of how each cellular provider was used, which mast was used at which time, where there may have been capacity but because the video was static there was little throughput, etc.
But the aim here is to try to help readers make a high level buying decision. If there are detailed KPIs that we do not cover then do, of course reach out and get in touch, or perhaps check in on www.cellmux.com where we try to aggregate all the data we can about these technologies..
Setting Up the LU500
LU500 setup was easy and pretty much instant—press the "on" button, wait a few moments, and you're ready to simply hit "go" to transmit live. This model is ideal for the journalist or video producer who just doesn’t want to think about the transmission and needs to get on with producing content.
By contrast, the server/demuxer proved complex to route, and I am no newcomer to installing stuff behind firewalls. I have configured LiveU demuxers before with little or no trouble, so this was a bit of a surprise to me. However, since these issues are specific to my (admittedly bizarre) office routing configuration and external to the test, I think it is important to simply note that you must allow time for debugging the studio end routing before your scheduled live time—or at least be able to do what I did, which was, after 45 minutes of messing about, to turn off my office firewall (my office machines are all separately firewalled) for the duration of the test.
Doing so instantly produced a live signal from the camera at the remote server’s SDI output. We had an SDI monitor that gave us confidence things were working, but it is useful to note that because the resolution, bitrate, and various other encoding parameters are constantly be adjusted by the cellmux process, the server doesn’t make available the demuxed IP encapsulated stream.
LiveU and Garland Partners had created me a temporary account on their LiveU Central system. Essentially this is a hosted platform that can be used as an orchestration and oversight platform enabling the studio/master control room team (etc) to "war game," remotely control, oversee, and monitor live feeds and manage the archives from all their deployed LiveU systems.
We opted to connect our test system to LiveU Central, and by connecting my laptop browser to the LiveU Central web-portal and logging in I could see the LU500 was connected and active. Further, by selecting it in the GUI, I could actually bring up a monitoring stream on my laptop.
LiveU Central produces some nice, real-time graphing that shows the throughput and bitrate of each cellular, Wi-Fi, or LAN (etc.) sub-stream, and also the aggregate of the bonded group. However this is really more for confidence monitoring than the deeper inspection that we wanted to carry out. Also, the data was only in view for about 10 minutes and was not archived anywhere, so while it proved useful to correlate and use as a balance and check for my own data visualization, the LiveU Central portal is not really set up or intended for serious debugging work of this type. However, as a broad management tool it is straightforward and, more interestingly, hints at the evolution of the LiveU Connect ecosystem, and perhaps LiveU's overall approach and strategy as a company.
To obtain my own data set, and after a little dialog with the LiveU 24/7 support team, I used tcpdump to capture the inbound data seen at the server. For geeks out there, this was the capture command:
tcpdump -n -i eth0 port 9000 -s0 -w /tmp/roadtest_cap.cap
We left this task running in the background on the demuxer server throughout the test, capturing all the packets to port 9000 to file, and yielding more than 5GB of data across the tests.