AVIWest DMNG Pro180 and Studio: Hands On Review
There are also two areas where handovers between masts occur, both as we approach and then as we crest the highest point on the route. These mast-to-mast handovers sometimes fail—mobile phone calls get dropped and more often than not the data sessions over the cellmux links drop and have to reconnect—resulting in a brief loss of video.
The Results
Once we got back we retrieved the video file from the DMNG Studio server onto a USB stick.
This marked a departure from the workflow we used with the Mobile Viewpoint system. That system had an inbuilt RTSP server and so I was able to stream the recording through this server and to my client laptop, while at the same time recording the quality of the bitstream using Wireshark, producing a clear indication of when the quality dropped from the target.
In this test of the DMNG—which doesn’t include an RTSP server on the Studio demuxer—the easiest way to take the recorded stream from the DMNG Studio was via USB memory stick.
After transferring the archive to my laptop I then set about using a simple tool called Bitrate Viewer (http://www.winhoros.de/docs/bitrate-viewer/) which produced some graphics with the sort of data I was expecting.
The main graph output from Bitrate Viewer is reproduced in Figure 7 from a screen shot of the output once I loaded the DMNG Studio ‘s recording.
Figure 7. The main graph output from Bitrate Viewer, showing the quality of the stream from the DMNG Pro180
I also extracted this from the analysis of the Locally Stored 3.5Mbps archive that was recorded using the second encoding DSP in the device—unsurprisingly this was “perfect,” as you see in Figure 8.
Figure 8. An analysis of the locally stored 3.5Mbps archive
I like Bitrate Viewer; it made the analysis clearer and feels like it will more generically handle the output of these devices. I hasten to add there may be other tools which can analyze in different ways, and I would be interested to hear about free/low-cost technologies that may provide qualitative information over the duration of a recorded file. I will endeavor to run whatever tests are practical for the audience.
The methodology for the test at this point takes a very “glue and scissors” approach—essentially I copy and paste each of the graphs—all with the common timeline and try to horizontally align them by hand on the page. This exercise is in its own right relatively informative because you become aware of a wider number of influencing factors on each test than you can record.
Let me bring all the data together for the DMNG, in Figures 9 and 10.
Figure 9. The testing route with key points plotted on a map (top) and a topographical chart (bottom)
Figure 10. DMNG Pro180 bitrates compared to points on map
I have marked up the map (Figure 9) manually a little, putting a small red marker for each of the visible cell towers we know of.
The contour of the area is not clear from the map itself, but essentially there are some points around B on the map and point C where the signal from the radio masts is essentially propagating down a valley and the valley bends, resulting in a loss of signal and yet a few moments later as you move down the valley you turn a bend and there is a next mast to handover to. We note that my letter markup A, B, C is then reflected in the return journey by D, E, and F. This is clearer in the blue contour graph (bottom half of Figure 10)—which helps us mentally map the highest point on the ascent map and this highest point is around point ‘4’ on the blue route marker.
So lining up the bitrate graph (Figure 10) with the ascent contour and the route map we start to see where the signal drops are and how they more or less align with the points where the signal from the cellmux to the mast is going to be geographically compromised.
Looking at the performance of the cellmux then, what immediately jumps out is that the codec is ramping up the encoding rate gradually after any drop out, so if the signal drops completely the encoder winds down the logically available throughput bitrate target it is encoding for, and is ready and encoding at a lower bitrate as soon as the connectivity is restored, and this is why we see the video bitrate ‘”saw toothing” in Figure 10 as the network link is recovered and the average bitrate the encoder is putting out gradually ramps up as the link proves more stable. This is a great approach for network links such as cellular shared services, with some variability. While it may lead to more artifacts in the video, this type of encoding profile will provide continuity in tough conditions.
I expressly asked the team to setup the latency at around three seconds or less. This parameter would usually be determined by a cellmux’s operators use case and so it was something that I felt I should be deterministic about. I am aware that even the toughest connectivity conditions can be smoothed out with high-latency buffering. However I wanted there to be a clear impact of the mast-to-mast switching for me to log and interpret, and also while in many circumstances latency in a live context is immaterial, in an increasing number of applications low latency is an expectation.
I recall we had sub 1-second latency as we tested at setup. By my estimation the outages we had above are all about 30 seconds to 1 min—on the video the major break up at point C can be seen happening between 16:20 and about 16:55 seconds—at which point a pixelated video runs, increasing in quality until 21.27 which is the point where D breaks down again for a further 30 seconds or so. From there on the signal runs steadily and picks up bitrate/quality right up until we crest the highest point and hand over to a new cell mast, dropping into the narrow road gully/valley again for the stretch between E and F; in that time the capacity is limited and reflects the capacity at the outset in stage B, confirming (in my mind at least) that the test is giving good pictures of the overall system connection quality.
Despite all the analytics, the most important thing is that the video looks watchable. Do take time to have a look at the YouTube clip. While you do, try to work out where you are on the route (play with Google maps).
Afterward, playing with this correlated map and data graphs encouraged us all to guess what was causing the bitrate losses. Factors we explored included taking educated guesses about the capacity provisioned on the backhaul fibre(s) by each operator at each of the masts: I would guess that the likely typical backhaul an operator may have in an area with a population of say 15,000 is probably 1Mbps per mast per operator. So while we had 3 SIMs from H3G (“3”), two from Orange, and two from Vodafone, my hunch is that in an area like this if my cellmux can only “see” one mast I probably only have 3Mbps available (one for each operator) at that mast. So even if I have 7 SIM cards I wont significantly benefit over having just one card from each provider. In fact I would be better off in resilience terms if I have as many vendors as I do SIM slots, although obviously the law of averages probably means I will miss out as often as I gain from that strategy.
While on the subject of SIMs, here is the total data transferred during the test as sent to me by Paul the following day:
H3G 76.51 MB
H3G 65.59 MB
H3G 84.00 MB
Orange 77.56 MB
Orange 78.59 MB
Vodafone 9.29 MB
Vodafone 14.48 MB
This total above (approx. 403MB) is notably different to the 255MB that I have on my USB memory stick at the moment. I assume this is down to back talk from the Studio to the Pro 180 confirming packet delivery etc.
That is definitely a quantity of data that you want to ensure you are billing efficiently. It’s about half a GB. A wrongly billed roaming charge on a contract for this could run up a significant bill (or lead to a number of deactivated SIMs in the middle of a live event!)
Conclusions
The DMNG Pro180 was rugged, and felt well-designed and put together. The video encoding quality was DSP-based with their own profile optimisations, all of which you could customize as you needed. Once configured the solution was “red button,” leaving the operator to get on with production. The link was low latency, good quality at a low bitrate and recovered well from link loss.
I particularly liked the dual DSP encoding approach; this provided several benefits. I also found the UI was simple and intuitive.
The talkback feature for audio communication over the cellular links back to the Studio device will be a useful feature for news crews and those synchronizing live broadcasts with scheduled TV playout.
All in all this is clearly a capable toolkit (Figure 12). I could write considerably more about the versatility. The form factor is great, as is the UI and controls. The wide range of details that are well thought out make the product effuse confidence. It sits firmly among the sector's leaders.
Figure 12. The AVIWest DMNG Pro180 has a "ready to work hard" feel.
I strongly recommend testing one out for your application. Please let me know if you have other tests you think we should be including in these benchmarks.
Related Articles
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
News gatherers can record and stream simultaneously, or conduct interviews with low latency.
01 Apr 2013
What to look for in cellular multiplexing devices -- perhaps the fastest growing streaming technology.
23 Feb 2012