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

41–50 of 128 posts

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

#41

Post by kdkeyser »

tssva wrote: post #40
kdkeyser wrote: post #35

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

The stock Wyze and Xiaomi firmware for their T20 based cameras both use WebRTC to stream the video to their apps.

Any background info/links to this? The Wyze forum comes up empty, only some discussions on WebRTC being complex to add.

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

#43

Post by sublimefire »

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

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

[1] https://webrtc.org/getting-started/turn-server

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

#44

Post by tempodox »

the-dude wrote: post #34
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...

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.

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?

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

#45

Post by callesgg »

noseratio wrote: post #38
j1elo wrote: post #12

Earlier quoted context omitted.

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.

You'd also need a TURN server if both peers are behind NAT without UPnP, which is very common. STUN alone wouldn't be enough.

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.

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

#46

Post by regularfry »

tempodox wrote: post #44
the-dude wrote: post #34

Earlier quoted context omitted.

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.

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?

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

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

#47

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

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

#48

Post by tempodox »

regularfry wrote: post #46
tempodox wrote: post #44

Earlier quoted context omitted.

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?

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

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

#49

Post by craftinator »

tempodox wrote: post #48
regularfry wrote: post #46

Earlier quoted context omitted.

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

No way! The only way to be on the baremetal side of the line is manual activation of transistors using a telegraph key powered by a lemon...

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

#50

Post by slezyr »

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…

> 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

Post reply on HN