Re: [LAD] Streaming AV/midi

From: Patrick Shirkey <pshirkey@email-addr-hidden>
Date: Wed Jul 02 2014 - 13:31:20 EEST

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@email-addr-hidden
>> http://lists.linuxaudio.org/listinfo/linux-audio-dev
>

--
Patrick Shirkey
Boost Hardware Ltd
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Wed Jul 2 16:15:02 2014

This archive was generated by hypermail 2.1.8 : Wed Jul 02 2014 - 16:15:02 EEST