Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

91–100 of 128 posts

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

#91

Post by lucb1e »

throwaway8581 wrote: post #68
tediousdemise wrote: post #47

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 ar…

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.

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.

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

#92

Post by tinus_hn »

bodegajed wrote: post #5
diericx wrote: post #4

In complete sincerity, how is this better than ffmpeg https://trac.ffmpeg.org/wiki/StreamingGuide

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.

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

#93

Post by lucb1e »

galenlynch wrote: post #76
tediousdemise wrote: post #73

Earlier quoted context omitted.

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…

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.

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

#94

Post by steveklabnik »

allo37 wrote: post #89
hctaw wrote: post #59

Earlier quoted context omitted.

Ownership semantics in rust largely prevent circular references, so it's not the same deal

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 and RefCell : 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…

Yes, it is the same thing.

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

#95

Post by lucb1e »

yupyup54133 wrote: post #74
tediousdemise wrote: post #47

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 ar…

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.

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

#96

Post by sodality2 »

phoboslab wrote: post #31
skeletal88 wrote: post #14

Earlier quoted context omitted.

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.

MPEG1 over WebSockets: https://jsmpeg.com/

The perf test page doesn't go over WS at all, it's just get requests.

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

#97

Post by hctaw »

allo37 wrote: post #89
hctaw wrote: post #59

Earlier quoted context omitted.

Ownership semantics in rust largely prevent circular references, so it's not the same deal

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 and RefCell : 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…

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.

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

#98

Post by kingosticks »

rapsey wrote: post #21
chin123 wrote: 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?

The official one, pion (go) and webrtc-rs (rust) can all be used on both sides.

Is webrtc-rs usable? There are ticks missing for Media or DataChannel and PeerConnection. Aren't these required to do anything useful?

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

#99

Post by pratio »

Sean-Der wrote: post #88
crakenzak wrote: post #2

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?

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 existi…

Excellent website btw, thank you.

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

#100

Post by scottlamb »

gpderetta wrote: post #71
as-j wrote: post #58

Earlier quoted context omitted.

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...

[1] https://github.com/sepfy/pear/blob/b984c8dccaafdcdd1b181786a...

[2] https://dave.cheney.net/2018/05/29/how-the-go-runtime-implem...

Post reply on HN