4 ms·

I really wish there were non-browser implementations of WebRTC. So far, it seems like the standard as-it-is is defined by browser code and browsers contain the

I really wish there were non-browser implementations of WebRTC. So far, it seems like the standard as-it-is is defined by browser code and browsers contain the canonical implementations.

brian-armstrong 8y ago
Does https://webrtc.googlesource.com/src https://webrtc.googlesource.com/src not count?
- Karrot_Kream 8y ago
  Right, so it's a chromium C++ repo that you need to create bindings for to interact with. I have no doubt that an organization like Discord has the engineering resources to either write their own bindings to WebRTC or to roll their own implementation of the components, but if I'm a an individual developer that wants to interact with WebRTC without a browser, then it's pretty difficult. One common desired use case is using WebRTC for p2p torrent communications. Right now the best way to do this is in browser, or to use an Electron app that can bridge the WebRTC clients with the standard desktop torrent clients.
  - brian-armstrong 8y ago
    Ah that makes sense. I have seen forks that de-chromium it some that look pretty reasonable. Most of it doesn't depend on anything chromium, just happens to use its build system (for better or worse). But I believe the fork switches it to CMake
  - jgrowl 8y ago
    There's nothing tied specifically to the browser, but it is written in C++. It seems like the discord folks just built a layer on top of it. It's been a while since I played around with it, but you just have to build the peerconnection library. This guide seems pretty close to what I remember having to do: https://webrtc.org/native-code/development/ https://webrtc.org/native-code/development/ It still leaves you writing in c++, but it lets you build a self contained server without any browser stuff. There also were java bindings which is what I used when I was experimenting with it. You just have to build your .so and .jar files. EDIT: Here's some scala code that I wrote that uses the native bindings. (Please forgive the messy test project that I have abandoned). https://github.com/jgrowl/livehq/blob/master/media/src/main/scala/tv/camfire/media/webrtc/WebRtcHelper.scala https://github.com/jgrowl/livehq/blob/master/media/src/main/...
  - Orphis 8y ago
    There are Java Android and ObjC iOS bindings available in the repository. Not sure how those would work in a regular JRE or ObjC macOS environment, but it should be alright (but then, you might as well use the C++ API directly on macOS, just saying).
fulafel 8y ago
From the article: "Our desktop, iOS, and Android applications, however, make use of a single C++ media engine built on top of the WebRTC native library — specifically tailored to the needs of our users."
Sean-Der 8y ago
There are implementations that don't use libwebrtc/Chromium at all like pions-WebRTC[0] Or do you want something that has a completely different API? It would be nice to be able to ignore the JS idioms, but it is tough to start from scratch. [0]https://github.com/pions/webrtc https://github.com/pions/webrtc
- shazow 8y ago
  pions' webrtc is the only third-party implementation with that level of completeness, and it's not very complete yet. It's super new (months old), but it's exciting! See issues: https://github.com/pions/webrtc/issues https://github.com/pions/webrtc/issues There are many aspirational repos that have been started over the years with the intention to implement WebRTC but very few of them actually made good progress. I too would love more third-party language-native implementations. Right now everyone is binding to the C++ codebase. The real problem without having language-native implementation is that it creates a protocol rift. Things like BitTorrent vs WebTorrent, or IPFS native vs IPFS JS: It's effectively UDP/TCP vs WebRTC, clients on one end (native apps that aren't NodeJS) can't speak to clients on the other end (browsers) without a relay bridge (which is always NodeJS).
anderspitman 8y ago
I agree. This is a major barrier to adoption of many exciting technologies, in my estimation. See for example[0] [0] https://github.com/webtorrent/webtorrent/issues/1492 https://github.com/webtorrent/webtorrent/issues/1492

I really wish there were non-browser implementations of WebRTC. So far, it seems like the standard as-it-is is defined by browser code and browsers contain the canonical implementations.

brian-armstrong 8y ago

Does https://webrtc.googlesource.com/src https://webrtc.googlesource.com/src not count?

Karrot_Kream 8y ago
Right, so it's a chromium C++ repo that you need to create bindings for to interact with. I have no doubt that an organization like Discord has the engineering resources to either write their own bindings to WebRTC or to roll their own implementation of the components, but if I'm a an individual developer that wants to interact with WebRTC without a browser, then it's pretty difficult. One common desired use case is using WebRTC for p2p torrent communications. Right now the best way to do this is in browser, or to use an Electron app that can bridge the WebRTC clients with the standard desktop torrent clients.
- brian-armstrong 8y ago
  Ah that makes sense. I have seen forks that de-chromium it some that look pretty reasonable. Most of it doesn't depend on anything chromium, just happens to use its build system (for better or worse). But I believe the fork switches it to CMake
- jgrowl 8y ago
  There's nothing tied specifically to the browser, but it is written in C++. It seems like the discord folks just built a layer on top of it. It's been a while since I played around with it, but you just have to build the peerconnection library. This guide seems pretty close to what I remember having to do: https://webrtc.org/native-code/development/ https://webrtc.org/native-code/development/ It still leaves you writing in c++, but it lets you build a self contained server without any browser stuff. There also were java bindings which is what I used when I was experimenting with it. You just have to build your .so and .jar files. EDIT: Here's some scala code that I wrote that uses the native bindings. (Please forgive the messy test project that I have abandoned). https://github.com/jgrowl/livehq/blob/master/media/src/main/scala/tv/camfire/media/webrtc/WebRtcHelper.scala https://github.com/jgrowl/livehq/blob/master/media/src/main/...
- Orphis 8y ago
  There are Java Android and ObjC iOS bindings available in the repository. Not sure how those would work in a regular JRE or ObjC macOS environment, but it should be alright (but then, you might as well use the C++ API directly on macOS, just saying).

fulafel 8y ago

From the article: "Our desktop, iOS, and Android applications, however, make use of a single C++ media engine built on top of the WebRTC native library — specifically tailored to the needs of our users."

Sean-Der 8y ago

There are implementations that don't use libwebrtc/Chromium at all like pions-WebRTC[0] Or do you want something that has a completely different API? It would be nice to be able to ignore the JS idioms, but it is tough to start from scratch. [0]https://github.com/pions/webrtc https://github.com/pions/webrtc

shazow 8y ago
pions' webrtc is the only third-party implementation with that level of completeness, and it's not very complete yet. It's super new (months old), but it's exciting! See issues: https://github.com/pions/webrtc/issues https://github.com/pions/webrtc/issues There are many aspirational repos that have been started over the years with the intention to implement WebRTC but very few of them actually made good progress. I too would love more third-party language-native implementations. Right now everyone is binding to the C++ codebase. The real problem without having language-native implementation is that it creates a protocol rift. Things like BitTorrent vs WebTorrent, or IPFS native vs IPFS JS: It's effectively UDP/TCP vs WebRTC, clients on one end (native apps that aren't NodeJS) can't speak to clients on the other end (browsers) without a relay bridge (which is always NodeJS).

anderspitman 8y ago

I agree. This is a major barrier to adoption of many exciting technologies, in my estimation. See for example[0] [0] https://github.com/webtorrent/webtorrent/issues/1492 https://github.com/webtorrent/webtorrent/issues/1492