On Wed, July 2, 2014 2:22 pm, Flávio Schiavoni wrote: > Hi Patrick > > A first advice is to try some tool that works with multicast / broadcast > addressing method to allow a one to many connection. It means to work > with UDP because TCP can not do multicast or broadcast. So you can save > some bandwidth. Since RTP is not a transport protocol but a kind of > application protocol over UDP, a tool RTP based can be used. If I'm not > wrong, Icecast works with TCP. I dunno if it can be configured. >
Thanks for that tip. I am currently looking at ffserver with ffmpeg. IIUC it can support RTP too so that might be a good way forward. I have it running on my device and I am testing the stream/codec combinations at the moment. Gotta hand it to the ffmpeg devs for keeping keeping pace with the market. > Some questions: > - Do you need to sync audio / video / MIDI? Not really sample accurate but 2000ms is the limit for lag. > - What is your audio / video / MIDI source? File? Cam? /dev/graphics/fb0 + external BT microphone > - How will it be used on the receiver? Monitor? Projector? If I use ffserver the output will be displayed as a video stream at the application level. > > Pure Data can send audio / midi / video. > I will look into PD if ffserver is unable to get the job done. > If I'm not wrong, GStreamer can do it too. > > Cheers > > Schiavoni > > Em 01-07-2014 06:34, Patrick Shirkey escreveu: >> Hi, >> >> Does anyone have a suggestion for open source solutions to enable >> streaming AV/midi to multiple ARM mobile devices with a one to many >> network configuration? >> >> I am looking at the following options: >> >> 1: ffmpeg streaming server >> 2: icecast with netjack >> 3: netjack >> >> There are some limitations. >> >> 1: Server is a mobile device with dual core ARM chipset >> 2: Wifi connectivity with 20Mb/s total uplink from master server. >> >> An ideal implementation would allow 20 client devices to receive the >> audio >> stream in close to realtime. Upto 100ms delay would be acceptable. >> >> I'm weighing up the benefits from using FFMPEG to stream all the data >> compared to a 32/64bit icecast stream with additional midi triggering >> for >> visual data located on the client app. >> >> - FFMPEG has the benefit of removing all trigger events but costs a lot >> in >> terms of bandwidth/power consumption. >> >> - Icecast is very good at serving audio but iiuc does not support >> video/midi >> >> - Netjack can potentially do all three but is not well tested on a >> mobile >> platform. >> >> >> >> >> -- >> Patrick Shirkey >> Boost Hardware Ltd >> _______________________________________________ >> Linux-audio-dev mailing list >> Linux-audio-dev@lists.linuxaudio.org >> http://lists.linuxaudio.org/listinfo/linux-audio-dev > -- Patrick Shirkey Boost Hardware Ltd _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev