Live data from Hacker News

A simple C implementation to stream H.264 to browser using WebRTC

github.com

111–120 of 128 posts

Re: A simple C implementation to stream H.264 to browser using WebRTC

#111
post #83

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.

Not any more with IPv6 ?

Re: A simple C implementation to stream H.264 to browser using WebRTC

#112

Earlier 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

Modern networks use IPv6 only, so don't have NAT.

Re: A simple C implementation to stream H.264 to browser using WebRTC

#113

Earlier 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

IPv6 is slowly taking over, hopefully in the near future being behind a NAT will be considered abnormal (just like happened with Unicode, we're around 35% = "Unicode 2009", popularity-wise).

Re: A simple C implementation to stream H.264 to browser using WebRTC

#114

Earlier 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 ?

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.

Re: A simple C implementation to stream H.264 to browser using WebRTC

#115

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

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 ?

Re: A simple C implementation to stream H.264 to browser using WebRTC

#116
post #58

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

Space is so cheap these days, it doesn't matter much unless you're on a really low budget. That said I still get a kick out of programming specialty cases with 8 and 16 bit micros. It's nice to have just about everything you need on a chip (a2d, d2a, CAN, I2C, SPI, timers, tons of general I/O). All you kids should do at least one project like that, you'd be surprised at how fun it can be to pick and choose exactly what the hardware is doing down to the clock cycle :)

Re: A simple C implementation to stream H.264 to browser using WebRTC

#117
post #78
post #58

Earlier 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?

lol none, someone who says that doesn't really know what they're talking about. You can use zero overhead subset of c++ just fine and it will take barely any more room than C. Now if you pull in the std library it's over :)

Re: A simple C implementation to stream H.264 to browser using WebRTC

#118
post #95

Earlier 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…

Or do what you want. However I think c++ with just RAII and smart pointers brings so much more safety than C I don't know why it doesn't get more attention. You don't have to use all the rest, just those couple of things can bring a lot of safety to a project

Re: A simple C implementation to stream H.264 to browser using WebRTC

#119

The 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…

Yeah I've been using rust for more and more small projects at work (we are a c++ house but rust is "ok") and love it. However, it's annoying to hear rustaceans constantly pushing their wares

Re: A simple C implementation to stream H.264 to browser using WebRTC

#120

Earlier 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 ?

The court does not agree with you. A peer to peer communication service, like FaceTime was originally, violates the patents.
Post reply on HN