LiveU LU500 Road Test
In some of the previous road tests with other vendors, I have managed to use this packet collection method after (logically) the stream has been demuxed (i.e., on the single "re-constituted" stream output to my laptop, typically as an RTSP or MPEG-TS, from the respective vendor's demuxer). This setup with the LU500 was slightly different in that we were actually capturing the stream inbound before the demuxer, giving a very detailed insight into what was going on with the critical muxed signal path.
However, since this is meant to be an article and not a book (!), I will stick to the aggregate I/O graphs rather than start analyzing the separate cellular paths.
These graphs were produced by importing the data captured by the tcpdump into Wireshark, and then using the Statistics > I/O Graph option to generate the graph output eventually as .png. Due to width issues I then composited two or three sections along the time-line into the single graphs sampled in the document.
I also ran a "jogging logger" on my iPhone as we did the drive to produce a map and other details such as elevation and speed, which I am not showing here.
Matt from Garland Partners added a UTC timestamp to the archive of the video recorded at the server. The uploaded archive can be seen here. and it may be interesting to have this open as you read the analysis.
Combining all these data points and referencing the UTC timestamp in the video itself we can pretty accurately see the bits per second that were captured at the server.
Let’s look at the results.
LU500 Test Results
Here is the road-test route as plotted by the jogging logger on my iPhone:
This will be familiar to many of you who have followed these tests before. The numbered points are generated by the app to reference pace changes and the like, but I use the numbering consistently to reference stages of the journey when marking up other data and numbering images.
The key points are shown by the app as 8 and 14 that fall where the dead spot is. We expect to see breakup and signal loss, followed by recovery.
So now let's look at the overall bitrate I/O graph. This is the output from the second road-test:
I have marked up most of the points on the route map on the graph in red (and added a note where we pass the ‘hill-top’ on the outbound journey).
First lets look at hilltop where the cellmux has at least 3 cell towers in direct line of sight, and all the I/O graphs show we were performing at peak levels.
Recalling this is a screen-shot from VLC, and so the rendering of the car to the right and the screen reflection are ultimately production issues, you can see that as far as a viewer is concerned the perceptual coding is doing a good job, and the shot is extremely viewable, with a real sense of detail.
However when we get down to the dead spot, the LU500 gave us, for the second time during our tests, a rather nice surprise, and we achieved continuous signal right through the dead spot—despite a clear drop in available bandwidth, which resulting in lower encoding quality:
This only lasts a few seconds and then clears up very quickly (as the traffic graphs confers).
So, with the exception of the Mobile Viewpoint system, which has an option to extend the latency to an extreme level (potentialy minutes) to deal with tunnels etc., the LU500 is the first "low latency" (2- 5 second) cellmux to make it through our road test dead spot without a loss of signal.
However, while we were just beginning to wonder if our road-test was broken (had those dammed mobile operators added a mast and filled in the dead spot?) we had, for the first time in our road-tests, an 10 second outage on the slightly higher return route:
It is worth noting that traffic conditions meant that on the way out we were at a crawl (15km/h or thereabouts) and yet the return route was free flowing and so we were probably at 70 to 90 km/h. Assuming that forward error correction and so on can reassemble the bit stream, even in very weak signal areas, and assuming that correction itself is better able to keep up with the rate of change of the conditions by virtue of passing through the dead spot slowly, then it may be that the velocity at which we were moving could have had a bearing on these unusual outcomes.
The other thing that really struck us is that where we have typically had "gullwing"-shaped graphs, reflecting the peak signal outbound and returning over the hill top at the peak of each wing, and the dead spot appearing as the "shoulder," with the LU500 the traffic graph was only maxed out (at around the set 5Mbps) occasionally—the variable bitrate encoding could be seen clearly. If you track the graph while watching the video you can see the effect of the bitrate dropping when the car is stationary, and small spikes as traffic moves through the image causing the H.264 codec to send more data while there is more motion.
Each road test reveals more than the last, and we understand how to get more data. In this test, we have a very interesting tracking of how incredibly responsive the LU500 encoder is to changing conditions and how both the multiplexing and the video encoding are incredibly "in-tune"—and that integration is the critical enabler that makes a channel-bonding router into a cellular video multiplexer.
It is impossible to know which of the many details and moving environmental parts our audiences will most be interested in. A good cellmux should be a simple-to-use tool which has as much intelligence as possible to deal with as many complex situations as possible and to manage the acquisition, compression, and packetisation of the video as well as possible.
The road-tests are not meant to be particularly comparative: We aim to focus on the applicability of the systems to function as they are sold. The LU500, the flagship of the leading player in the space, is absolutely robust, extensible, and simple to use, while being packed with features and capabilities.
As with all cellmux units, scenarios can be engineered where the link can be made to fail. To its huge credit the LU500 managed to make it through an area that has on all previous road tests been a challenge, albeit with some of the many environmental factors at variance as they always will be.
LiveU has a model where they provide the technology platform much like a managed service. Typically, the link and data is managed and re-sold by them. If you are on the case with Sensorly or other coverage mapping you can almost certainly ensure that LiveU will provide you with suitable cellular services for a particular area.
This model makes it hard to comment on the perceived "premium brand" that LiveU can come across as, and whether that premium is significantly better than some of the lower priced but "service not included" systems out in the market: it will definitely depend on where your price vs management cost balance is. That will probably be driven by how much use the device will get, but whichever way you cut the cake, the overall costs of running any cellmux is nominal compared to the cost and inflexibility of most other satellite and fibre-based backhaul options.
The LU500 is LiveU’s flagship at the moment. There are other systems which excel in technical specifics for some features, and other providers who excel in specific services to the clients and users, but LiveU has a strong market positioning, and in many ways this makes the LU500 the industry’s current reference platform.
A Footnote on the LiveU Xtender
I wanted to just add a footnote about the LiveU Xtender. It is an extra antenna that can support 6 more data SIMs and can be connected by a long cable to the LU500. This means that you can run the antenna upstairs from a basement or out above the heads of a crowd while keeping the LU500 with you as the camera operator.
During one of our tests we extracted a small data set where we added the LiveU Xtender to a live video link:
As you can clearly see the extender provided that extra capacity for the encoder to really comfortably sit at the target 10Mbps, where before the encoding rate was peaking out at perhaps 9Mbps.
While this particular dataset proves the technical gain on the throughput that the LiveU Xtender brings, the value of its use will generally be in either marginal signal areas, or in areas where the production rig and a good signal are a little way apart.