[MLB-WIRELESS] Re: Streaming Wifi
TSwireless
wireless at toysatellite.org
Mon Dec 15 16:25:16 EST 2003
hi peter - we set up a trial wireless streaming project last year and used
entirely open source tools running on linux.
http://toysatellite.org/wireless/
the following is an extract from our yet to be published report:
---
For the streaming we used ffmpeg, an open-source project that is
freely available from http://ffmpeg.sourceforge.net/ . We chose ffmpeg
for it's ability to do on-the-fly encoding to multiple formats
concurrently, thus avoiding being bound to platform specific, or
rather, biased codecs. Ffmpeg is comprised of two components: 'ffmpeg'
and 'ffserver'; 'ffmpeg' does capture and encoding and then outputs to
ffserver and/or to file(s); 'ffserver' then provides streams to
clients connecting over a network. Ffserver runs under Linux, and
there are versions of ffmpeg available for both Linux and Windows.
Due to limited resources and the heavy processing demands of encoding
to multiple formats we had to choose among codecs to support and in
the end went with mpeg (MPEG1 multiplexed video and audio) for the
audio/visual stream, and audio-only mp2 (MPEG audio layer 2).
We encoded two mpeg streams, one of a fairly high quality, and another
of a lower quality for those with less bandwidth. The one mp2 audio
stream was of an average quality, this not being such a concern with
voice-only transmission. The encoder component of ffmpeg has the
ability to output to multiple destinations, thus we sent one stream to
a local ffserver, one to another ffserver in Sweden, and another to
the hard disk for archival purposes. Adam (*-surname-*) from
free2air.org was also 'mirroring' the mp2 stream by running a client
from the server in Sweden and then re-serving it over an icecast
server based in London.
There were a couple of 'hitches' to the evening. Ironically, given the
evening's focus on wireless technologies, we were restricted by the
cable-length of our video recorder and microphone equipment, which
meant that the footage was not as clear as we would have liked.
Also, unfortunately, certain client programs (namely, Realplayer under
Windows) had problems with the video stream and constantly fell back
into "buffering" mode. It's possible we may get around this in the
future with creative use of URL or mime encoding, or it may be a
matter of experimenting with different bitrates under a variety of
network conditions and seeing what works best for all clients. Linux
clients didn't seem to suffer from this problem.
---
hope this helps...
-ag.
---
Andrew Garton
c2o/Toy Satellite - computer mediated art for public space
T/F: +61 (0)3 9417 5425
:: agarton at toysatellite.org
:: http://c2o.org
:: http://toysatellite.org
----------------------------------------------------------
A member of the Association for Progressive Communications
To unsubscribe: send mail to majordomo at wireless.org.au
with "unsubscribe melbwireless" in the body of the message
More information about the Melbwireless
mailing list