[HN Gopher] A simple C implementation to stream H.264 to browser...
___________________________________________________________________
A simple C implementation to stream H.264 to browser using WebRTC
Author : sepfy
Score : 278 points
Date : 2021-04-08 05:38 UTC (17 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| londons_explore wrote:
| How the world has changed that running something on a raspberry
| pi counts as "embedded".
|
| I was expecting this to be on some microcontroller...
| the-dude wrote:
| 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.
| a1369209993 wrote:
| > For how many years do you want to keep defining embedded as
| single core, no MMU with a relatively low clock?
|
| All of the years; all of them forever.
| tempodox wrote:
| 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?
| regularfry wrote:
| "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?
| tempodox wrote:
| 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.
| craftinator wrote:
| 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...
| Redoubts wrote:
| > How the world has changed...
|
| Was this before of after the release of Windows XP Embedded?
| mywittyname wrote:
| 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.
| PragmaticPulp wrote:
| Nothing has changed. Small Linux systems have been a staple of
| the embedded systems world for a long time.
| kdkeyser wrote:
| 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 browser,
| but that is really inefficient w.r.t. bandwidth.
| tssva wrote:
| The stock Wyze and Xiaomi firmware for their T20 based cameras
| both use WebRTC to stream the video to their apps.
| kdkeyser wrote:
| Any background info/links to this? The Wyze forum comes up
| empty, only some discussions on WebRTC being complex to add.
| chin123 wrote:
| 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?
| Sean-Der wrote:
| There are lots of implementations now! Here are the ones I know
| about.
|
| * 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
| EGreg wrote:
| What about Node.js clients??
|
| To record meetings without sacrificing end to end encryption
| pjmlp wrote:
| Windows, https://github.com/microsoft/winrtc
| ajb wrote:
| 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.
| superdisk wrote:
| Matrix can also function as a signaling layer for WebRTC.
| SahAssar wrote:
| 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.
| rapsey wrote:
| The official one, pion (go) and webrtc-rs (rust) can all be
| used on both sides.
| kingosticks wrote:
| Is webrtc-rs usable? There are ticks missing for Media or
| DataChannel and PeerConnection. Aren't these required to do
| anything useful?
| tapirl wrote:
| pion link: https://github.com/pion/webrtc
| bodegajed wrote:
| 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
| the_only_law wrote:
| I believe that clients are available for most native MobileMe
| platforms as well.
|
| https://webrtc.github.io/webrtc-org/native-code/android/
|
| https://webrtc.github.io/webrtc-org/native-code/ios/
| kingosticks wrote:
| Gstreamer. Example at https://github.com/centricular/gstwebrtc-
| demos/tree/master/s...
| phipleg wrote:
| The Python library aiortc, https://github.com/aiortc/aiortc,
| enables client and server side communication via WebRTC.
| SahAssar wrote:
| A lot of video call applications use WebRTC, I'm pretty sure
| slack uses it (although not in P2P mode, they use a SFU).
| albertoCaroM wrote:
| If you are interested in desktop implementations, you can
| access the telegram desktop source code, which also uses
| WebRTC:
| https://github.com/telegramdesktop/tdesktop/blob/a506e9b9eb7...
| tediousdemise wrote:
| 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.
| [deleted]
| TaupeRanger wrote:
| 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.
| adrianN wrote:
| 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.
| tediousdemise wrote:
| 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
| astorgard wrote:
| 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 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.
| adrianN wrote:
| > 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.
| tediousdemise wrote:
| > "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.
| throwaway8581 wrote:
| 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.
| tediousdemise wrote:
| 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.
| therealcamino wrote:
| "Eschew" means "to avoid habitually especially on moral or
| practical grounds".
| galenlynch wrote:
| 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".
| lucb1e wrote:
| > 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.
| tediousdemise wrote:
| 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?
| lucb1e wrote:
| 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-j wrote:
| 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.
| gpderetta wrote:
| 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.
| scottlamb wrote:
| 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/b984c8dccaafdcdd1b18
| 1786a...
|
| [2] https://dave.cheney.net/2018/05/29/how-the-go-runtime-
| implem...
| xfer wrote:
| Really? You have megabytes of memory but can't run C++? Which
| architecture is this?
| mpfundstein wrote:
| 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.
| userbinator wrote:
| Perhaps you'd like to point out an actual bug you've found...?
|
| This sort of dogmatic cargo-culting paranoia-rant is exactly
| why people are getting sick of hearing about the "modern" BS.
| tediousdemise wrote:
| 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.
| scoutt wrote:
| 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.
| tediousdemise wrote:
| 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.
| villasv wrote:
| The modern C++ techniques being referred are 10 years old at
| this point already and have stayed in consensus. No need to
| get salty.
| higerordermap wrote:
| > 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"
| tediousdemise wrote:
| Very true. This is why I appreciate C++'s lack of a universal
| package manager.
| yupyup54133 wrote:
| 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.
| lucb1e wrote:
| 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.
| dwpdwpdwpdwpdwp wrote:
| Oh man, wait till you see the Linux source code...
| [deleted]
| lucb1e wrote:
| 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.
| slezyr wrote:
| > 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
| orf wrote:
| Leak can mean different things. None of those types in the
| link are stack allocated, I think.
| tediousdemise wrote:
| 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.
|
| https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC.
| ..
| allo37 wrote:
| It's the same deal as creating a circular references using
| `std::shared_ptr` in C++.
| hctaw wrote:
| Ownership semantics in rust largely prevent circular
| references, so it's not the same deal
| allo37 wrote:
| 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 ?
| steveklabnik wrote:
| Yes, it is the same thing.
| hctaw wrote:
| 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.
| genericacct wrote:
| Can you provide an example that streams from a v4l device?
| crakenzak wrote:
| 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?
| skeletal88 wrote:
| 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.
| phoboslab wrote:
| MPEG1 over WebSockets: https://jsmpeg.com/
| sodality2 wrote:
| The perf test page doesn't go over WS at all, it's just get
| requests.
| mypalmike wrote:
| How is it better than what?
| ianlevesque wrote:
| People mostly do this for lower latency.
| rapsey wrote:
| 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.
| Sean-Der wrote:
| 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.
|
| [0] https://webrtcforthecurious.com/docs/01-what-why-and-how/
| pratio wrote:
| Excellent website btw, thank you.
| zip1234 wrote:
| 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.
| diericx wrote:
| In complete sincerity, how is this better than ffmpeg
|
| https://trac.ffmpeg.org/wiki/StreamingGuide
| Randor wrote:
| 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.
| riedel wrote:
| Maybe it would be a good starting point for someone
| integrating it into ffmpeg
| Randor wrote:
| 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.
| defied wrote:
| If you're using ffmpeg with rtp, you can use Pion to make it a
| WebRTC stream:
| https://github.com/pion/webrtc/tree/master/examples/rtp-to-w...
| bodegajed wrote:
| WebRTC with STUN is pure p2p where ffmpeg it requires a rtmp or
| rtsp server
| diericx wrote:
| Ahh I see
| [deleted]
| jcelerier wrote:
| ... how is STUN pure p2p ? you still need to have a STUN
| server somewhere no ?
| bodegajed wrote:
| You can just use google stun servers they are free to use
| _joel wrote:
| Here's a list of public STUN servers (non google too)
| https://www.voip-info.org/stun/
| fulafel wrote:
| 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.
| j1elo wrote:
| 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.
| noseratio wrote:
| 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.
| callesgg wrote:
| 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.
| rashkov wrote:
| 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.
| callesgg wrote:
| Go read about stun.
|
| 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.
| uuidgen wrote:
| 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.
| a1369209993 wrote:
| > when network devices in between are broken or are
| [maliciously] actively preventing it.
|
| Those are called "middleboxes" (IIRC) and they're
| unfortunately somewhat pervasive.
| labawi wrote:
| 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.
| jcelerier wrote:
| > STUN is just for punching holes in your NAT router, and
| also discovering what is your public IP address.
|
| 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
| bodegajed wrote:
| 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
| the8472 wrote:
| Then bittorrent is transcendent p2p?
| tinus_hn wrote:
| 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.
| sublimefire wrote:
| 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
| Sean-Der wrote:
| It's a little more nuanced than this.
|
| 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[0] and now ahead of time if
| you need a TURN server.
|
| To understand NAT behaviors more check out [1]
|
| [0] https://github.com/pion/stun/tree/master/cmd/stun-nat-
| behavi...
|
| [1]
| https://webrtcforthecurious.com/docs/03-connecting/#nat-
| mapp...
___________________________________________________________________
(page generated 2021-04-08 23:02 UTC)