[asterisk-dev] Asterisk and video conferencing

[Dan Cropp]

"I've been lobbying hardware manufacturers to provide video cards for Asterisk where we can have licenses to do transcoding and reformatting, so far with no success."

I passed this onto someone in our hardware department to look into.

I do worry about the thought of hardware for a video solution.  We go into a lot of hospitals.  They only want virtual servers.  Not sure that a hardware based video solution will go over very well in many markets.

For those worried about bandwidth of video, would it be possible to offload that work to another Asterisk box B?  Put audio on box A.  If you need video conferencing, have box A send that to box B? 


-----Original Message-----
From: asterisk-dev-bounces at lists.digium.com [mailto:asterisk-dev-bounces at lists.digium.com] On Behalf Of Olle E. Johansson
Sent: Monday, March 31, 2014 6:42 AM
To: Asterisk Developers Mailing List
Cc: Olle E Johansson
Subject: Re: [asterisk-dev] Asterisk and video conferencing


On 31 Mar 2014, at 12:47, Johan Wilfer <lists at jttech.se> wrote:

> Hi!
> 
> I've spent some time scratching my head thinking about video conferencing and how to go about it. Right now we use Meetme as a audio bridge for pstn connectivity and so on. But our users ask for video and screen sharing. I can see four distinct ways to go about this:
> 
> 1. Asterisk right now - supports 1-1 video, and with confbridge 1 video stream can be sent to the other participants. (The codec must match thought, and a key-frame are not sent immediate if the video source is changed so there will be a garbled video stream until next key-frame.)
> 
> 2. MCU - multiple video streams encoded in single stream. For video do the same as with audio. That means decode each stream, compose a new stream with all the participants layered out nicely. While this works for audio it consumes huge amounts of cpu to do this for video.
> 
> 3. p2p - multiple video streams sent peer to peer. Each participant sends the audio/video to every other participant. This eats a lot of bandwidth for the users and can work for smaller conferences, but in a conference with 10 participants each will have to have a very good upstream connection.
> 
> 4. Jitsi Videobridge - multiple video streams from server, but send only your stream to the server. The jitsi videobridge the distributes the stream to all other clients. This will eat a lot of bandwidth for the server, but not for the clients. This is also how Google Hangouts works. So if you are 10 participants you will send one stream to the server with your audio/video and receive 9 streams from the server for the other participants.
> 
> 
> To be able to scale reasonably I think option 2 is out of the question. And option 3, p2p, eats to much bandwidth for the clients (and doesn't require an asterisk anyway).
> 
> What you lose with option 4 is everything asterisk excels at: pstn connectivity, fine-grained control of each participant in the bridge.
> 
> What are your thoughts on adding Jitsis approach in regards to video to Asterisk for confbridge or even ARI? No composing of video, just relaying the other participants streams to each other in the bridge. Then it's up to the client in the other end to display these streams in a reasonable way (like Google Hangout, and https://meet.jit.si/).

Why? The jitsi video bridge exists and work fine :-)

What you are forgetting here is the thing that has stopped us from doing really cool stuff with video - patents and licensing. The jitsi video bridge is a nice workaround, but not optimal if you have a lot of different devices. You put the load on the device and in bandwidth-constrained environments that's not good.

Video is heavily dependend on peer2peer negotiation and doesn't really fit well in a PBX b2bua architecture... The jitsi model could work - but the SDP o/a handling would be really hard to get right in Asterisk.

I've been lobbying hardware manufacturers to provide video cards for Asterisk where we can have licenses to do transcoding and reformatting, so far with no success. Cisco's H264 codecs recently became available for us in the Open Source world thanks to a generous solution by Cisco. I guess funding is needed to add anything cool to Asterisk using them. We can do MCU-style stuff, reformatting - but to do transcoding we need another codec :-)

Google VP8 is around, I don't know what Digium's legal team have to say about us using it.

Random thoughts...

/O
-- 
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev