2014-03-31 13:41, Olle E. Johansson skrev:
On 31 Mar 2014, at 12:47, Johan Wilfer <[email protected]> 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.
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.. :-)
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
