9 ms·

Hublin: open-source video conferencing

212 points by based2 11y ago

shock 11y ago
https://hubl.in/loyally-fine-paris https://hubl.in/loyally-fine-paris
- yxlx 11y ago
  Empty room.
briankwest 11y ago
https://www.freeswitch.org https://www.freeswitch.org does all this and then some, But does so in a traditional MCU role, It can bring WebRTC and transcode vp8,h264 and h263 and SIP Endpoints together in the same Video Conference.
- dublinben 11y ago
  It took me way too long to find what license this is published under. It appears to be MPL 1.1, btw.
sleepless 11y ago
Screensharing would be a great addition.
nosuchthing 11y ago
Video chat systems/protocols look to be somewhat stagnate/immature. I just wanted to do 720p 30FPS screen sharing across the internet (Europe to America), and this can be done with $10,000 dedicated hardware encoders and a ridiculously expensive mile for mile dedicated layer 2 network route. -OR- Alternatively, we could purchase a ~$200 elgato HDMI capture box, and create a free youtube account to stream 60FPS 1080p across the planet. Currently there is no in between for high FPS video streaming systems on the internet. There's also https://jitsi.org/ https://jitsi.org/ and https://obsproject.com/ https://obsproject.com/ , but they don't seem to allow P2P connections with buffering options. The trade off for low/unreliable bandwidth is allowing larger buffers which would impose greater latency.
- jallmann 11y ago
  If you want a dedicated circuit, then of course it's going to be expensive. But there's really no reason to spend that much money on an encoder, unless you're doing something like integrating an ASIC [1]. > Video chat systems/protocols look to be somewhat stagnate/immature Eh. There's a lot of work being done with WebRTC, but I'm not going to say that's significantly advancing the state of the art with respect to video transport -- SDP, RTP, DTLS have all coexisted for a long time. What has happened, though, is that by abstracting away media handling, the traditional "control plane" is being disintermediated. As a result, we're seeing 1) a lot of reinventing the wheel, and 2) more siloing among service providers. Both lead to feature fragmentation among providers and slows the progress of video-based services. While I'll be the first to admit that SIP (and XMPP and H.323 and BFCP and ...) is rather too involved to be used outside a fully federated telecom environment, it's a bit of a shame that a nicer signaling protocol hasn't really gained any traction in in its stead. Having most services work from a higher level baseline could reduce feature fragmentation and speed up the perceived progress of video services. And hopefully encourage more interoperability, but that's probably a lost cause... [1] I'm aware there are encoders that cost in that range, eg VBrick, and it's crazy -- you don't need to spend that much for video conferencing.
- amelius 11y ago
  > Video chat systems/protocols look to be somewhat stagnate/immature. I just wanted to do 720p 30FPS screen sharing across the internet (Europe to America) And this can't be done with any of the current clients based on webrtc, such as Hublin?
- TD-Linux 11y ago
  Your two examples are not equivalent at all. Video conferencing is generally designed for very low delays, whereas Youtube live streaming has a many second delay. This is critical to improving quality - not only can fancier video compression schemes be used with a large delay (B frames etc), but larger buffers mean that spikes in bitrate can be smoothed out. This is especially noticeable for screensharing where screen data updates tend to come in huge spikes with lulls of no changes in between.
  - 11y ago
ianbicking 11y ago
"Based on WebRTC which allows decentralized communication between browsers. Your video conference is not streamed to Hubl.in in any way." How is it doing this? Is each peer sending video to all the other peers? (I.e., with 3 users, each user has two outgoing and two incoming streams?)
- benevol 11y ago
  > How is it doing this? Good question. Until now, with WebRTC, you always needed a STUN, TURN and signaling server [0]. And I would be very surprised if they somehow managed to create a whole new architecture. It certainly seems like these servers are run centrally by Hublin. [0] http://www.html5rocks.com/en/tutorials/webrtc/infrastructure/ http://www.html5rocks.com/en/tutorials/webrtc/infrastructure...
  - brazzledazzle 11y ago
    I think they're saying the content of the video stream isn't sent to them.
    - benevol 11y ago
      In a WebRTC architecture, the media (video call stream) gets sent over a TURN server. I don't see where they say that you will set up your own TURN server.
      - brazzledazzle 11y ago
        My understanding is that STUN only coordinates connections between peers. A TURN server is required if that fails. So presumably they don't have a TURN server and only support clients that can peer with each other.
      - lallysingh 11y ago
        TURN's only needed if both sides have particularly restrictive NATs. There are also some public TURN servers. It's fairly harmless, as the media's all encrypted.
