How the world has changed that running something on a raspberry pi counts as "embedded". I was expecting this to be on some microcontroller...
A simple C implementation to stream H.264 to browser using WebRTC
101–110 of 128 posts
Re: A simple C implementation to stream H.264 to browser using WebRTC
#102I'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…
To record meetings without sacrificing end to end encryption
Re: A simple C implementation to stream H.264 to browser using WebRTC
#103Earlier 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.
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
#104Earlier 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.
Those are called "middleboxes" (IIRC) and they're unfortunately somewhat pervasive.
Re: A simple C implementation to stream H.264 to browser using WebRTC
#105How 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.
All of the years; all of them forever.
Re: A simple C implementation to stream H.264 to browser using WebRTC
#106Earlier 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.
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
#107Earlier 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…
Re: A simple C implementation to stream H.264 to browser using WebRTC
#108Earlier 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…
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:
Re: A simple C implementation to stream H.264 to browser using WebRTC
#109How the world has changed that running something on a raspberry pi counts as "embedded". I was expecting this to be on some microcontroller...
Re: A simple C implementation to stream H.264 to browser using WebRTC
#110Earlier 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.