[asterisk-dev] Asterisk and video conferencing

Mon Mar 31 08:33:37 CDT 2014

2014-03-31 15:17 GMT+02:00 Johan Wilfer <lists at jttech.se>:

> 2014-03-31 13:41, Olle E. Johansson skrev:
>
>
>> On 31 Mar 2014, at 12:47, Johan Wilfer <lists at jttech.se> wrote:
>>
> >
>
>> 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.
>>>
>>> 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 :-)
>>
>
> I think it's hard to integrate them and keep the functionality from both,
> maybe I'm wrong. But Asterisk does the audio mixing really great, and you
> have very fine-grained control on recording / muting / menu's etc. You may
> want the audio in asterisk to do video follow speaker.
>
> So that's my question - could this fit into asterisk architecture to get
> multiple videos instead of one. I find the Jitsi approach very clever to
> avoid hitting the cpu too much.
>
>

I don't think there's an easy way to do that except by placing multiple
calls (e.g., N+1, 1 for sending your audio/video and receiving the mixed
audio, N for receiving each of the remote videos) and heavily customizing
MeetMe/ConfBridge for the purpose.

A naive hack to do so using what Asterisk already provides out-of-the-box
may be to rely on N+1 ConfBridge rooms for this, e.g., have a ConfBridge
room everybody attaches to for the audio mixing, and N ConfBridge rooms
that only act as reflectors for each user's video (e.g., I call room 1234
and send my video there, everybody else who's interested in my video can
call the same room as recvonly; you call 1235 to do the same, and I call
1235 to get yours; etc.). I don't see this scaling very well (if it iven
works, that is), but it may be worth a try.

>
>  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.
>>
>
> I think this is a related but different issue. In a 1-1 call you may want
> to transcode to a different codec, or downsample to save bandwidth I think
> with VP8 you can do that by just dropping packets, if I got it correctly.
>
> On a conference-call however you may want all video streams (or just one,
> but asterisk can already do this). Regarding bandwidth people tend to have
> a lot more bandwidth downstream than upstream.
>
>
>
>> 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.
>>
>
> This is really the question, if this fits into the Asterisk architecture?
> Because I expect the clients to be able to decode and play the video
> streams. Transcoding would be cool also, but is resource intensive.
>
>
>
>> 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.
>>
>>
> Given how cpu intensive transcoding video I wouldn't like that to hit my
> cpu anyway.. :-)
>
>

That depends... we've been doing this for a while with an ad-hoc videomixer
we built for the purpose. We have a simple videomixer that receives video
frames from Asterisk and does transcoding/composition on its behalf, so
that as a client you always get a single audio/video flow no matter how
many people are in the room.

Yes, it's intensive, but not that much if you're ok with low resolutions,
or don't expect a lot of people at the same time being active. It is more
intensive when VP8 is involved, though, I guess because of the fact that
VP8 is heavier by itself.

Anyway, as I said this is currently done in an external component that
Asterisk talks to. I guess that this may at least leverage the licensing
problems Olle mentioned before, as you could have the interaction mechanism
in place and configurable, so that you only enable it if you have all the
licenses as needed (a bit how proprietary audio codec plugins can be used
right now).

Lorenzo

>  Random thoughts...
>>
>
> Thanks Olle!
>
>
> --
> Johan Wilfer
>
>
> --
> _____________________________________________________________________
> -- 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/08fc7df9/attachment-0001.html>