how to
How to create your own Local Report
Introduction:
It is very much possible for anyone to run their own Local Report, and it does not take a large scale production in order to make it work. Give time, patience, and resourcefulness, a moderately tech-savvy producer could draw on the resources given here and set up the infrastructure for running Local Reports themselves. At a minimum, running a Local Report requires an internet connection, Voice-over-IP service, a decently capable computer and collaborators with video capable mobile phones (to be reporters). Running the Local Reports as documented in this book required a relatively complicated computer setup since there were many facets to the production. If you want to run your own Local Report, you need not include every aspect of the production in order to have a successful Local Report. For example, your Local Report could be played live on a screen and speakers, then recorded and posted to the website later. In that case, you would not need to set up the streaming infrastructure. Or, you could have the event only displayed live via streaming, in which case you would not need local playback and recording capabilities.
Overview:
The Whitman Local Report was run at 5 locations over the course of 2 months. At each location we had an internet connection, several laptops, a projector and of course 30 "reporters" with mobile phones. The reporters were sent out into the local area with the task of recording video in 20 second snippets which were sent back to the Local Report head-quarters and calling in live with a verbal report as well. At the head-quarters we sequenced the video as it came in and played the audio live when the caller called. We projected this all and played the audio on large speakers for anyone to come and watch. We also streamed it out onto the internet live so anyone anywhere could watch.
Below is a breakdown of the individual pieces that comprised the project presented with the intent to help you produce your own version of the Local Report.
Mobile phones:
For the Whitman Local Report (WLR) we used 30 Nokia 7610 phones. These phones support development using Java 2 Micro Edition (J2ME) and have additional capabilities for video and networking (MIDP 2.0 and MMAPI). Now-a-days these capabilities are common on many handsets and the application that was developed for WLR could be ported to a variety of other models. The basic requirements are a video camera, support for J2ME (with MIDP 2.0 and MMAPI) with video capture.
The source code for the WLR phone application is available online at: http://www.whitmanlocalreport.net/phone/source/
If you are interested in giving it a try before attempting to modify the source, the compiled application can be downloaded directly to your phone and tested by going to the following URL: http://www.whitmanlocalreport.net/phone/Whitman_Mobile_Video.jar
There is one caveat to trying this application out, it is that the sending of the video to the Local Report server requires a data connection through your mobile phone service provider (T-Mobile, Cingular, Verizon..) and use of this data connection might cost you extra depending on your service. You should check these costs before attempting to use the application.
The source for the application can be able to be compiled and installed as is but unless you make some minor modifications, it will upload the video to the Whitman Local Report Server instead of where you might want it to go. The upload URL (HTTP POST) is hard coded into the source.
To change the upload location in the Java source you will need to modify the following line in the WhitmanMVideo.java file and input the correct URL in place of the www.whitmanlocalreport.net/phone/up.php URL: HTTPPoster poster = new HTTPPoster("http://www.whitmanlocalreport.net/phone/up.php", "post.3gp", videoBytes);
If you try the application out without modifying the source, you should be able to find the video you upload by going to: http://www.whitmanlocalreport.net/videos/
Last, this application has a couple of features/bugs/items on the to do list. We welcome any modifications or contributions back to the source should you be interested in helping out. Ok, here is the list:
1: The status indication for uploads does not accurately indicate the progress of the file upload. This is unfortunately a limitation in the Java platform on mobile devices.
2: The videos are not saved on the device. There is an attempt to utilize a "record store" to do such but it's implementation is not complete and does not function correctly.
Again with the caveat, this application requires the use of a data connection on the phone from your mobile provider. If you do not have a plan to encompasses data use you will generally be paying a premium for the service. Second, video files are generally fairly large and can eat up your allowed data usage. In other words, BE CAREFUL with how you use this until you know what it will cost.
Video Reception:
The mobile phone application uses HTTP file upload capabilities to send the video to a web server on the internet. The following very basic (and very insecure) PHP script can be used to receive the video files sent from the phone:
<? $uploadfilename = time() . "_" . rand(1000,9999) . "_" . basename($_FILES['bytes']['name']); $uploaddir = '/xxxx/xxxx/xxxx/videos/'; $uploadfile = $uploaddir . $uploadfilename; if (move_uploaded_file($_FILES['bytes']['tmp_name'], $uploadfile)) { echo "Video Sent!"; } else { echo "Error: Video Not Sent!"; } ?>
In order to use the above script, you should put the code in a text file with the extension ".php". You should also change the line that starts with "$uploaddir" to point to the location you want the video files saved on your server. You will need a webserver that can run PHP scripts and this script will have to be placed somewhere that is web accessible (you probably want it in location that you are pointing to with the mobile phone application).
Video Playback Application:
Onsite at each location we had a laptop hooked up to a projector that ran an application to play back the videos full screen as they came in from the server. This application is actually two applications, the first is called "rsync", which is an application for synchronizing files across a network. Rsync was running on the server as a "daemon", meaning it was running as a service in the background. It was configured to share the videos read-only to any connection, so that we did not need to set passwords, but didn't have to worry about someone deleting or moving the files. Rsync then also ran on the video playback laptop to download the incoming videos from the server. It was set to run using "cron", an scheduling service which ran the rsync program every few minutes to download any new videos.
The second portion is a Java application that uses QuickTime for Java (which is bundled with QuickTime and iTunes) to playback the videos in sequence with controls for playing the next and previous videos. This application only plays 3gp videos but can be modified to play other QuickTime compatible formats fairly easily.
The source for this application can be downloaded here: http://www.whitmanlocalreport.net/video_player/
On-site Computer Setup:
At each location, we had an internet connection set up and ready to go when we got there. We then set up a small network of computers to run the show. One laptop was dedicated to managing the incoming calls and playing the audio from those calls. The next laptop was used for downloading the videos from the server playing them back. Both the audio and video were sent to another laptop that combined them into a stream and sent it to the streaming server. The audio/video signal was also sent to a local projector and PA system for live playback on-site.
Server Setup:
In addition to the collection of laptops that was used on-site, there was one remote server. The server, running the Debian operating system, was located at a colocation facility in Los Angeles. It provided a number of essential functions: website hosting with the Apache web server; phone call termination and call queue system using Asterisk phone system software; custom software for receiving videos send from the phones and relaying them to the laptops on location; and, the public streaming server, running Darwin Streaming Server, that delivered the audio/video stream for the world to experience.
Phone System (PBX/Asterisk):
The central part of the voice reports is the phone system built using Asterisk. It is essentially a call queue system like any business might have when you call their customer service number. Participants dial one of the phone numbers pre-programmed into the mobile phones. Asterisk answers, plays back some basic instructions, then moves on to the hold music, announcing the caller's position in the queue whenever the a call was answered. The first caller in the queue is transferred to the extension of the software phone running on the laptop on location. This software phone acts just like a phone in an office phone system does, it has an extension number that works only within that context. When the participant is next in the queue, Asterisk played them a prompt to get them prepared to deliver their report: "Get ready, your next! When the hold music stops you are live on the air!". After the current call is hung up, the next participant is prompted, asterisk sends the next call to the software phone on location. The software phone was configured to automatically answer as soon as possible, putting the audio immediately on the air. When the current report hits a good breaking point, hit the Esc key on the laptop running the software phone. Then the call is dropped and the next one picked up, starting this process again.
To setup your own queue system you will need an Asterisk server (http://www.asterisk.org) and Voice over IP (VoIP) service. You can find lots of help for setting up Asterisk help online, so this is just an outline of what needs doing. It is probably worthwhile to get a hosting provider to install and host Asterisk for you. Once you have Asterisk running and receiving calls from normal phones (mobile or otherwise), you can setup the call queue mechanism. All of the queues are set up in a file called "queues.conf". In this file you can set up the various automated announcements, the frequency of the announcements, and which extension receives the calls from the queue. All in all, the Local Report setup only required about 10 custom settings to get the call queue working.
Next, you will need to have a piece of software called a "soft-phone" to receive the calls as they come in. For this purpose we used software called Freshtel Firefly, but there are many solid options available now, depending on which operating system your computer is running. Essentially this software works just like a phone, receiving calls using VoIP instead of a normal phone line. We hooked this phone into Asterisk to be the phone that Asterisk directed the calls to once they were in the top of the queue. Again, the setup of this is out of the scope of this document but plenty of information for configuring soft-phones to work with Asterisk can be found online.
Last, Asterisk might be one of those portions of the system that we used for our setup that might be overkill for what you want to do. Many VoIP TSP (Telephony Service Providers) allow you to configure service with them to work directly with a soft-phone. Some might even allow you to setup a queue. We used Voicepulse for our service, they come highly recommended but the industry is changing quickly and it would behoove you to shop around a bit.
Mobile Phone Configuration:
The mobile phones that we used were configured so that they would be as easy to use as possible. We wanted to make it possible to have people with no mobile phone experience be able to fully participate in Local Report. Much of this configuration was centered around making the user need as few button clicks as possible in order to make their reports. In particular, we configured the two "soft keys" to open the two relevant applications for Local Report: the video application and the contacts (for calling in).
When a participant clicked on the soft key to launch the video application, the user needed only to keep clicking on that same soft key in order to choose all of the requisite options in order to record a video and upload it to the server. The first click launched the application, the second click started recording video, the third click stopped the recording, then the remaining clicks uploaded the video. When a participant clicked on the audio soft key, they were presented with four different phone numbers to dial, all of which dial the same phone system. The participant just clicked once more to dial a number, then followed the voice prompts of the phone system to do their audio report.
Making a Video Report:
First, the participant launched the video application as described above. This would open a preview window which they could use to set up the shot. Following that, a press to video soft key (the left button) started recording. Once recording started, the border around the video preview turned red, and a countdown from 20 starts, showing the remaining recording time. The participant could compose the video however they want to within the 20 second limit. When the countdown hit zero, the participant was prompted to upload the video, which was done by a couple clicks on the video soft key (allowing the application to access the network). Once the video uploaded was complete, the participant was notified on the phone, and the video was automatically played on-site and on the stream.
Making an Audio Report:
The Asterisk phone system answered the call, played a pre-recorded welcome, then placed the call in a hold queue, complete with hold music. As the call advanced in the queue, the phone system announced the call's position in the queue. When the call was up next, the participant heard a little pep talk, getting them ready to deliver their report. When the call was finally answered, the hold music stopped and the participant was immediately speaking live on location and the stream.
Conclusion
There are indeed many parts that make up the whole system that runs a Local Report, but each of the pieces is actually relatively simple in the grand scheme of things. Fortunately, there is a lot of good, free software like Asterisk, rsync, and J2ME that this whole system is built upon. Using the software that are provided on the whitmanlocalreport.net website, your own Local Report is that much closer to happening.
© 2007 Shawn Van Every and Hans-Christoph Steiner. Some Rights Reserved.
