Streaming Events
Testing
There are two truths when it comes to testing :
- you can never do enough
- you never do enough
I prefer to test the setup as much as possible within a context that is as close to 'the real thing' as possible. For example, testing the technical systems is one thing, but if you tested on a sunday and there is plenty of bandwidth, then the event happens on the next day there might be no bandwidth available because everyone in the building is at work and online. This kind of thing really happens and can cause real issues.
So test the setup with a mock run through in a situation that will closely resemble the day of the event.
When it comes to testing, make a check list and run through it several times. A list might include :
- is the audio signal strong?
- do you have all the audio feeds (laptops, mics, video etc)?
- is the lighting going to be enough for the cameras?
- will the audience be in the way of the cameras?
- will the cameras be in the way of the audience?
- is the encoder stable?
- do you have the titles ready and are they spelt correctly?
- is the compressor set up correctly?
- is the video mixer set up correctly?
- are the cables out of the way?
- do you know what signal each of the cables carries?
- is there enough bandwidth?
- is the stream stable?
- is the load on the server ok?
- does the team know what they are doing!?
When testing the stream itself make sure you test the outgoing stream with someone that is outside the building where the event is. Also, make sure you test the stream on an ongoing basis by receiving the stream from the server. The best way to do this is to wear headphones so you can listen to the stream and continue to work on other things, then if the audio cuts out you can check for problems. It will mean that you are in two 'time zones' at once as the stream will be slightly delayed and behind the events in the room, but with a little practice this becomes a normal way to work.
Be very careful when testing a stream locally while using a not so high bandwidth connection, you might end up jamming your connection since you it will mean uploading and downloading data at the same time. So, if you stream at a bit rate of say 96kbps you will requiere 96kbps free to download. Needless to say that having other applications running on the same machine and making intense use of the network resources could also jamm your connection. So no bittorrent clients should be open on the same network.
When you have the appropiate conditions and have access to the Icecast server, there is a software application called Iperf.
It will allow us to audit the up and down links to the server:
Log into your server, install and run iperf with the command:
iperf -s --port 9000
iperf will then be listening on port 9000.
Then you will be ready to run from a client located within the network you intent to use the following command:
iperf -c IPofServer --port 9000 -w 256k -t 60
the above command will send 256k to the server for 60 seconds, the image below shows the results of such test from the network of St. Oberholz Cafe in Berlin:
I clear that this is not a good place from where to stream, as suggested before, try always to avoid the use of wireless networks for streaming.
Testing the Future
Also, its good to anticipate as many problems as you can. Its good to know where the circuit board is (in case a fuse pops), where the internet connection comes in how it is setup, whos in charge of what etc.