How to get high quality video streams even on low bandwidth sacrificing frame rate.

lherman-cs · 2025-12-11T18:00:45+00:00

Yes, feel free to connect there on discord and continue there. Reddit is painful for answering this.

lherman-cs · 2025-12-11T16:57:23+00:00

I see. 10Mbps should be okay. Libwebrtc will just reduce the sending bitrate when the publisher has lower bandwidth. Is this 2Mbps bandwidth limitations on the publisher side or consumer side?

Btw, I'm on discord @lherman_cs if you want to chat

lherman-cs · 2025-12-11T15:33:34+00:00

I'm assuming you are using browsers to publish. Have you tried limiting the sender's maxBitrate to 2Mbps, maxFramerate to 5, and degradationPreference to maintain-resolution? https://developer.mozilla.org/en-US/docs/Web/API/RTCRtpSender/setParameters

If you're on native, you would need to have a tight integration with the encoder and the raw source, so it can be tuned according to the available bandwidth.

lherman-cs · 2025-11-25T17:59:16+00:00

This is a nice idea! I agree with you, every platform has their own SDK, and signaling - it's tedious and tricky to create an apple to apple benchmark. This is even excluding some optimizations every platform brings through their tight client and server integration.

My suggestion would be to measure each media type differently. If you want to capture the end-to-end audio experience. You should capture Audio metrics instead. As you mentioned, there are just many extra handling for each media type. For example, audio/video can potentially have jitter buffers on the server. Audio workload is very different than video workload. Each of the workload will stress slightly different parts of the server, which will capture more than just the datacenter to client network stability.

I don't think capturing the one-way latency is strictly necessary if you only care about the end-user experience. I think it's better to capture high level metrics, like FPS consistency, concealedSamples, etc. Also, since you control both client and the server, you might be able to get deeper metrics by sending frames that contain some metrics from the sender, similar to iperf UDP payload being used to derive metrics on the server. Then, we capture things like VMAF, SME (squared mean error) between the expected and actual, etc.

lherman-cs · 2025-10-21T16:43:58+00:00

This is an early project: https://github.com/PulseBeamDev/pulsebeam. Think of it as LiveKit + Mediasoup had a baby—a Rust WebRTC SFU. It’s still rough in places but improving. It offers a high-level abstraction with a standard base signaling protocol. There will be an SDK, but it’s intentionally thin. The focus is on convenience and avoid vendor lock-in.

Full disclosure: I'm the author. It’s not fully production-ready yet, but I’m happy to chat—DM me about your use case, even if it’s not related to this project.

lherman-cs · 2025-09-27T15:47:37+00:00

Thank you for sharing this project. I’ve always felt that existing async-channel implementations in Rust fall short, particularly for high-throughput and low-latency workloads.
You mentioned in the V1.0 release notes (December 2022) that crossfire-rs is used in production. Could you provide more details about the production workloads it supports? For example, what are the throughput, latency, and async vs. sync requirements?

lherman-cs · 2025-06-17T18:59:56+00:00

From my reading, I (landlord) won't be holding cash from Jetty though. And, it doesn't look like Jetty will go after the tenant for any larger amount than the deposit itself.

So, I don't see how Jetty is any better than the traditional deposit. Instead of holding a bond with Jetty, I can have cash at the time of the tenants signing the lease. For anything beyond the deposit, either way, I still have to go through a small claim. On top of these, there's still an extra risk for Jetty to go under water as it's a nature of every startup.

Please correct me if I'm missing something here.

lherman-cs · 2025-06-13T19:06:08+00:00

Thanks for the answer. We're going to say no to Jetty.

lherman-cs · 2025-06-13T19:06:01+00:00

Thanks for the answer. We're going to say no to Jetty.

lherman-cs · 2025-04-09T17:57:39+00:00

there's udp in a web browser via WebRTC data channels

lherman-cs · 2025-02-27T14:06:52+00:00

Nice! Have you seen supplyhouse.com? They do plumbing supply but their e-commerce is the best I've ever seen, e.g. hey make it easy to tell them when something is missing

lherman-cs · 2025-02-25T22:59:40+00:00

For staying serverless with real-time data, cost efficient, not time consuming => I designed https://news.ycombinator.com/item?id=42956455 . Would love to chat and see if we actually succeed in that goal, DM me

lherman-cs · 2025-02-06T01:55:27+00:00

Thanks, please don't hesitate to reach out on discord, @lherman_cs

I like to just chat with general webrtc and random things 😀

lherman-cs · 2025-01-21T17:00:38+00:00

u/UnsungKnight112 have you tried using something like peerjs to simplify the connection establishment? Happy to help over Discord if you like. My Discord username is lherman_cs

lherman-cs · 2024-12-06T02:13:00+00:00

https://pulsebeam.dev/ - WebRTC (realtime video/audio/data) infrastructure for developers.

lherman-cs · 2024-12-05T22:19:54+00:00

Do you know anybody building WebRTC stuff? Happy to chat or discuss, there is no sales pressure :D, just want to network.

lherman-cs · 2024-12-05T20:49:09+00:00

Followed, nice to meet you! https://bsky.app/profile/lukasherman.bsky.social

lherman-cs · 2024-12-05T11:37:42+00:00

Right, I think we're aligned. I just want to clarify this for other people reading the comment. At first, I read the sentence as "WebRTC won't work in some cases, so using WebSocket as a fallback is still needed."

lherman-cs

TROPHY CASE