justsaysmthng 11y ago
Maybe it's just me, but I find it a bit ... odd? to have my video conferencing tool running inside the browser. I have Skype running as a separate application and I have it's icon in the Dock and I can switch to it, it runs in the background, etc. I know that this is the tool responsible for my communication. My contacts are also running it and it usually starts automatically on their system so most probably they're online. A conference tool running inside the browser doesn't have these properties. I look at it as a website which I can visit or not. This, I guess is a problem with all WebRTC implementations out there - it might be great in terms of capabilities, but it's not very practical in terms of heavy daily usage.
- dvirsky 11y ago
  Considering that Google Hangouts is perhaps the best video conferencing tool I've tried, it's not odd for me at all.
  - IanCal 11y ago
    My "dream" VC tool is basically just a stable version of google hangouts.
    - dsl 11y ago
      Hangouts Video is whitelabeled from Vidyo with some weird bolt ons to make it Googley. You could try going to them directly.
      - IanCal 11y ago
        Interesting, thanks for the tip.
      - kurczakov 11y ago
        Don't think that is a case - https://vsee.com/blog/google-hangouts-dropped-vidyo/ https://vsee.com/blog/google-hangouts-dropped-vidyo/
krig 11y ago
There's also Jangouts: https://github.com/jangouts/jangouts https://github.com/jangouts/jangouts
- yxlx 11y ago
  They should've named it Bangouts or Gangouts.
  - rectang 11y ago
    Jeah®!!
