Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Twilio Video – Real-time WebRTC video infrastructure

twilio.com

Post reply on HN
Print view View original

91–100 of 106 posts

Re: Twilio Video – Real-time WebRTC video infrastructure

#91

Post by emcho »

JoeAltmaier wrote: post #23
jgrowl wrote: post #20

Earlier quoted context omitted.

Thought I'd mention jitsi ( https://jitsi.org ) since it seems to aim to do what you are wanting. I am not sure how many connections it practically supports currently though.

Jitsi, licode, janus ... there are a whole list of them, open-source. Unfortunately they conflate the MCU feature with the SDP exchange feature. Which may or may not suit your application. For instance if you want to connect clients in anything but an everyone-in-the-room-hears-everyone-else model, they don't support anything else.

Joe, this is actually not true. At least not for Jitsi where we have things like last N and possibilities to have 1:m or n:m sessions ...

There's also absolutely no usage of SDP Offer/Answer in Jitsi Videobridge

Re: Twilio Video – Real-time WebRTC video infrastructure

#92

Post by tjkells »

walterbell wrote: post #80
tjkells wrote: post #55

Earlier quoted context omitted.

Shameless plug here, but if you're interested in voice platforms and are growing weary of Twilio, I'm working on a new hosted telephony platform that uses embedded lua executing directly on our hosted servers. Check it out - https://developers.corvisa.com/

Why did you choose Lua?

It was designed to be embedded, has a very small footprint, is relatively fast ( we use luajit ), and has few opinions as a language. That said, there is nothing locking us in to lua permanently as we would just need to implement a small-ish set of language bindings and docker configs to execute the language du jour.

Re: Twilio Video – Real-time WebRTC video infrastructure

#93

Post by emcho »

kolencherry wrote: post #26
JoeAltmaier wrote: post #23

Earlier quoted context omitted.

Jitsi, licode, janus ... there are a whole list of them, open-source. Unfortunately they conflate the MCU feature with the SDP exchange feature. Which may or may not suit your application. For instance if you want to connect clients in anything but an everyone-in-the-room-hears-everyone-else model, they don't support anything else.

Bingo. You hit the nail on the head. To efficiently do large conferences, you need to both multiplex audio and video at the media server layer and have a concept of active speakers.

Jitsi Videobridge has both of those.

Re: Twilio Video – Real-time WebRTC video infrastructure

#94

Post by jumpchat »

kolencherry wrote: post #31
Everhusk wrote: post #30

It would be useful to know which browsers are supported for javascript developers. I am using OpenTOK for Real-time WebRTC at the moment which works great, but it doesn't have safari support. Would definitely consider switching if this worked on all browsers!

Chrome and Firefox are the only browsers supported WITHOUT plugins. Look into the plugin that Temasys makes, which enables support for IE and Safari. It's relatively trivial to write a shim for said plugin. IE will bring native WebRTC support in the next version of IE.

WebRTC on Opera works without plugins also.

Re: Twilio Video – Real-time WebRTC video infrastructure

#95

Post by stpeter »

jc4p wrote: post #4

I was really excited by the title but this seems a bit lacking. I've done a lot of WebRTC work -- we currently use Google Hangouts everywhere at Stack Exchange for internal team communication, but the 15 person cap hurts some bigger all-hands calls or our weekly remote parties. I don't think the hardest part of WebRTC is transcoding or TURN servers (what Twilio seems to be offering), multiplexing is where all the com…

Some Ns are larger than others. :-) At Talky, we can scale up to 15-25 participants using the excellent Jitsi Videobridge as a selective forwarding unit, and the results are similar at Jitsi Meet. Even at that relatively small scale, your browser might melt down depending on your hardware. Beyond ~25 we'll need to look at something more like a broadcast scenario a la Hangouts on Air (e.g., do you really need 25+ people actively participating and sending video at the same time?). As gz5 notes, that might imply a need for session control and moderation queues and such, or a larger group of passive audience members with the ability to temporarily grant send privileges to select users as needed. Those are all fun problems to solve. :-)

Re: Twilio Video – Real-time WebRTC video infrastructure

#96

Post by lozf »

talltofu wrote: post #71

Awesome. Will try it soon. What would HN readers recommendfor near zero latency audio only? Our client needs to connect two devices within a LAN (no throughput issue) but near zero latency. We have tried Twilio PSTN, other webrtc technologies but they all have noticeable (half a second) delay from device to device. Any thoughts?

Try https://now.source-elements.com/#!/ Voice studios can manage to sync ProTools sessions on opposite sides of the Atlantic to within quarter of a frame, so on LAN it should manage nearer Opus' default of ~20ms.

Re: Twilio Video – Real-time WebRTC video infrastructure

#97

Post by talltofu »

joeyspn wrote: post #86
talltofu wrote: post #71

Awesome. Will try it soon. What would HN readers recommendfor near zero latency audio only? Our client needs to connect two devices within a LAN (no throughput issue) but near zero latency. We have tried Twilio PSTN, other webrtc technologies but they all have noticeable (half a second) delay from device to device. Any thoughts?

You could try a SIP client with a low latency codec like CELT...

Thanks for your reply. Do you have any recommendations?

Re: Twilio Video – Real-time WebRTC video infrastructure

#99

Post by mcs »

jc4p wrote: post #4

I was really excited by the title but this seems a bit lacking. I've done a lot of WebRTC work -- we currently use Google Hangouts everywhere at Stack Exchange for internal team communication, but the 15 person cap hurts some bigger all-hands calls or our weekly remote parties. I don't think the hardest part of WebRTC is transcoding or TURN servers (what Twilio seems to be offering), multiplexing is where all the com…

Blue Jeans solves this at scale, with higher quality than WebRTC alone, while also supporting video conferencing equipment joining the same meetings.

Transcoding is tough with unique views per client, but audio processing is tougher. :)

Re: Twilio Video – Real-time WebRTC video infrastructure

#100

Post by TD-Linux »

gz5 wrote: post #53
dirtyaura wrote: post #37

I did a lot of testing of a few WebRTC platforms last summer for a product idea that we had. I came to the conclusion that on mobile phones, WebRTC video is not yet usable. Even with just audio on a cellular network, call quality started deteriorating after a few minutes on every platform that I tried. Video without a WiFi signal was hopeless. I discussed this with an WebRTC expert, and the problems are partly with W…

The issue is mostly due to the nature of the mobile IP, rather than inherent WebRTC variables. However, ORTC does seek to improve with simulcast/SVC, and attributes of ORTC will merge into WebRTC as well, ultimately providing more hooks, finer-grained control and better instrumentation/visibility to the upper layers. All that said, you can do acceptable quality WebRTC voice and video over 4G LTE today. But you do nee…

ORTC is just an API.

The WebRTC protocol itself is defined in RTCWEB at the IETF and based on the existing RTP and RTCP transports, and SCTP transport layer. I don't think you'll be able to do better.

Post reply on HN