Streamie Security, Inc

Streamie v4.6.0 added Rhombus SRS (Secure Raw Streams) support, amazingly, before we actually had a Rhombus camera with which to test. Our shiny, new R200 just arrived and now I need to start looking at API features. The first-time-setup, Bluetooth-based camera discovery feature makes for a cool user experience; better than scanning a QR code from the bottom of a camera that you just mounted to a wall. Our first Streamie + Rhombus user has 62 (!!) cameras running on each Apple TV.

Streamie v4.6.0 is out! Try it out today: https://lnkd.in/grjGnX2E The highlight of this release is Rhombus SRS (Secure Raw Stream) support. Streamie is capable of displaying 60+ cameras on a single Apple TV. Full release notes are here: https://lnkd.in/ehetsq6a

Do your customers want to live stream your service, but you need to automatically limit them to certain hours? @streamieapp Shares can now be linked with Modes and you can do exactly that with just a few taps. New in Streamie v4.5.0. Try it today! Read more about Shared Camera Schedules here: https://lnkd.in/erR8bHZn Install Streamie v4.5.0: https://lnkd.in/gA9_GU8B

We're working on a proposal for a video security solution RFP. One requirement relates to license plate logging. @DahuaHQ LPR cameras don't have ONVIF integration, which is just a monumental oversight. One Streamie user has an @LTSecurityInc camera though, and it provides a "PlateNumber" parameter via ONVIF, which is exactly what we want. I made a minor tweak to @streamieapp to send all ONVIF parameters to a Function when an event occurs. I used @Cloudflare to quickly set up a Worker to log plates to KV. I created a Function in Streamie that grabs the "PlateNumber" parameter and passes it to the CF Worker. Finally, I create a new Action on the camera to call the Function whenever a license plate event occurs. It all "just works".

Modules with JSON payload let you easily add a hurricane tracker to Streamie.

Metrowerks CodeWarrior was peak cool. https://lnkd.in/ewabEycg

"When working with a WebSocket using Apple's NWConnection class, a call to the receiveMessage() function returns the error "Message too long". What is the default maximum message size and can that maximum be adjusted?" I was rooting for Grok, but ChatGPT nailed it. Has someone already developed a "Meta AI" (I don't mean the Facebook Meta) that sends the prompt to each of several LLMs and somehow combines and curates the results?

Streamie v4.3.2 Release Notes

I was naively assuming that if VTCompressionSessionCreate() reported success, that I'd have no problems encoding a video stream. Specifically, I was counting on it to fail if the device was not capable of performing H.265 encoding. A friend run Streamie on a pre-4K Apple TV. It happily creates the H.265 compression session and then fails the moment I try to encode the first video frame. When remote streaming, the component that asks for a video stream doesn't care about the specific codec, it just wants it encoded at the desired bitrate. "Use the best codec available." When this -12908 error occurs, Streamie now checks a bunch of conditions and gracefully downgrades to H.264 if it's appropriate to do so. The receiving component remains unaware of the chaos within and remote streaming "just works".

I don't know exactly where we started at, but mostly recently we were at 12m D1 read queries per week. Server-side caching has this down to ~4.5 million (3x improvement). Having got the read queries under control, I couldn't understand why I'm doing so many (1,200+ per minute) row writes. The answer was obvious in hindsight (after nagging the D1 Discord support channel): each "row written" includes index updates. The irony here is that one reason for all of the indexes is to avoid the cost of table scans, but reads are basically free on D1 ($0.001 per million), while writes are 1,000x more expensive. In my attempt to save on read costs, I'm actually spending more. Of course, the indexes also considerably speed up the read queries, so I'm not changing anything. Let's ignore speed as a factor though. I'm looking at 3 - 8 rows written per actual write query. Let's call it 5. And they're 1,000 more expensive than reads: each write query costs 5,000x more than a read (when using indexes). As long as the lack of indexes didn't result in more than 5,000x rows read per query, it'd be cheaper to drop the indexes. But not faster, of course.