Hublin: open-source video conferencing

https://hubl.in/

by based2 • 10 years ago

212 55 10 years ago

hubl.in

shock• 10 years ago

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

yxlx2• 10 years ago

Empty room.

briankwest• 10 years ago

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.

dublinben4• 10 years ago

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

sleepless2• 10 years ago

Screensharing would be a great addition.

nosuchthing2• 10 years 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/ and 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• 10 years 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• 10 years 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• 10 years 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.

nosuchthing2• 10 years ago

  Your two examples are not equivalent at all.

Well yes, that's what I stipulated by mentioning

  The trade off for low/unreliable bandwidth is allowing 
  larger buffers which would impose greater latency

Video conferencing systems mostly prioritize low latency, so as bandwidth decreases (cross continent internet connections currently almost always have latency/bandwidth issues) either frames will drop, or resolution will need to drop. For our purposes of screen sharing/broadcasting we didn't care as much about low latency as much as we wanted high FPS and high resolution.

tty7• 10 years ago

well, sure. I could stream my desktop in HD @ twitch. But what about latency? Your examples don't add up.

ianbicking• 10 years 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?)

benevol2• 10 years 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...

brazzledazzle3• 10 years ago

I think they're saying the content of the video stream isn't sent to them.

brazzledazzle3• 10 years ago

I'm curious as well. My understanding is that WebRTC and group chat is a pain when done strictly p2p. I could see perhaps sending a small compressed version of the stream and increasing that when requested (like clicking on someone's feed and making it larger) but even in that scenario it seems like bandwidth could become a problem quickly. Maybe it elects a leader with the most bandwidth and they act as a relay or mux the streams?

justsaysmthng• 10 years 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.

dvirsky3• 10 years ago

Considering that Google Hangouts is perhaps the best video conferencing tool I've tried, it's not odd for me at all.

IanCal2• 10 years ago

My "dream" VC tool is basically just a stable version of google hangouts.

JoeAltmaier3• 10 years ago

Sigh. We used to make a really good tool, but it was all proprietary. It supported up to 20 participants with full-duplex audio and multiple doc sharing. But it was part of a full product for collaborative teams, and we couldn't figure out the sales process fast enough.

It scaled well - hundreds of different conference participants per server node; media nodes that supported hundreds of simultaneous streams. Stream switching was on the order of scores of milliseconds (not seconds like all the webrtc stuff).

cgh• 10 years ago

Have you ever tried Cisco's Webex? It's pretty good, plus it has desktop sharing and various other handy things.

stingraycharles• 10 years ago

You should take a look at tools like https://appear.in. They make it so easy to create ad-hoc conference rooms for people coming from different mediums (for example, sales pitches with many people accross the world, organised in under a minute).

These tools are great if you want to organise something like several people from Slack, Skype and email (customers).

krig• 10 years ago

There's also Jangouts:

https://github.com/jangouts/jangouts

yxlx2• 10 years ago

They should've named it Bangouts or Gangouts.

rectang• 10 years ago

Jeah®!!

yeukhon• 10 years 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?

cpeterso2• 10 years ago

Slack does use WebRTC:

https://bloggeek.me/slack-acquires-screenhero/

https://webrtchacks.com/dear-slack/

sleepless2• 10 years 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.

AdamGibbins• 10 years 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• 10 years ago

Do you really have more than 15 active participants, or would hangouts on air work for your use case?

dublinben4• 10 years ago

Have you tried either the web-based or desktop version of Jitsi? There's no hard cap on the number of participants.

wiz21c• 10 years ago

I've tried Jitsi a lot but on Linux, it just doesn't work well, many little bugs make it unreliable :-(

Trufa• 10 years ago

Interesting, anyone want to give it a go? 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• 10 years 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.

cpeterso2• 10 years 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-togeth...

dublinben4• 10 years ago

Jitsi Meet requires only a Chrome/Chromium extension for screen-sharing. Video conferences themselves only need the browser.

dguido• 10 years 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

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-ch...

Omnipresent• 10 years 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.

wyred• 10 years 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• 10 years ago

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

Freak_NL• 10 years 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 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• 10 years ago

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

Jemm• 10 years ago

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

vardyr• 10 years ago

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

Hublin: open-source video conferencing

Related Stories