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.
In practice, the dependency on libnice, which depends on glib, can be a problem for embedded devices.
That's actually why I developped libjuice  as the default ICE backend of libdatachannel .
Also, what benefits does WebRTC give over other protocols?
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.
* 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.
There is RTSP but that does not work in browsers.
"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). <...>"
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 and now ahead of time if you need a TURN server.
To understand NAT behaviors more check out 
Once this NAT thing has been done by both parts, and the actual communication has started directly P2P, STUN is not needed any more.
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.
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.
Those are called "middleboxes" (IIRC) and they're unfortunately somewhat pervasive.
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
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.
If you implement p2p video streaming chances are no company will want to touch it with a ten foot pole.
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 ?
> Separately, in December 2014, Microsoft and VirnetX settled patent disputes over Skype technology for $23 million.
* 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
To record meetings without sacrificing end to end encryption
I was expecting this to be on some microcontroller...
And in the same vein : settopboxes are considered embedded. TiVo's are.
All of the years; all of them forever.
Was this before of after the release of Windows XP Embedded?
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.
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.
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.
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".
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.
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?
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:
This sort of dogmatic cargo-culting paranoia-rant is exactly why people are getting sick of hearing about the "modern" BS.
Hey, as long as people keeps writing C and C with classes, you'll have a day job.
Please, tell "the best programmers" that it's "impossible to leak" memory. Apparently they do not know this.
> 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 ?
> 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"
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.
"C" is here to stay.
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.
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.
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.
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.
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. 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  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...
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.
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.