As WebRTC enthusiasts, we were frustrated by the lack of awareness of the technology and how difficult it was to find non-commercial, in-depth information from actual practitioners.
Our goal is to bring knowledge of WebRTC and related technologies with the practical expertise to anyone with interest at absolutely no charge to the viewer. We invite the industry’s most respected practitioners to speak at intimate events where the focus is on the talks. We strictly review, refine, and rehearse the content to make sure it is compelling and useful. We always the needs of the audience before sponsors. We make all our content in its entirety is freely available to all. We strive to provide remote and post-event viewers a first-class experience, no matter where or when they happen to be watching.
Kranky Geek is organzied by Tsahi Levant-Levi, Chris Koehncke, and Chad Hart.
When you encrypt using a transform streams, aren't the chunks bytelength unterdermined? so when it comes to decrypting also using a stream, the bytelength per chunk may also be different, hence the same key will fail? shouldn;t the chunk size going in and coming out be the same.
I need your help. What kind of video do you recommend to do like the link below. He forwarded it many times. Thanks, ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-mgPRqjJCUyE.html
This video was so great. We are building a device and everything is in Kubernetes and I can build anything on a node server but the device is a C Yocto implementation with G Streamer. We currently in the POC phase have a RTMP stream working with AMS but the latency is not desirable and the cost seems, in scale, prohibitive. But it works. From this video I am thinking mediasoup would be a great place to start. I use case is 1 to 1 or 1 to few. Not a broadcasting situation at all. The only thing I am confused at the moment is about Janus and how that might work in a linux VM container situation. Node makes obvious sense but should or would the Janus server make even more sense?
Have been looking into WebRTC for P2P connections, which is sweet. BUT, my only snag with P2P is exposing the IP Addresses to each other (network sniffer). It just seems like a security risk to me ... Why don't the ISPs have a service to allow NAT to occur at the ISP level (as well). A separate NAT of sorts that simply doesn't expose your public IP. Instead, it serves as the public IP, and respond back to your computer via your IP infrastructure that it knows about (since you sent the request). Seems like a no brainer to me. They could even charge money for this. Get the P2P and the security to boot! ISP even takes a profit. It's a three for. Call it "Secure Peer"
@@jeffg4686 There are server forwarding units, which work as p2p party. When you use pion it may run behind nat on iot device, or on a server with a public ip. You can make all kinds of connections, you want. When sfu has a public ip you don't even need turn server. Ice will connect you directly to the server, without any stun or nat servers.
Any thoughts on usage for just pure data. The idea being a game server running on one of the clients with say up to 30 or so people connected. They'd be the one with the solid connection and processing power. This design would avoid everyone piling through a central hub (for all the packets during game play), and costly server fees.
He was far too polite in the way he dealt with that fool at the end who didn't comprehend that latency is generally much worse than packet loss for VoIP (and that a VPN generally makes a bad situation worse). :-)
The constant switch between the speaker and the slides is distracting^10. The presentation was great but please, keep the slides up and the speaker(s) to the right, it's fine.
I think "Vonage" also use Jitsi in it's underlying layer. and 'simulcast' is actually a webRTC feature (and jitsi use it) and 'enableLayerSuspension' is the feature jitsi team developed by tricking the webRTC (limiting the up bandwidth from client side when necessary) after observing Google Hangout's webRTC internals as user only needs to send good quality video when it is requested by someone in the meeting, otherwise just send poor quality videos for thumbnail.
Awesome job with these freely available tools. Took a while to get my head around it. Coming from a games developer background I think it's funny how computers started out having access to the low level components so we could write anything. We had access to the cpu, gpu, input devices and output devices. Then WWW (HTML/HTTP) became popular, which was never designed with writing apps in mind. Now people want to write apps on this platform and all this low level stuff has taken about 20 years to be put back in. So today we finally have a truly cross platform computing tool with security, easy distribution and content availability with excellent searching services. Really I think (and granted hindsight is 20/20) the focus should have been on building sandboxed minimal low level apis that could be extended upon. This would open up more possibilities and creative options that we have not even dreamed of for applications. TCP/HTTP/HTML/Javascript/CSS/Canvas/WebRTC would all be built on top of this secure low level platform that was ubiquitous as optional standard libraries deliverable on demand from content delivery networks (CDNs). Prebuilt native code versions could also be substituted in for popular devices for extra performance. This would open up a whole new world of creative opportunities and accelerate consumer computing possibilities in general. It would also reduce the size of the browser to a very large degree as these things are becoming behemoths. Right now I'm still frustrated that I can't just open a simple UDP port like I can with a regular computer application. People argue about security implications, DOS attacks or whatever but these are easily solved. From that fundamental other networking protocol can be built. I see WebRTC as a great tool but I also find it over complicated and restrictive in terms of what I am able to do with a simple UDP port. When I was writing game servers the NAT traversal was easy to overcome by our application specific solution. For those who want a library to do it, feel free, but I don't think it needs to be forced. Much like the HTML Canvas was a great step for games and animation, but really what we really wanted was WebGL. Now we finally have WebGL, and everywhere. When I look at tools like ShaderToy I see what amazing things have been built and I think the same kind of creative potential is there with networking protocols if we provide the low level access as the first priority. In summary I believe it's better to give access to the low level functionality and then build libraries on top. Rather than provide high level libraries that hide low level functions which restricts creative potential and consumer computing possibilities.
