These findings made the whole trip worth while. We now know that we can connect across the world and transfer live photo, video and VoIP data to give anyone on the Internet remote access to field locations.
The Twinkle VoIP client connecting a SIP call from the OU to Paul in Nicaragua (7.5MB Video - click to view). (video capture from screen)
The attached video shows the point at which we got our first audio contact at the Volcano. At this point the video was running at a quarter PAL resoluction (160 x 120 pixels) at five frames per second and a contstant bit rate of 200 Kbps.
Having done our usual set of ping and iperf tests on the BGAN connection at the Volcano, we tried accessing the webserver and downloading a photo (see post on ‘Photo downloads with and without audio’). All was going well so next we looked at accessing the live video stream. We started with the lowest frame size and frame rate and explored a range of settings (see post on ‘Video resolution configurations’). Part way through these we started a VoIP call (which ran for the reminder of the tests – 27 minutes).
A video of Paul counting down from five to one on his fingers - the audio and video are quite well synchronised (1.5MB Video).(video capture from screen)
To test how the audio and video streams are performing we do a simple five-finger test. This involves counting down from five to one using your fingers. The idea behind it is simple – the audio and video streams are being run but different processes so they can lag or get out of sync – in fact we might expect this to happen as different encoding algorithms are being used to process the audio and video data. However, as you can see from the attached video they seem to be in sync, this makes conversation a lot easier. Paul’s video camera is running at half PAL (320 x 240 pixels) and 5 frames per second, with a constant bit rate of 200Kbps.
A clip showing the view point area at the top of the volcano beside a crater with venting gases (Video - 4.2MB).(video capture from screen)
Here’s a clip showing the video stream stretched to it’s limits when Paul goes walkabout with the camera. We’re using MPEG-4 video and in this clip the resolution of Paul#s camera was set to half PAL (320 x 240 pixels) with a frame rate of 5 frames per second and a constant bit rate of 200Kbps. Between key frames the MPEG-4 encoder sends the changes between consecutive frames. This means that when there is a lot of movement the image quality can drop as more information needs to be sent for each frame. In this clip we can see lots of examples where the quality drops while the camera is moving, but as Paul pauses on an object the quality of the image improves.
Live video streams at varying resolutions and frame rates. (video capture from screen)
We’ve used quite a few different video resolutions and a couple of frame rates. In all cases we’ve kept a constant bit rate of 200Kbps – Richard at callmonitor.com recommended this setting and it has served us well. Higher bit rates are probably possible, but we’re using a ‘Standard’ BGAN data link configuration (rather than one of the Streaming configurations) so we don’t really want to push our luck. The following two sets of clips show the performance we had for video at different camera settings. The first set show Paul in front of the camera with a flag, the second set show the points where we made the video link after changing the camera settings. In both cases the smoothness of the video relates to the camera’s frame rate and the clarify of the image relates to the camera’s resolution.