Live data from Hacker News

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

github.com

101–110 of 128 posts

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

#101

How the world has changed that running something on a raspberry pi counts as "embedded". I was expecting this to be on some microcontroller...

Admittedly, I'm no expert on this subject, but this code looks like it could run on an embedded device. I don't see any system calls, and it looks to rely mostly on the standard library. glib.h is used in dtls_transport, but I suspect you can replace the certificate mechanism with something else.

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

#102
post #17

I've seen a few WebRTC server implementations pop up recently but the only clients I have seen are web browsers. Does anyone know of any WebRTC client implementations apart from the browser? Or am I misunderstanding the WebRTC architecture completely?

There are lots of implementations now! Here are the ones I know about. * https://github.com/aiortc/aiortc (Python) * GStreamer’s webrtcbin (C) * https://github.com/shinyoshiaki/werift-webrtc (Typescript) * https://github.com/pion/webrtc (Golang) * https://github.com/webrtc-rs/webrtc (Rust) * https://github.com/awslabs/amazon-kinesis-video-streams-webr... (C/Embedded) * https://webrtc.googlesource.com/src/ (C++) * htt…

What about Node.js clients??

To record meetings without sacrificing end to end encryption

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

#103
post #72
post #65

Earlier quoted context omitted.

Note that parent said “ if both peers are behind NAT without UPnP”. As far as I know, there’s no way to punch holes / open ports automatically without UPnP.

Punching holes doesn't work only when network devices in between are broken or are actively preventing it. From the network point of view it looks the same as two hosts starting an outgoing TCP connection through nat - if that works then hole punching should work too.

Not TCP. UDP - there are no connection in UDP, so the routers / firewalls don't really differentiate between a new connection and packets that happen to have the correct ip+port.

Some are trickier than others, as there are 2 IPs and 2 ports in a packet (at any point), and it can be hard to match all of them for the stricter devices, esp. on NATs that do source port randomization.

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

#104
post #72
post #65

Earlier quoted context omitted.

Note that parent said “ if both peers are behind NAT without UPnP”. As far as I know, there’s no way to punch holes / open ports automatically without UPnP.

Punching holes doesn't work only when network devices in between are broken or are actively preventing it. From the network point of view it looks the same as two hosts starting an outgoing TCP connection through nat - if that works then hole punching should work too.

> when network devices in between are broken or are [maliciously] actively preventing it.

Those are called "middleboxes" (IIRC) and they're unfortunately somewhat pervasive.

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

#105

How the world has changed that running something on a raspberry pi counts as "embedded". I was expecting this to be on some microcontroller...

For how many years do you want to keep defining embedded as single core, no MMU with a relatively low clock? And in the same vein : settopboxes are considered embedded. TiVo's are.

> For how many years do you want to keep defining embedded as single core, no MMU with a relatively low clock?

All of the years; all of them forever.

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

#106
post #65

Earlier quoted context omitted.

That is partially incorrect, STUN can punch a hole through even when both sides uses NAT in many cases. That is what I would classify as STUN’s main feature.

Note that parent said “ if both peers are behind NAT without UPnP”. As far as I know, there’s no way to punch holes / open ports automatically without UPnP.

Go read about stun.

You send outgoing packets simultaneously from both sides. Causing both sides to add nat translation entry’s to their nat tables. When the packets arrive both sides already have nat translation entries and the packets go right through the nat.

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

#107

Earlier quoted context omitted.

You literally go from thread to thread posting the same pro-Rust anti-C drivel, derailing every thread. Sorry to be crude, but can you people take this self-righteous bs elsewhere? Not every thread needs to be about the superiority of Rust or your gripes with C. This cancer is ruining every thread on HN now.

As far as I can tell, this is an open forum. If people keep repeating the same mistakes when they use C, I’ll keep promoting the alternatives. I’m not trying to eschew flamebait, it just so happens that people get upset when their ideas are challenged. If it makes people uncomfortable, then that’s fantastic, because no one who was comfortable ever learned anything. I get it: learning new things and new languages is h…

"Eschew" means "to avoid habitually especially on moral or practical grounds".

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

#108

Earlier quoted context omitted.

You literally go from thread to thread posting the same pro-Rust anti-C drivel, derailing every thread. Sorry to be crude, but can you people take this self-righteous bs elsewhere? Not every thread needs to be about the superiority of Rust or your gripes with C. This cancer is ruining every thread on HN now.

As far as I can tell, this is an open forum. If people keep repeating the same mistakes when they use C, I’ll keep promoting the alternatives. I’m not trying to eschew flamebait, it just so happens that people get upset when their ideas are challenged. If it makes people uncomfortable, then that’s fantastic, because no one who was comfortable ever learned anything. I get it: learning new things and new languages is h…

> As far as I can tell, this is an open forum

Your original point may very well still stand, but I'd like to point out that there's actually a whole bunch of guidelines for posting here:

https://news.ycombinator.com/newsguidelines.html

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

#109

How the world has changed that running something on a raspberry pi counts as "embedded". I was expecting this to be on some microcontroller...

It's time to move on I think. There are still plenty around but the world is going toward bigger and more.

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

#110

Earlier quoted context omitted.

WebRTC with STUN is pure p2p where ffmpeg it requires a rtmp or rtsp server

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 ?
Post reply on HN