353 points by Sean-Der 12 months ago | 69 comments
Sean-Der 12 months ago
* I want to show people that native WebRTC players can be a thing. I hope this encourages hangouts/discord/$x to implement WHIP and WHEP it would let people do so much more
* I wanted to make low latency sharing easier. I saw the need for this working on adding WebRTC to OBS and Broadcast Box[0]
* I wanted to show devs what a great ecosystem exists for WebRTC. Lots of great implementations in different languages.
* Was a bit of a ‘frustration project’. I saw a company claiming only their proprietary protocol can do latency this low. So I thought ‘screw you I will make an open source version!’
slashink 12 months ago
Sean-Der 12 months ago
Most Broadcast Box users tell me that’s their reason for switching off discord.
———
With WHEP I want to see easier co-streaming. I should be able to connect a room to my OBS instance and everyone’s video auto show up.
I don’t have this figured out yet. Would love your opinion and feedback. Wanna comment on the doc or would love to talk 1:1 ! siobud.com/meeting
eggsome 12 months ago
palata 12 months ago
Sean-Der 12 months ago
Between that and Simulcast I hope to make real-time video dramatically cheaper and easier
[0] https://docs.google.com/document/d/1Ed2Evze1ZJHY-1f4tYzqNZfx...
ta988 12 months ago
Sean-Der 12 months ago
We have vdo.ninja today and Twitch's Stream Together. Those both do the 'dual encoding' and it is a good enough experience that users are doing it!
xeonmc 12 months ago
Sean-Der 12 months ago
I created OBS2Browser[0] that is a good first step in the direction.
makapuf 12 months ago
cchance 12 months ago
Sean-Der 12 months ago
* Can play WebRTC in browser. That makes things easier to use.
* simpler/hackable software. BitWHIP is simple and uses nvenc etc… if you use nvenc with VNC I bet you can get the same experience
Karrot_Kream 12 months ago
namibj 12 months ago
It's much more appropriate to do perceptual fairness than strict bitrate fairness.
Happy to have a chat on this btw; you can best catch me on discord.
stefan_ 12 months ago
namibj 12 months ago
Apple already opportunistically uses L4S with TCP-Prague and there are real-world deployments/experiments [2] with end-to-end L4S.
Fixed-
[0]: https://github.com/cablelabs/lld [1] relevant excerpt from [0]: Applications that send large volumes of traffic that need low latency, but that are responsive to congestion in the network. These applications can benefit from using a technology known as "Low Latency, Low Loss, Scalable Throughput (L4S)". Support for this technology is including in the LLD feature set, but is beyond the scope of what we have in this repository. Information on L4S can be found in this IETF draft architecture.
[2]https://www.vodafone.com/news/technology/no-lag-gaming-vodaf...
mcwiggin2 12 months ago
mwcampbell 12 months ago
Sean-Der 12 months ago
nvidia is the absolute lowest I believe. I wanted to do it first to know if it was worth building.
tamimio 12 months ago
Did the company have a “ripple” in its name? Curious
Sean-Der 12 months ago
tamimio 12 months ago
kiririn 12 months ago
What I eventually settled on was https://github.com/Edward-Wu/srt-live-server with OBS and VLC player, which gives robust streaming at high bitrate 4k60, but latency is only 1-2 seconds
Sean-Der 12 months ago
eigenvalue 12 months ago
cargo:rustc-cfg=feature="ffmpeg_7_0"
cargo:ffmpeg_7_0=true
--- stderr
cl : Command line warning D9035 : option 'o' has been deprecated and will be removed in a future release
thread 'main' panicked at C:\Users\jeffr\.cargo\registry\src\index.crates.io-6f17d22bba15001f\bindgen-0.69.4\lib.rs:622:31:
Unable to find libclang: "couldn't find any valid shared libraries matching: ['clang.dll', 'libclang.dll'], set the `LIBCLANG_PATH` environment variable to a path where one of these files can be found (invalid: [])"
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
mintplant 12 months ago
warkdarrior 12 months ago
Sean-Der 12 months ago
I am also going to drop the 7z usage. Powershell has unzip built in
daghamm 12 months ago
I understand people have their tooling preferences, but this looks like something that build.rs or a plain makefile could have handled?
mijoharas 12 months ago
I'm familiar with makefiles, is there a particular advantage to using just over makefiles or is it personal preference? (which is a totally valid answer! I'm just wondering if I'm missing something)
aerzen 12 months ago
mijoharas 12 months ago
On reflection though, the timestamp dependant part isn't really something used much nowadays apart from compiling C.
It'd be cool if it was an opt-in feature for just files so that it could actually function as a replacement for make in all cases.
I went looking in the docs and found this[0] which I'd missed last time I looked into justfiles.
[0] https://github.com/casey/just?tab=readme-ov-file#what-are-th...
daghamm 12 months ago
Make has its issues, but it also has two big advantages: it's simple and everyone already have it.
IshKebab 12 months ago
That said I kind of agree. I like the idea of `just` but it does seem like they have just created a complicated DSL.
I think it is better to just write your infra scripting in a real language. I generally use Deno or Rust itself and a thin wrapper that `cargo run`'s it. Using Rust eliminates a dependency.
mort96 12 months ago
IshKebab 12 months ago
Not even remotely. I know it might be hard to imagine if you only program on Linux/Mac but there's a whole world out there that isn't built on janky shell scripts and Makefiles. If you use C# or Java or Visual C++ or Qt on Windows it's pretty unlikely that you'd have Make. It's kind of a pain to install and you don't need it.
krageon 12 months ago
galdosdi 12 months ago
In fact, I didn't even know about .PHONY and have used make for a long time. That's what's great about it, even if you stick to the most basic features make is incredibly easy and straightforward. Dare I say, it "just" works lol.
I hate the proliferation of new tools that are the same as a tool that's been around for 20 years and is no different in any significant way except being trendy. Just unnecessary entropy. Our job is to manage and reduce, not maximize entropy.
dijit 12 months ago
Not always, Go programmers for example often forget that they need C build-tools for their platform to get Make.
It's also just about the furthest thing from simple, the language is nasty so people just use it as an executor, which is a lot of tooling for such a simple use-case.
Arnavion 12 months ago
>The explicit list of phony targets, written separately from the recipe definitions, also introduces the risk of accidentally defining a new non-phony target.
... seems to think the only way to define phony targets is:
.PHONY: foo bar
foo:
...
bar:
...
... which has the problem that bar's definition is distant from its declaration as a phony target. But this form is equivalent and doesn't have that problem: .PHONY: foo
foo:
...
.PHONY: bar
bar:
...
This ability to declare dependencies of a target over multiple definitions isn't even unique to `.PHONY`.daghamm 12 months ago
I'm not against new better tooling, but I also want to keep my dev machine reasonably clean.
IshKebab 12 months ago
hughesjj 12 months ago
galdosdi 12 months ago
mharrig1 12 months ago
We're building a set of apps that need to run on Linux, MacOS, and Windows so having a consistent solution for each is better than shell scripting and I personally have never felt great about make and it's weirdness.
It also helps that we have a pretty big monorepo so that anyone can bounce from one app to another and `just run` to use any of them, no matter the platform.
Either way the justification for me came from COSMIC[0].
[0] https://github.com/pop-os/cosmic-epoch/blob/master/justfile
Sean-Der 12 months ago
Just is nice as a Windows user. When I started committing everything worked really well already. Editing the just stuff also is really easy. Much nicer to read then scripts I think
comex 12 months ago
Tielem 12 months ago
WebRTC is a great technology, but it still suffers from a scaling problem that is harder to resolve. On top of that, the protocol itself does not define things like adaptive bitrate switching or stalling recovery
Curious to hear what you think of some (proprietary) options for low latency playback like LLHLS LLDASH, WebRTC or HESP
Sean-Der 12 months ago
WebRTC doesn’t have a scaling problem. I think it was a software problem! Twitch, Tencent, Agora, Phenix all do 100k+ these days
I like WebRTC because of the open-ness of it. I also like that I only need one system for ingest and playback. I am HEAVILY biased though, way over invested in WebRTC :) I tend to care about greenfield/unique problems and not enough about scaling and making money
kierank 12 months ago
It's left as an exercise to the reader which methods of lying are being used in this case.
tamimio 12 months ago
krick 12 months ago
notjoemama 12 months ago
imtringued 12 months ago
Indeed, you'll have to live with something like 80ms to 100ms latency over the internet and a horrifying 160 ms if you want to have things respond to keyboard and mouse inputs.
jeffhuys 12 months ago
notjoemama 12 months ago
crtasm 12 months ago
geraldwhen 12 months ago
So the answer is “there’s a data center in your city.”
Sean-Der 12 months ago
You can either pull the video from a WHEP source or run in a P2P mode. I wanted to demonstrate the flexibility and hackability of it all :)
1oooqooq 12 months ago
Sean-Der 12 months ago
Dwedit 12 months ago
jmakov 12 months ago
Sean-Der 12 months ago
Any interest in getting involved? Would love your help making it happen
12 months ago
coolThingsFirst 12 months ago
synthoidzeta 12 months ago
darby_nine 12 months ago
metadat 12 months ago
Otherwise in this instance it'd have been reduced to merely "Here's a thing". Pretty dull and boring.
ericd 12 months ago
EmanuelMcDaniel 12 months ago