[asterisk-dev] Asterisk and video conferencing

[Bryant Zimmerman]

Sangoma has trans coding solutions that allow for use with virtual 
machines. They had video codecs in their road map. I am not sure if they 
have them yet?
  
 Thanks

Bryant Zimmerman (ZK Tech Inc.)
616-855-1030 Ext. 2003
  

----------------------------------------
 From: "Dan Cropp" <dan at amtelco.com>
Sent: Monday, March 31, 2014 12:02 PM
To: "Asterisk Developers Mailing List" <asterisk-dev at lists.digium.com>
Subject: Re: [asterisk-dev] Asterisk and video conferencing   
"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

--
_____________________________________________________________________
-- 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
 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140331/53c77176/attachment.html>