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.
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.
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.
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.
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.
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.
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.
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). <...>"
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.
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.
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.
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).
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.
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.
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?
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.
Anything can function as the signaling layer since all you need is to exchange pieces of text. I think the point was that most sites choose to implement it using JS and browser API's like ajax, websocket or SSE.
Because webrtc came from the chromium source code so you got it installed already on your browser. Then Google took it out there and made it stand alone library so you can use it on apps. I see webrtc projects occasionally here on Show HN threads
"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?
Personally, I'd say that FreeRTOS is just on the line, but others may draw that line differently. However, I do take your point about changing interpretations.
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.
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.
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.
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.
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.
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".
> It seems you think their mistake was using C in the first place, and not the way they used C.
I mean, guns are restricted in all countries, while of course it's the way guns are used that is truly what people take issue with. If you hang it up on your own wall and never take it off, nobody has an issue with your gun, but enforcement of that is nigh impossible and so we restrict the ownership to policemen and allow only things like hunting rifles for the small group that still likes to go hunting.
As someone working in security, I'd make a similar though obviously less extreme case for unsafe languages like C. If you don't need it, then why use something that you can shoot yourself in the foot with? You put other people at risk through using it incorrectly and it's nigh impossible to enforce secure coding. Many people seem to think that you need C++, C, or assembly to write fast code whereas nowadays there are plenty of alternatives without some of C's biggest issues.
To me, this is not a simple matter of preference like your choice of editor or the way you prefer to have it configured, to be used by you and you alone.
Software, especially open source software, is often collaborative. The programming language is a way of expressing yourself not only to your compiler, but also to other human beings.
Would you write a book today in Middle English, when the rest of the world is expecting modern English?
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.
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.
Yeah, it’s shocking that almost every day I log onto HN and see either (1) security exploits in legacy C code or, (2) new C code being introduced into the world that invites the same exploits to the untrained programmer. The same way people keep repeating the same mistakes, I will keep repeating my criticisms. We’re stuck in an infinite loop.
> 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.
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.
Sorry, I'm not a Rust pro, but from the docs about reference cycles linked above:
> We can see that Rust allows memory leaks by using Rc<T> and RefCell<T>: it’s possible to create references where items refer to each other in a cycle. This creates memory leaks because the reference count of each item in the cycle will never reach 0, and the values will never be dropped.
This sounds a lot like what happens when you create a circular reference with std::shared_ptr ?
Yes, but grep for `Rc::new()` in actual rust code bases compared to `shared_ptr` in C++. Interior mutability is cumbersome and not a natural pattern in practice.
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.
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.
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
"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.
> The compiler is a dead simple translator who doesn't play funny tricks behind my back.
When did you last look at the assembly your compiler produces at O2 or higher? Because decades of C compiler development would very much like to disagree with that statement.
> As others have mentioned on this thread, together with "cppcheck", "valgrind", "electric-fence" and friends it is also as secure as any other.
Where do all the memory safety problems in any nontrivial C or C++ codebase come from then? Do you think that for example the Chrome team is just incompetent? It is certainly possible to write safe C, but that involves _a lot_ more effort than using valgrind. You could for example write MISRA-C. Together with extensive manual checking those rules lead to fairly save C, but the effort needed is really big.
> "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).
I agree that a CS education may include an understanding of low level details, but if you want to learn assembly and understand assembly, use assembly.
> 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.
It really depends on what you tell the compiler. And if you’re using GNU, g++ compiles both C and C++. The compiler will aggressively optimize your code down to practically nothing, and you’ll find that the resulting machine code has high probability of being identical whether you wrote it in C or C++, so it’s a matter of choosing the language that is shorter and easier to read/understand.
I really do respect where you are coming from, but in my opinion one should use the tool that’s most appropriate for the job in light of what’s available. Just because we can keep using lead paint in buildings, or wire wrapping/vacuum tube amplifiers in electronics, doesn’t mean we should. Maybe for fun, maybe as a hobby, but not professionally, and that’s the mindset I approached this with.
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.
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
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.
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.
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...
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 :)
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 :)
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 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.
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
Bit of a difference between a kernel and video conferencing.
One of these absolutely needs raw memory management and all the unsafe-if-not-very-carefully-done features that C(++) offer, the other definitely does not.
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.