Paul live from the volcano on VoIP phone and streaming video (video capture from screen)
Yesterday we successfully connected to Paul at the volcano using the BGAN satellite link. The following set of (five) posts will try to cover the tests we carried out, these include:
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.
A clip showing of the effect of downloading a photo during an active VoIP call (Video - 15.8MB).(video capture from screen)
The final test we did with Paul at the volcano yesterday was to download a photo while talking on the VoIP phone at the same time. The router currently gives no priority (or Quality of Service preferences) to audio data – all data gets treated with equal priority. As a result while we’re filling the bandwidth with photo information the audio drops out. This could be solved by setting a Quality of Service preference for audio data. The image would then download slower, but the audio conversation would be maintained. Another option is to self regulate the conversation and keep quiet while waiting for downloads or other priority data.
Photo download video clip (5.4MB) - showing the time taken to download a new thumbnail page and a new photo.
On Saturday Paul went back up to Masaya volcano for a couple of hours in the morning. Again we used the BGAN terminal to connect to the Internet. As before, we used Skype text chat throughout as our back channel for communication. The Ricoh WiFi camera worked well for taking pictures and sending them over the local WiFi network to the Asus server, where I could then access them from the UK. This time I managed to get a video of the process to show the performance of the service (see clip). The thumbnail images came down in about 11 seconds and a full picture took about 23 seconds. This is certainly usable for getting live photos from the field.
First live photo from Masaya volcano
Today Paul used the BGAN terminal on the side of the volcano to send back live photos.
The first data to come from Nicaragua over the BGAN - thumbnail images of photos.
Yesterday as well as talking on Skype, Paul and Carlos set up the BGAN terminal on the hotel roof and sent us back the first set of photos.
Paul’s Asus Eee PC 901 was running as a web server (using LAMPP). The Linksys WRT54GL he was using as a router gave him a local wireless network and registered the IP address it was given by the BGAN terminal (operating on modem mode) with our DynDNS service.
Paul doing a five finger lag test on a Skype video call using the hotel's ADSL cable connection (8.8MB mp4 video)
Yesterday Paul and I chatted on Skype using Skype’s video phone option. Here’s the video I recorded from my screen, while we did a quick five finger test. This test involves putting up your hand and holding out your fingers then closing each finger as you count down from five to none. The video gives a reasonable indication of lag.