Pull-based streaming can work with webrtc. I implemented it for my custom ip camera nvr solution. I just open N streams on the client and when one is deactivated (typically by scrolling it out of the viewport), the client sends an unsubscribe message over a separate control channel and the server just stops sending video until they resubscribe.
I'm currently switching to a quic-based solution for other reasons, mainly that webrtc is a giant blackbox which provides very limited control[1], yet requires deep understanding of its implementation[2] and I'm tired[3].
I looked at moq-lite but decided against it for some reason. I think because I have <5 clients and don't need the fanout. The auth strategy is very different than what I currently use too.
[1] Why is firefox now picking that (wrong) ice candidate?
[2] rtp, ice, sdp, etc
[3] webrtc isn't bad for the video conferencing use-case but anything else is a pain
I wouldn't say I'm done evaluating it, and as a spare-time project, my NVR's needs are pretty simple at present.
But WebCodecs is just really straightforward. It's hard to find anything to complain about.
If you have an IP camera sitting around, you can run a quick WebSocket+WebCodecs example I threw together: <https://github.com/scottlamb/retina> (try `cargo run --package client webcodecs ...`). For one of my cameras, it gives me <160ms glass-to-glass latency, [1] with most of that being the IP camera's encoder. Because WebCodecs doesn't supply a particular jitter buffer implementation, you can just not have one at all if you want to prioritize liveness, and that's what my example does. A welcome change from using MSE.
Skipping the jitter buffer also made me realize with one of my cameras, I had a weird pattern where up to six frames would pile up in the decode queue until a key frame and then start over, which without a jitter buffer is hard to miss at 10 fps. It turns out that even though this camera's H.264 encoder never reorders frames, they hadn't bothered to say that in their VUI bitstream restrictions, so the decoder had to introduce additional latency just in case. I added some logic to "fix" the VUI and now its live stream is more responsive too. So the problem I had wasn't MSE's fault exactly, but MSE made it hard to understand because all the buffering was a black box.
What was the WebRTC bug, would love to help! I saw at work that FireFox doesn't properly implement [0] I wanted to go fix after FFmpeg + WHEP.
If you are still struggling with WebRTC problems would love to help. Pion has a Discord and https://webrtcforthecurious.com helps a bit to understand the underlying stuff, makes it easier to debug.
You can convert any push-based protocol into a pull-based one with a custom protocol to toggle sources on/off. But it's a non-standard solution, and soon enough you have to control the entire stack.
The goal of MoQ is to split WebRTC into 3-4 standard layers for reusability. You can use QUIC for networking, moq-lite/moq-transport for pub/sub, hang/msf for media, etc. Or don't! The composability depends on your use case.
And yeah lemme know if you want some help/advice on your QUIC-based solution. Join the discord and DM @kixelated.
> I could use AI and have a working solution an hour later.
That sounds really cool. You should share what you used.
> The goal was not to become a Bluetooth archaeologist. The goal was to solve the problem.
I'm sympathetic to this view. It seems very pragmatic. After all, the reason we write software is not to move characters around a repo, but to solve problems, right?
But here's my concern. Like a lot of people, I starting programming to solve little problems my friends and I had. Stuff like manipulating game map files and scripting ftp servers. That lead me to a career that's meant building big systems that people depend on.
If everything bite-sized and self-contained is automated with llms, are people still going to make the jump to be able to build and maintain larger things?
To use your example of the BLE battery monitor, the AI built some automation on top of bluez, a 20+ year-old project representing thousands of hours of labor. If AI can replace 100% of programming, no-big-deal it can maintain bluez going forward, but what if it can't? In that case we've failed to nurture the cognitive skills we need to maintain the world we've built.
It has also led me to a career in software development.
I find myself chatting through architectural problems with ChatGPT as I drive (using voice mode). I've continued to learn that way. I don't bother learning little things that I know won't do much for me, but I still do deep research and prototyping (which I can do 5x faster now) using AI as a supplement. I still provide AI significant guidance on the architecture/language/etc of what I want built, and that has come from my 20+ years in software.
This is is the project I was talking about. I prefer using codex day-to-day.
And? I didn't say anything about "incitement", I said "actual death/violence threats", because I meant people making actual threats of violence up to and including death, are the actual things tweeted in the most commonly seen examples given on Hacker News (besides the aforementioned "also not upheld" that the commenter I was replying to tried to use to justify when Americans get arrested for tweets).
> The classical cultural example is the Luddites, a social movement that failed so utterly
Maybe not the best example? The luddites were skilled weavers that had their livelihoods destroyed by automation. The govt deployed 12,000 troops against the luddites, executed dozens after show trials, and made machine breaking a capital offense.
I caught that too. The piece is otherwise good imo, but "the luddites were wrong" is wrong. In fact, later in the piece the author essentially agrees – the proposals for UBI and other policies that would support workers (or ex-workers) through any AI-driven transition are an acknowledgement that yes, the new machines will destroy people's livelihoods and that, yes, this is bad, and that yes, the industrialists, the government and the people should care. The luddites were making exactly that case.
> while it’s true that textile experts did suffer from the advent of mechanical weaving, their loss was far outweighed by the gains the rest of the human race received from being able to afford more than two shirts over the average lifespan
I hope the author has enough self awareness to recognize that "this is good for the long term of humanity" is cold comfort when you're begging on the street or the government has murdered you, and that he's closer to being part of the begging class than the "long term of humanity" class (by temporal logistics if not also by economic reality).
> We should hate/destroy this technology because it will cause significant short term harm, in exchange for great long term gains.
Rather
> We should acknowledge that this technology will cause significant short term harm is we don't act to mitigate it. How can we act to do that, while still obtaining the great long term gains from it.
TFR doesn't account for mortality which has also continuously fallen since then. If you're not adjusting for that, then you're looking at meaningless decontextualized numbers. Obviously if people want a certain number of children and the children keep dying then they're going to need to give birth more to get the right number of children. Birthing is not a useful measure on its own because pre-adulthood dead children lead to the same impact on population growth as no children in the first place.
Unfortunately, many of these system don't offer any kind of local control, like the ability to monitor and set charge level. You have to use a cloud service with Ecoflow systems, for example.
Does this system allow local control and monitoring, ie without a cloud service? Ecoflow does not, although someone has reverse engineered the bluetooth protocol for some models.
Is it UL9540(UL energy storage system safety standard) certified? I didn't see it listed in the specs but several of the ecoflow models are.
I'm currently switching to a quic-based solution for other reasons, mainly that webrtc is a giant blackbox which provides very limited control[1], yet requires deep understanding of its implementation[2] and I'm tired[3].
I looked at moq-lite but decided against it for some reason. I think because I have <5 clients and don't need the fanout. The auth strategy is very different than what I currently use too.
[1] Why is firefox now picking that (wrong) ice candidate?
[2] rtp, ice, sdp, etc
[3] webrtc isn't bad for the video conferencing use-case but anything else is a pain
reply