I'm not very familiar with WebRTC & how the browser pulls video usually, in what way is this better? Also, what benefits does WebRTC give over other protocols?
My understanding: Most IP cameras only have an RTSP stream, which would need to be proxied expensively by some server if you want to view it over the internet or be exposed directly to the internet. WebRTC would allow the server to help negotiate a connection directly from client to camera, thereby bypassing having to host expensive proxy.
A simple C implementation to stream H.264 to browser using WebRTC
111–120 of 128 posts
Re: A simple C implementation to stream H.264 to browser using WebRTC
#112Earlier quoted context omitted.
WebRTC with STUN is pure p2p where ffmpeg it requires a rtmp or rtsp server
Just for completeness sake this is what docs [1] state: "For most WebRTC applications to function a server is required for relaying the traffic between peers, since a direct socket is often not possible between the clients (unless they reside on the same local network). " [1] https://webrtc.org/getting-started/turn-server
Re: A simple C implementation to stream H.264 to browser using WebRTC
#113Earlier quoted context omitted.
> STUN is just for punching holes in your NAT router, and also discovering what is your public IP address. I know, but what I mean is that "true P2P" on our current internet architecture is not possible, you always need the help of a third party
If we are still in the 90's that definition of "true p2p" would be: two computers with both having public IPs and transferring packets via TCP. But nowadays we are always behind NATs so we became less strict with the definition of what is true p2p
Re: A simple C implementation to stream H.264 to browser using WebRTC
#114Earlier quoted context omitted.
Careful! P2P streaming video is a (completely non obvious, according to the courts) infringement of the VirNetX patent that for example Apple just had to pay a few billions of dollars for. If you implement p2p video streaming chances are no company will want to touch it with a ten foot pole.
Um, shouldn't the patent have expired by now ?
Re: A simple C implementation to stream H.264 to browser using WebRTC
#115Earlier quoted context omitted.
Um, shouldn't the patent have expired by now ?
Probably not or it would have been on the news and you would start seeing p2p communications again. It’s not rocket science, after all.
And for some recent examples : what about Popcorn Time ? Or PeerTube ?
EDIT : Oh, I guess that most of those are technically not "streaming", but "watching while downloading" like YouTube or FTP+VLC ?
Re: A simple C implementation to stream H.264 to browser using WebRTC
#116The code contains things that make any modern C++ or Rust developer cringe: naked pointers, unsafe type casts, raw loops, using malloc/free to manually allocate memory for buffers, and calls to unsafe free functions like strcat. So much slow boilerplate is required to do things like handling memory allocation. The increased source code size for even the simplest things becomes harder to maintain. Danger is waiting ar…
Thanks is, as the GitHub title says, for iot and embedded devices. There’s a whole class of these that don’t have the resources to run C++ or rust. Source: develop on a Linux system with 7 megabyte roofs and 16 megs of ram. Oh! We have a 1 meg application partition.
Re: A simple C implementation to stream H.264 to browser using WebRTC
#117Earlier quoted context omitted.
Thanks is, as the GitHub title says, for iot and embedded devices. There’s a whole class of these that don’t have the resources to run C++ or rust. Source: develop on a Linux system with 7 megabyte roofs and 16 megs of ram. Oh! We have a 1 meg application partition.
Really? You have megabytes of memory but can't run C++? Which architecture is this?
Re: A simple C implementation to stream H.264 to browser using WebRTC
#118Earlier quoted context omitted.
Dude. The alternative is that the author would not have written the project. Not everyone has hundreds of hours of free time to throw away at learning the next hot programming language.
There's definitely an argument to be made for sticking with stuff you know and love rather than investing in the latest fad. There also comes a point, though, where the solution you know of has clear disadvantages and there are various alternatives with good support and third party libraries available to use. Also consider that it also impacts other people if you put unsafe code out there or if others want to contrib…
Re: A simple C implementation to stream H.264 to browser using WebRTC
#119The code contains things that make any modern C++ or Rust developer cringe: naked pointers, unsafe type casts, raw loops, using malloc/free to manually allocate memory for buffers, and calls to unsafe free functions like strcat. So much slow boilerplate is required to do things like handling memory allocation. The increased source code size for even the simplest things becomes harder to maintain. Danger is waiting ar…
C is very fun to write. You get down to the machine level (nearly). Op did so because he probably wanted to just use it. Maybe to study it, maybe to learn how to write in an unsafe language. You can program Rust if you want and all you want and feel safe by doing so. Feel free. But this reply really does not contribute anything of value. Especially not for Op. Ofc there are languages with better abstractions reg memo…
Re: A simple C implementation to stream H.264 to browser using WebRTC
#120Earlier quoted context omitted.
Probably not or it would have been on the news and you would start seeing p2p communications again. It’s not rocket science, after all.
But p2p streaming has been around since the mid 2000's ?? (Pre-Microsoft Skype, Miro, Joost, Tribler...) And for some recent examples : what about Popcorn Time ? Or PeerTube ? EDIT : Oh, I guess that most of those are technically not "streaming", but "watching while downloading" like YouTube or FTP+VLC ?