"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: [email protected] [mailto:[email protected]] 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 <[email protected]> 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 -- _____________________________________________________________________ -- 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
