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

71–80 of 128 posts

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

#71

Post by gpderetta »

as-j wrote: post #58
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…

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.

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

#72

Post by uuidgen »

rashkov wrote: post #65
callesgg wrote: post #45

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

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.

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

#73

Post by tediousdemise »

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.

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.

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

#74

Post by yupyup54133 »

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.

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

#75

Post by PragmaticPulp »

londons_explore wrote: post #26

How the world has changed that running something on a raspberry pi counts as "embedded". I was expecting this to be on some microcontroller...

Nothing has changed. Small Linux systems have been a staple of the embedded systems world for a long time.

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

#76

Post by galenlynch »

tediousdemise wrote: post #73
throwaway8581 wrote: post #68

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

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

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

#77

Post by higerordermap »

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…

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

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

#78

Post by xfer »

as-j wrote: post #58
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…

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.

Really? You have megabytes of memory but can't run C++? Which architecture is this?

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

#79

Post by tediousdemise »

astorgard wrote: post #69
tediousdemise wrote: post #55

Earlier quoted context omitted.

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

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

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

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

#80

Post by tediousdemise »

higerordermap wrote: post #77
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…

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

Very true. This is why I appreciate C++’s lack of a universal package manager.
Post reply on HN