yeukhon 11y ago
WebRTC is very promising. "Hello" in Firefox is surprising stable (although I know a lot of people don't like Mozilla partnering with Telefonica) but there are occasions my remote teammates would find using Hello give them better screen resolution and latency. In one case, I was able to do real-time troubleshoot with an end-user problem over "Hello." Typically we'd use Skype or Webex. Does anyone know whether WebRTC is used in HipChat and Slack video feature?
- cpeterso 11y ago
  Slack does use WebRTC: https://bloggeek.me/slack-acquires-screenhero/ https://bloggeek.me/slack-acquires-screenhero/ https://webrtchacks.com/dear-slack/ https://webrtchacks.com/dear-slack/
- sleepless 11y ago
  HipChat uses Jitsi. Atlassian bought BlueJimp a while ago (which is the company behind jitsi). Hello doesn't have full screensharing, only browser content can be shared, which is a huge limitation.
deleted 11y ago
[deleted]
dguido 11y ago
Hah, we wrote one of these too. It's fun! Our code for it is super clean and documented if you want to learn how to use WebRTC: https://github.com/trailofbits/tubertc https://github.com/trailofbits/tubertc The hardest part is getting the signaling to work correctly over the internet (STUN/TURN/etc), which is why we advertise Tuber as only working on LANs. We tried to get some non-profit funding to finish that part up to no avail. I wonder how Hublin solved that problem? I am really glad to see one of these finally go fully open-source. It has been stupid to see conferencing app after conferencing app only available through a hosted website. How are you supposed to deprecate expensive, proprietary enterprise videochat platforms if you can't deploy behind a firewall!? ps. our logo is better than yours heh: https://blog.trailofbits.com/2015/12/15/self-hosted-video-chat-with-tuber/ https://blog.trailofbits.com/2015/12/15/self-hosted-video-ch...
- Omnipresent 11y ago
  That is really cool. Thanks for sharing. For someone with no knowledge of WebRTC, it would be helpful to have a blog post that explains the architecutre of tubertc and how it functions.
AdamGibbins 11y ago
Only supports up to 8 participants, unfortuantely. Continually on the hunt for something that takes >15 (like Hangout) and doesn't cost a bomb and is truely cross platform (Linux, Windows, OS X, Android, iOS).
- takno 11y ago
  Do you really have more than 15 active participants, or would hangouts on air work for your use case?
- dublinben 11y ago
  Have you tried either the web-based or desktop version of Jitsi? There's no hard cap on the number of participants.
  - wiz21c 11y ago
    I've tried Jitsi a lot but on Linux, it just doesn't work well, many little bugs make it unreliable :-(
    - JoeAltmaier 11y ago
      Sococo is constantly working to improve the experience (improve Jitsi). They support large conferences! And they're free to start with anyway.
Trufa 11y ago
Interesting, anyone want to give it a go? https://hubl.in/carefully-spectacular-rhone https://hubl.in/carefully-spectacular-rhone Had a quick chat with another user, works fine for this limited tryout at least. I like that adoption is not such a problem as you only have to share a link.
cheez 11y ago
Does anyone know of a good screen-sharing service that doesn't require any download or account creation? Kind of like those remote help desk apps: I want to send a link and have them sharing their screen with me, no fuss.
- cpeterso 11y ago
  Firefox Hello supports web page sharing, but not full screen sharing. Only the page sharer needs to be using Firefox. https://support.mozilla.org/en-US/kb/browse-web-pages-together-firefox-hello https://support.mozilla.org/en-US/kb/browse-web-pages-togeth...
- dublinben 11y ago
  Jitsi Meet requires only a Chrome/Chromium extension for screen-sharing. Video conferences themselves only need the browser.
wyred 11y ago
Am I the only one getting an invalid cert error? NET::ERR_CERT_AUTHORITY_INVALID Subject: hubl.in Issuer: Gandi Standard SSL CA 2 Expires on: 2017/03/06 Current date: 2016/03/16
- k33l0r 11y ago
  Seems that the server is sending an incomplete chain: https://www.ssllabs.com/ssltest/analyze.html?d=hubl.in https://www.ssllabs.com/ssltest/analyze.html?d=hubl.in (“This server's certificate chain is incomplete”)
Freak_NL 11y ago
It is nice to see all these WebRTC solutions appear. For teams wishing to do teleconferencing using any platform (mobile and desktop) this is good news. I wonder how long before a FOSS self-hosted solution is available? What I couldn't figure out from http://hubl.in http://hubl.in though; how is Linagora going to cover the costs of (and presumably raise a profit from) this service? Is it a freemium model, or is the current phase simply intended to garner interest and gain a foothold in the market?
itsnotvalid 11y ago
What a shame that Apple haven't got WebRTC supported, and I think it would still take a long way to go.
Jemm 11y ago
Doesn't run on Safari, the native Mac web browser.
- vardyr 11y ago
  Safari doesn't support WebRTC yet. https://github.com/sarandogou/webrtc-everywhere/ https://github.com/sarandogou/webrtc-everywhere/ might help, but I've never tried it so I can't vouch for it.

212 points by based2 11y ago

shock 11y ago

https://hubl.in/loyally-fine-paris https://hubl.in/loyally-fine-paris

yxlx 11y ago
Empty room.

briankwest 11y ago

https://www.freeswitch.org https://www.freeswitch.org does all this and then some, But does so in a traditional MCU role, It can bring WebRTC and transcode vp8,h264 and h263 and SIP Endpoints together in the same Video Conference.

dublinben 11y ago
It took me way too long to find what license this is published under. It appears to be MPL 1.1, btw.

sleepless 11y ago

Screensharing would be a great addition.

nosuchthing 11y ago

Video chat systems/protocols look to be somewhat stagnate/immature. I just wanted to do 720p 30FPS screen sharing across the internet (Europe to America), and this can be done with $10,000 dedicated hardware encoders and a ridiculously expensive mile for mile dedicated layer 2 network route. -OR- Alternatively, we could purchase a ~$200 elgato HDMI capture box, and create a free youtube account to stream 60FPS 1080p across the planet. Currently there is no in between for high FPS video streaming systems on the internet. There's also https://jitsi.org/ https://jitsi.org/ and https://obsproject.com/ https://obsproject.com/ , but they don't seem to allow P2P connections with buffering options. The trade off for low/unreliable bandwidth is allowing larger buffers which would impose greater latency.

jallmann 11y ago
If you want a dedicated circuit, then of course it's going to be expensive. But there's really no reason to spend that much money on an encoder, unless you're doing something like integrating an ASIC [1]. > Video chat systems/protocols look to be somewhat stagnate/immature Eh. There's a lot of work being done with WebRTC, but I'm not going to say that's significantly advancing the state of the art with respect to video transport -- SDP, RTP, DTLS have all coexisted for a long time. What has happened, though, is that by abstracting away media handling, the traditional "control plane" is being disintermediated. As a result, we're seeing 1) a lot of reinventing the wheel, and 2) more siloing among service providers. Both lead to feature fragmentation among providers and slows the progress of video-based services. While I'll be the first to admit that SIP (and XMPP and H.323 and BFCP and ...) is rather too involved to be used outside a fully federated telecom environment, it's a bit of a shame that a nicer signaling protocol hasn't really gained any traction in in its stead. Having most services work from a higher level baseline could reduce feature fragmentation and speed up the perceived progress of video services. And hopefully encourage more interoperability, but that's probably a lost cause... [1] I'm aware there are encoders that cost in that range, eg VBrick, and it's crazy -- you don't need to spend that much for video conferencing.
amelius 11y ago
> Video chat systems/protocols look to be somewhat stagnate/immature. I just wanted to do 720p 30FPS screen sharing across the internet (Europe to America) And this can't be done with any of the current clients based on webrtc, such as Hublin?
TD-Linux 11y ago
Your two examples are not equivalent at all. Video conferencing is generally designed for very low delays, whereas Youtube live streaming has a many second delay. This is critical to improving quality - not only can fancier video compression schemes be used with a large delay (B frames etc), but larger buffers mean that spikes in bitrate can be smoothed out. This is especially noticeable for screensharing where screen data updates tend to come in huge spikes with lulls of no changes in between.
- 11y ago

ianbicking 11y ago

"Based on WebRTC which allows decentralized communication between browsers. Your video conference is not streamed to Hubl.in in any way." How is it doing this? Is each peer sending video to all the other peers? (I.e., with 3 users, each user has two outgoing and two incoming streams?)

benevol 11y ago
> How is it doing this? Good question. Until now, with WebRTC, you always needed a STUN, TURN and signaling server [0]. And I would be very surprised if they somehow managed to create a whole new architecture. It certainly seems like these servers are run centrally by Hublin. [0] http://www.html5rocks.com/en/tutorials/webrtc/infrastructure/ http://www.html5rocks.com/en/tutorials/webrtc/infrastructure...
- brazzledazzle 11y ago
  I think they're saying the content of the video stream isn't sent to them.
  - benevol 11y ago
    In a WebRTC architecture, the media (video call stream) gets sent over a TURN server. I don't see where they say that you will set up your own TURN server.
    - brazzledazzle 11y ago
      My understanding is that STUN only coordinates connections between peers. A TURN server is required if that fails. So presumably they don't have a TURN server and only support clients that can peer with each other.
    - lallysingh 11y ago
      TURN's only needed if both sides have particularly restrictive NATs. There are also some public TURN servers. It's fairly harmless, as the media's all encrypted.

justsaysmthng 11y ago

Maybe it's just me, but I find it a bit ... odd? to have my video conferencing tool running inside the browser. I have Skype running as a separate application and I have it's icon in the Dock and I can switch to it, it runs in the background, etc. I know that this is the tool responsible for my communication. My contacts are also running it and it usually starts automatically on their system so most probably they're online. A conference tool running inside the browser doesn't have these properties. I look at it as a website which I can visit or not. This, I guess is a problem with all WebRTC implementations out there - it might be great in terms of capabilities, but it's not very practical in terms of heavy daily usage.

dvirsky 11y ago
Considering that Google Hangouts is perhaps the best video conferencing tool I've tried, it's not odd for me at all.
- IanCal 11y ago
  My "dream" VC tool is basically just a stable version of google hangouts.
  - dsl 11y ago
    Hangouts Video is whitelabeled from Vidyo with some weird bolt ons to make it Googley. You could try going to them directly.
    - IanCal 11y ago
      Interesting, thanks for the tip.
    - kurczakov 11y ago
      Don't think that is a case - https://vsee.com/blog/google-hangouts-dropped-vidyo/ https://vsee.com/blog/google-hangouts-dropped-vidyo/

krig 11y ago

There's also Jangouts: https://github.com/jangouts/jangouts https://github.com/jangouts/jangouts

yxlx 11y ago
They should've named it Bangouts or Gangouts.
- rectang 11y ago
  Jeah®!!

yeukhon 11y ago

WebRTC is very promising. "Hello" in Firefox is surprising stable (although I know a lot of people don't like Mozilla partnering with Telefonica) but there are occasions my remote teammates would find using Hello give them better screen resolution and latency. In one case, I was able to do real-time troubleshoot with an end-user problem over "Hello." Typically we'd use Skype or Webex. Does anyone know whether WebRTC is used in HipChat and Slack video feature?

cpeterso 11y ago
Slack does use WebRTC: https://bloggeek.me/slack-acquires-screenhero/ https://bloggeek.me/slack-acquires-screenhero/ https://webrtchacks.com/dear-slack/ https://webrtchacks.com/dear-slack/
sleepless 11y ago
HipChat uses Jitsi. Atlassian bought BlueJimp a while ago (which is the company behind jitsi). Hello doesn't have full screensharing, only browser content can be shared, which is a huge limitation.

deleted 11y ago

[deleted]

dguido 11y ago

Hah, we wrote one of these too. It's fun! Our code for it is super clean and documented if you want to learn how to use WebRTC: https://github.com/trailofbits/tubertc https://github.com/trailofbits/tubertc The hardest part is getting the signaling to work correctly over the internet (STUN/TURN/etc), which is why we advertise Tuber as only working on LANs. We tried to get some non-profit funding to finish that part up to no avail. I wonder how Hublin solved that problem? I am really glad to see one of these finally go fully open-source. It has been stupid to see conferencing app after conferencing app only available through a hosted website. How are you supposed to deprecate expensive, proprietary enterprise videochat platforms if you can't deploy behind a firewall!? ps. our logo is better than yours heh: https://blog.trailofbits.com/2015/12/15/self-hosted-video-chat-with-tuber/ https://blog.trailofbits.com/2015/12/15/self-hosted-video-ch...

Omnipresent 11y ago
That is really cool. Thanks for sharing. For someone with no knowledge of WebRTC, it would be helpful to have a blog post that explains the architecutre of tubertc and how it functions.

AdamGibbins 11y ago

Only supports up to 8 participants, unfortuantely. Continually on the hunt for something that takes >15 (like Hangout) and doesn't cost a bomb and is truely cross platform (Linux, Windows, OS X, Android, iOS).

takno 11y ago
Do you really have more than 15 active participants, or would hangouts on air work for your use case?
dublinben 11y ago
Have you tried either the web-based or desktop version of Jitsi? There's no hard cap on the number of participants.
- wiz21c 11y ago
  I've tried Jitsi a lot but on Linux, it just doesn't work well, many little bugs make it unreliable :-(
  - JoeAltmaier 11y ago
    Sococo is constantly working to improve the experience (improve Jitsi). They support large conferences! And they're free to start with anyway.

Trufa 11y ago

Interesting, anyone want to give it a go? https://hubl.in/carefully-spectacular-rhone https://hubl.in/carefully-spectacular-rhone Had a quick chat with another user, works fine for this limited tryout at least. I like that adoption is not such a problem as you only have to share a link.

cheez 11y ago

Does anyone know of a good screen-sharing service that doesn't require any download or account creation? Kind of like those remote help desk apps: I want to send a link and have them sharing their screen with me, no fuss.

cpeterso 11y ago
Firefox Hello supports web page sharing, but not full screen sharing. Only the page sharer needs to be using Firefox. https://support.mozilla.org/en-US/kb/browse-web-pages-together-firefox-hello https://support.mozilla.org/en-US/kb/browse-web-pages-togeth...
dublinben 11y ago
Jitsi Meet requires only a Chrome/Chromium extension for screen-sharing. Video conferences themselves only need the browser.

wyred 11y ago

Am I the only one getting an invalid cert error? NET::ERR_CERT_AUTHORITY_INVALID Subject: hubl.in Issuer: Gandi Standard SSL CA 2 Expires on: 2017/03/06 Current date: 2016/03/16

k33l0r 11y ago
Seems that the server is sending an incomplete chain: https://www.ssllabs.com/ssltest/analyze.html?d=hubl.in https://www.ssllabs.com/ssltest/analyze.html?d=hubl.in (“This server's certificate chain is incomplete”)

Freak_NL 11y ago

It is nice to see all these WebRTC solutions appear. For teams wishing to do teleconferencing using any platform (mobile and desktop) this is good news. I wonder how long before a FOSS self-hosted solution is available? What I couldn't figure out from http://hubl.in http://hubl.in though; how is Linagora going to cover the costs of (and presumably raise a profit from) this service? Is it a freemium model, or is the current phase simply intended to garner interest and gain a foothold in the market?

itsnotvalid 11y ago

What a shame that Apple haven't got WebRTC supported, and I think it would still take a long way to go.

Jemm 11y ago

Doesn't run on Safari, the native Mac web browser.

vardyr 11y ago
Safari doesn't support WebRTC yet. https://github.com/sarandogou/webrtc-everywhere/ https://github.com/sarandogou/webrtc-everywhere/ might help, but I've never tried it so I can't vouch for it.