Get the top HN stories in your inbox every day.
kdkeyser
tssva
The stock Wyze and Xiaomi firmware for their T20 based cameras both use WebRTC to stream the video to their apps.
kdkeyser
Any background info/links to this? The Wyze forum comes up empty, only some discussions on WebRTC being complex to add.
tssva
When the Pan cam was initially released I bought a couple of them and hacked on them for a while. examining the original firmware quickly revealed they were using WebRTC for the video. At least at the time almost all the cameras based on the Ingenic T series chips used the same backend service. It has been a couple of years so my memory fails on the name. The marketing material for the service mentioned the use of WebRTC.
chapelierfou
Nice, this looks like a simple and clear proof of concept!
In practice, the dependency on libnice, which depends on glib, can be a problem for embedded devices.
That's actually why I developped libjuice [0] as the default ICE backend of libdatachannel [1].
crakenzak
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?
Sean-Der
If you have the time give WebRTC for the Curious[0] a read. I try and explain what WebRTC is and how it actually works. The big advantages that I see are.
* Can do P2P (and Client/Server)
* Mandatory Encryption
* Handles codec/track negotation. You don't need to know ahead of time what is being sent.
* Data channels. Can also be configured to be lossy/unordered for kind of performance needed for gaming.
* Uses existing protocols. Really easy to bridge with SIP/RTSP. This software/hardware goes all the way back to the late 90s
* Multiple implementations and available in the browser. No other protocol comes close in availability.
[0] https://webrtcforthecurious.com/docs/01-what-why-and-how/
pratio
Excellent website btw, thank you.
rapsey
WebRTC is generally for video conferencing as that requires real time communication.
Live streams or videos on the web are most commonly hls or dash protocols. Just mp4 file play while download also works.
Hls/dash are not built for lower latencies. They are built for easy CDN distribution and flexible switching between different resolutions and bitrates. Live streams generally are at least a few seconds behind.
ianlevesque
People mostly do this for lower latency.
skeletal88
What other protocols do you know that offer low latency almost real time video and all that in the browser?
There is RTSP but that does not work in browsers.
phoboslab
MPEG1 over WebSockets: https://jsmpeg.com/
sodality2
The perf test page doesn't go over WS at all, it's just get requests.
zip1234
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.
BlueTemplar
Not any more with IPv6 ?
mypalmike
How is it better than what?
diericx
In complete sincerity, how is this better than ffmpeg
Randor
It's certainly not better than FFmpeg. But I had a look through the source code and the author seems to have a fairly good grasp of WebRTC. The library looks really useful for anyone that wants to quickly understand WebRTC and how to use librtp and libsrtp. It's mostly a bare-bone wrapper around those libs.
riedel
Maybe it would be a good starting point for someone integrating it into ffmpeg
Randor
Yep, it looks easy to replace the function h264_get_next_frame(). I think you could get really decent performance if you used ffmpeg to pre-extract all of the frames into sequential files and serve them statically.
bodegajed
WebRTC with STUN is pure p2p where ffmpeg it requires a rtmp or rtsp server
sublimefire
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). <...>"
Sean-Der
It’s a little more nuanced than this.
https://medium.com/the-making-of-whereby/what-kind-of-turn-s... fippo pulled the stats and saw 17%
This also depends on your clients network. You can determine your NAT mapping type[0] and now ahead of time if you need a TURN server.
To understand NAT behaviors more check out [1]
[0] https://github.com/pion/stun/tree/master/cmd/stun-nat-behavi...
[1] https://webrtcforthecurious.com/docs/03-connecting/#nat-mapp...
BlueTemplar
Modern networks use IPv6 only, so don't have NAT.
jcelerier
... how is STUN pure p2p ? you still need to have a STUN server somewhere no ?
j1elo
STUN is just for punching holes in your NAT router, and also discovering what is your public IP address. Both things will be needed for the other peer to know where to reach you. And the other way around.
Once this NAT thing has been done by both parts, and the actual communication has started directly P2P, STUN is not needed any more.
fulafel
Your p2p nodes might not be behind NAT. In a lot of populations you can rely on everyone having working v6 for example.
I think the question of what's "pure" p2p is somewhat academic. If your app uses DNS, is it p2p, isn't DNS just a distributed p2p database? Does p2p require that every aspect of your app right down to discovery is distributed among nodes running your app? Is it cheating to use an existing DHT? etc.
bodegajed
You can just use google stun servers they are free to use
tinus_hn
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.
BlueTemplar
Um, shouldn't the patent have expired by now ?
defied
If you're using ffmpeg with rtp, you can use Pion to make it a WebRTC stream: https://github.com/pion/webrtc/tree/master/examples/rtp-to-w...
chin123
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?
Sean-Der
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++)
* https://github.com/rawrtc/rawrtc (C++)
* https://github.com/sipsorcery-org/sipsorcery (C#)
* https://github.com/paullouisageneau/libdatachannel (C++)
Also check out https://github.com/sipsorcery/webrtc-echoes for how they work together
chapelierfou
Just a nitpick: RAWRTC is actually written in C (also I think it focuses on data channels only).
EGreg
What about Node.js clients??
To record meetings without sacrificing end to end encryption
kingosticks
Gstreamer. Example at https://github.com/centricular/gstwebrtc-demos/tree/master/s...
ajb
At a low level, webrtc interoperates with VoIP. But because webrtc doesn't mandate a signalling protocol and VoIP uses SIP, generally you need a browser to run whatever proprietary signalling the site decided to implement in JS.
phipleg
The Python library aiortc, https://github.com/aiortc/aiortc, enables client and server side communication via WebRTC.
rapsey
The official one, pion (go) and webrtc-rs (rust) can all be used on both sides.
kingosticks
Is webrtc-rs usable? There are ticks missing for Media or DataChannel and PeerConnection. Aren't these required to do anything useful?
chapelierfou
I think webrtc-rs is still in early development. libdatachannel has Rust bindings though: https://github.com/lerouxrgd/datachannel-rs
chapelierfou
libdatachannel (C/C++) can also be used on both sides: https://github.com/paullouisageneau/libdatachannel
tapirl
pion link: https://github.com/pion/webrtc
the_only_law
I believe that clients are available for most native MobileMe platforms as well.
albertoCaroM
If you are interested in desktop implementations, you can access the telegram desktop source code, which also uses WebRTC: https://github.com/telegramdesktop/tdesktop/blob/a506e9b9eb7...
genericacct
Can you provide an example that streams from a v4l device?
londons_explore
How the world has changed that running something on a raspberry pi counts as "embedded".
I was expecting this to be on some microcontroller...
the-dude
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.
tempodox
For how many years do you want to keep blurring the line between running on top of a cushy OS and running on bare metal with no OS at all?
regularfry
"Embedded" is a property of how the box is deployed, not what's inside it. The lines are blurring because the word "embedded" has been overloaded with an interpretation it doesn't merit for too long. If you mean "bare metal", say "bare metal". Mind you, if you're going to argue "no OS at all" is part of the criteria, FreeRTOS and the like are banned, right?
a1369209993
> 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.
mywittyname
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.
Redoubts
> How the world has changed...
Was this before of after the release of Windows XP Embedded?
stjohnswarts
It's time to move on I think. There are still plenty around but the world is going toward bigger and more.
PragmaticPulp
Nothing has changed. Small Linux systems have been a staple of the embedded systems world for a long time.
tediousdemise
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 around every corner for you to commit a buffer overflow or type confusion error after a long day of work. Infinite chances are offered for you to leak memory. The alternative is that you could be using a language that uses highly optimized RAII types on the stack which are impossible to leak, and written by some of the best programmers in the world so you don’t have to juggle chainsaws.
C invites disaster through seemingly normal use of the language. Just embrace modernity; your code will be smaller, more expressive, more performant, and you’ll be grateful.
throwaway8581
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.
lucb1e
Let's not call genuine opinions 'cancer' please. If this were some viagra spam bot, then maybe though it would still not be constructive, but let's keep in mind there's a human on the other end of the line.
tediousdemise
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 hard. But like I said before, it will pay dividends, and save time for the people in the future who come hunting down your bugs.
galenlynch
It seems you think their mistake was using C in the first place, and not the way they used C.
Calling people out for not using a language that you prefer is not helping them learn, nor is it bitter medicine to those who find learning your preferred language "hard".
bartvk
> 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:
therealcamino
"Eschew" means "to avoid habitually especially on moral or practical grounds".
userbinator
Perhaps you'd like to point out an actual bug you've found...?
This sort of dogmatic cargo-culting paranoia-rant is exactly why people are getting sick of hearing about the "modern" BS.
villasv
The modern C++ techniques being referred are 10 years old at this point already and have stayed in consensus. No need to get salty.
tediousdemise
I already have to debug C/legacy C++ code (“C with classes”) on a daily basis for my day job, so I sure certainly am not going to waste my free time doing it. The best I can do is be an evangelist for better practices, a fly on the ass of people who still pump C into the garbage stream of the internet.
scoutt
Since the text in your parent post is more or less the same of your last comment from 10 hours ago, I agree you are in a sort of "keyword oriented" evangelization crusade against good'ol C. The question would be, why caring so much?
Hey, as long as people keeps writing C and C with classes, you'll have a day job.
slezyr
> The alternative is that you could be using a language that uses highly optimized RAII types on the stack which are impossible to leak, and written by some of the best programmers in the world so you don’t have to juggle chainsaws.
Please, tell "the best programmers" that it's "impossible to leak" memory. Apparently they do not know this.
https://doc.rust-lang.org/book/ch15-06-reference-cycles.html
tediousdemise
Thanks for sharing, I’m unfamiliar with the nuances of Rust’s implementation of RAII as I’m primarily a modern C++ developer. Modern C++ mostly guarantees against leaks since it encourages the stack as much possible.
https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC...
allo37
It's the same deal as creating a circular references using `std::shared_ptr` in C++.
orf
Leak can mean different things. None of those types in the link are stack allocated, I think.
higerordermap
> Be me
> Rewrite h.264 in rust
> Depends on swap_bits crate by Wladimir Jinping Jr.
> NIH hacked by unknown people
> NYT title next day "Cargo cult package manager behind NIH hack"
tediousdemise
Very true. This is why I appreciate C++’s lack of a universal package manager.
TaupeRanger
C with Asan or Valgrind is faster to write and just as performant (usually better) as Rust or C++. There's a reason the world runs on C, and only part of it is historical.
adrianN
Now you just need to also write a testsuite that covers every possible path through your code and you've proved the absence of errors that Valgrind can find. I'm not sure that building such a test suite is less work than using a safer language.
tediousdemise
I just can’t recommend using it for new code in light of the sexy new alternatives that can compile down to the same binary with source code that’s way more intuitive and readable.
I do have nostalgia for C since it was my first language, and I think a lot of people are in the same boat, which is a problem. That’s why I think we need to stop teaching C. Kate Gregory has a good cppcon talk on the topic: https://youtu.be/YnWhqhNdYyk
astorgard
I... don't even know how to start answering this.
"C" is glorified assembly and learning assembly is *fundamental* to understand how computers work. "C" *should* be the first language programmers learn when they get serious (ex: first year computer science classes).
When I write "C" I know exactly what is going on with each of my CPU cycles and where my variables are being allocated. The compiler is a dead simple translator who doesn't play funny tricks behind my back.
"C" is the perfect language to learn and have fun with the underlying architecture.
"C" is very easy to learn and not that hard to master. It is fast to compile, fast to run and available everywhere.
I don't like "C++". All code bases maintained by more than one single developer (no matter the language it is written in) become rotten with time but, from my experience, the larger the amount of features a language has, the worst this becomes. All big "C++" projects I have worked on (except for one) were horrendous. This also happens in "C", but in "C" I can just "grep" the keyword and immediately know where it comes from.
I don't like "Rust". I've tried to learn it twice and failed. There are too many places where I lose track what the compiler is doing, the (formal?) specification is big and complex and keeps growing (approaching "C++" absurdity levels). There is never an "obvious" way to do one thing. I get "Rust" is a test bench for language designers, but they are creating an over-engineered monster that is not easy to use (think "low gravity ink injection pen" vs "pencil")
So... "C" is perfect for me (and many others). It's simple, fast and as powerful as it gets, which means it is also fun. As others have mentioned on this thread, together with "cppcheck", "valgrind", "electric-fence" and friends it is also as secure as any other.
"C" is here to stay.
mpfundstein
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 memory and concurrency. But who cares? its Op's freedom to use whatever he wants to use.
and btw. this attitude is precisely why so many people think Rusters are fucking annoying.
stjohnswarts
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
as-j
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.
gpderetta
If it can run C, it can run C++ (or rust I guess). The majority of abstractions have little to no overhead. Also 16 megabytes were enough for a very decent desktop computer in the '90, enough to run very complex C++ applications with ease.
scottlamb
I think there's some truth in what as-j is saying. Rust binaries (and C++ ones) tend to be larger than C ones. I think the major reasons are (a) Rust dependencies being statically linked due to a lack of ABI stability, (b) inclusion of portions of the (statically linked, see a) Rust standard library used by the program where C code uses libc, (c) code bloat due to monomorphization, (d) the ease of just using a full-featured library where someone writing in C might cheat a little bit. As an example of what I mean by the last point, see sdp_attribute_get_answer in this codebase. [1] It's writing JSON, but it doesn't use a JSON library that actually escapes the included string. It just assumes the included string doesn't have a quote character in it. Is that assumption valid? Will it always be valid? I'm not sure on quick inspection.
There are ways around all of these:
* a. Static vs dynamic linkage: in an embedded system, it'd be reasonable to just produce a single userspace binary that does everything. It can change its behavior based on argv[0]. I think this is not too unusual for constrained systems even with C binaries. Eg busybox does it. If you only have one binary, you don't need dynamic linking. Also, I think it's not strictly true that Rust doesn't support dynamic linking. I think you can dynamically link everything if you ensure the whole system is built with the same compiler version.
* b. Standard library. You don't have to use it at all, or you can use it sparingly, paying only for what you use.
* c. Monomorphization. You could write (for example) a Go-like map [2] rather than relying so heavily on monomorphization. I'd love to see someone take this idea as far as possible; it might be a good idea for a lot of non-inner-loop code in general, not just on tight embedded systems.
* d. Using full-featured libraries. Obviously no one is making you do this; the same cheats available in C are available in Rust.
but in fairness, the further you go down this path, the further you are from just being able to just take advantage of the whole Rust ecosystem.
Personally, I'd still rather develop or use a #![no_std] Rust codebase than a C one. Memory safety is important to me. IOT devices are no exception to that. Their security history is horrible, and I'd like their security future to be better...
[1] https://github.com/sepfy/pear/blob/b984c8dccaafdcdd1b181786a...
[2] https://dave.cheney.net/2018/05/29/how-the-go-runtime-implem...
stjohnswarts
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 :)
xfer
Really? You have megabytes of memory but can't run C++? Which architecture is this?
stjohnswarts
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 :)
yupyup54133
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.
lucb1e
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 contribute or build upon it (even if your C is better than even the chromium team, that doesn't mean your contributors' or developer-users are).
In my opinion C has reached a point where using a project like this as a learning opportunity to try out another language, if you don't know one already, would be worth considering.
stjohnswarts
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
Get the top HN stories in your inbox every day.
This would be interesting to integrate into https://github.com/openmiko/openmiko which is a firmware for the T20 based ip-cameras.
Right now, I am not aware of any cheap ip camera that can stream its H264 video to a regular web browser, with sub 500 ms latency. All manufacturers seem to have moved to an app, I guess they can show an RTSP stream in that way.
Older ip cameras had MJPEG which you could view in the browser, but that is really inefficient w.r.t. bandwidth.