Adding Live Video to a Smart-Home Platform, from Proof of Concept to Scale
Adding a first WiFi IP camera to an existing smart-home platform built around short-range wireless devices, from an initial proof of concept through to a media platform designed to scale to a million cameras.
Context
A connected-home devices provider's existing platform was built around short-range wireless protocols: thermostats, locks, lighting, and similar sensors, all communicating over an established low-power mesh network. A camera was something categorically different: continuous IP video over WiFi, the platform's first device of that kind, and the existing infrastructure had no support for it at all.
Naeva Tec was brought in for the media side of that problem: turning a consumer WiFi camera's raw video into something the provider's own mobile app could show a user live, store, and play back later, without asking the rest of an already mature platform to change shape to accommodate it.
Proving it first, in under two seconds
Before committing to a full build, the provider wanted a proof of concept with clear, measurable goals:
- Live streaming from the camera.
- Motion-triggered recordings, uploaded automatically to the cloud.
- Recording selection and playback.
- A mobile app exercising all of the above end to end.
- Latency under two seconds for both live viewing and playback.
- An architecture that could plausibly scale to a million cameras later, even though the proof of concept itself would only ever run a handful.
We built this on Kurento Media Server: a Java control server subscribing to camera-generated events over MQTT, an RTSP-in/WebRTC-out media path for live viewing, an S3-backed recording repository, and a REST API driving a small native mobile app built specifically to validate the concept, deliberately kept separate from the provider's own production app so the media pipeline could be proven almost standalone first.
From proof to production
Once the concept held up, the work moved into a full production build alongside the provider's own engineering team, delivered sprint by sprint as part of their existing agile process rather than as a separate, isolated project. The scope grew accordingly:
- Real integration with the provider's own device-messaging platform, replacing the isolated proof-of-concept pipeline.
- Scalability and deployment work actually sized for up to a million cameras, not a handful.
- Adaptive bitrate tuning, so a camera's stream degrades gracefully on a weak connection instead of stalling.
- Monitoring integration, so the operational tooling the provider already used for the rest of their platform could see the new camera traffic too.
- Ongoing support for the provider's own mobile apps as they added live view, recordings, and motion alerts for end users.
Our role
- Designing and building the Kurento Media Server and control-server pipeline, from proof of concept through production scale.
- Handling the RTSP-in/WebRTC-out signaling and lifecycle for each camera session.
- Building the event pipeline that turned camera-generated motion and audio events into stored recordings and push notifications to the right user.
- Tuning the media path (adaptive bitrate, sub-two-second live latency) for a platform meant to eventually support a million devices.
- Working embedded in the provider's own sprint teams during the production phase, not as an external vendor working in isolation.
Technologies
- Kurento Media Server, for camera-to-viewer media relay and recording.
- A Java control server (Spring Boot), handling event processing and the REST API.
- MQTT, for camera-to-cloud event signaling.
- AWS (EC2 and S3), for compute and recording storage.
- REST APIs with JSON payloads, and native mobile clients (iOS, later Android) consuming them.
- Push notifications, delivering motion and audio events to the right user's device.
Conclusion and lessons learnt
Proving the hardest part in isolation first, low-latency live streaming and recording at consumer IP-camera scale, let both sides validate the riskiest assumptions (codec support, latency, eventual scale) before that work had to compete with everything else already built into a mature platform. It also made the harder lesson visible early: adding one genuinely new device type to an ecosystem that was never designed for it is rarely just a media problem, and the production phase, embedded directly in the provider's own team, was where that integration work actually happened.