Loading…
Loading…
Why Aptibit built a native streaming engine for Visylix instead of wrapping FFmpeg, and what that choice means for live video and AI at enterprise scale.
Anyone building a live video product eventually hears the same question: why not simply use FFmpeg? It is a fair question. FFmpeg is the open-source multimedia toolkit behind a vast range of video platforms, media players and commercial products.
When we began building Visylix, our automated AI video surveillance platform, we chose a different path. We built our own native streaming engine, in-house. It was a significant investment of time and senior engineering effort, and we made it deliberately. This article explains why.
Visylix is built for large estates: campuses, cities, transport networks and industrial sites where a great many cameras connect to one platform. Operators need live video with almost no delay. At the same time, AI analytics need to watch those feeds continuously and raise alerts the moment something happens.
That workload never pauses. It runs every hour of every day, and it has to stay stable for months at a time. As we studied how video platforms typically behave as camera counts grow, one pattern stood out. The cost of each extra camera kept rising, live delay stretched, and the usual answer was simply to buy more servers.
FFmpeg is a remarkable piece of software. It converts video between formats, supports an enormous range of codecs (the methods used to compress video), and handles recording and processing tasks with great reliability. In practice, it is a powerful toolkit and command-line tool for working with media.
Running a live surveillance estate is a different job. It means keeping thousands of camera connections open, delivering each feed to browsers instantly, recording it, and passing it to AI models, all at once and all day. FFmpeg can be part of such a system, but it was not designed to be the server at its centre.
When video is decoded and re-encoded several times on its way to storage, analysis and the browser, every step costs processing power. Multiply that by a large camera count and the processing bill becomes the limit. We wanted a design that raised that ceiling rather than one that just added servers.
Building our own engine was the harder road. It added months to our timeline and meant solving problems that FFmpeg had long since solved, from handling container formats to negotiating streaming protocols.
In return, we could design every layer around one purpose: carrying a large number of live streams, running AI on them, and using as little of the server as possible. Three design principles guided that work.
A media toolkit is usually pointed at one file or one stream at a time. A surveillance platform must look after every camera at once.
We designed the Visylix engine from the start to manage a whole estate of live connections within one efficient service. The overhead of each additional camera stays small, so growth in camera count does not translate into the same growth in servers.
The most expensive thing a video platform can do is decode and re-encode video it did not need to touch. Wherever it can, Visylix passes the camera's own video through unchanged, to recording, to analytics and to the browser.
That frees processing power for the work that matters: AI analysis and fast live view. It also means operators see the image as the camera captured it.
Many systems look good in a short demo and slowly degrade over weeks of continuous running. Video traffic is uneven: frames arrive at varying rates, alerts trigger bursts of recording, and AI workloads rise and fall through the day.
We built the engine natively, so we control exactly how it uses the server's resources under that kind of load. The aim is simple. Performance on day ninety should look the same as performance on day one.
For operators, the most visible result is live view. Visylix delivers sub-second live video over WebRTC, the real-time technology built into modern browsers, and down to under 200 ms in good network conditions. Nothing needs to be installed at the desk.
The engine supports more than 13 protocols. It serves video over WebRTC, RTSP, RTMP, SRT, HLS, LL-HLS, MPEG-DASH, HTTP-FLV and HTTP-TS. It also takes in NDI, OMT, RIST and GB28181 feeds, and uses ONVIF, the common camera standard, for camera control.
Capacity depends on resolution, codec, frame rate and how many analytics run on each feed, so every deployment is sized precisely to the customer's own hardware and camera mix.
Building a streaming engine from the ground up took far more time and effort than wrapping FFmpeg would have. We had to master codecs, container formats, protocol negotiation and buffering, all problems FFmpeg handles out of the box.
The reward is a foundation designed for the workload Visylix exists to serve. For buyers, that means more of each server goes to watching and analysing video, live view stays fast, and the platform runs on hardware they own, whether on premise, at the edge, in a hybrid setup, fully air-gapped or in their own cloud account.
Every team building video software faces the same choice: build or wrap. Wrapping is faster to market. At Aptibit, we optimised for a different moment: the day a customer connects their thousandth camera and expects everything to keep working exactly as before.
Architecture shaped around the real workload is hard to substitute. FFmpeg remains an outstanding tool for what it was built to do, and we continue to respect and use open-source software where it is the right choice.
When a product must carry a large number of live streams, run AI on them continuously and keep live view under a second, a purpose-built engine is worth the investment. We built ours in Kolkata, and it is the foundation Visylix stands on. Sometimes the hardest engineering decision is the right one.
FFmpeg is an excellent toolkit for converting and processing video. It was not designed to be a streaming server that keeps thousands of live camera connections open around the clock. Products that wrap it can work well at small scale. For a platform built to run a large camera estate with AI on every feed, we wanted control of the whole path a video frame takes.
The clearest one for buyers is live view: sub-second over WebRTC, down to under 200 ms in good network conditions. The engine is also designed to do as little repeated work per camera as possible, so more of each server goes to analysis rather than to moving video around. We do not publish one headline streams-per-server figure, because it depends on resolution, codec, frame rate and how many analytics run. We size it on the customer's own hardware during the proof of concept.
Predictability. Surveillance video runs every hour of every day, and operators notice even brief stalls. Building the engine natively lets us control exactly how it behaves under sustained load, so performance stays steady over weeks and months, not just in a short demo.
Many months of focused work by a dedicated senior team, and the work continues with every release. It is an investment many companies choose not to make, which is why wrapping FFmpeg is so common. For us, it was the difference between competing on features alone and competing on the foundation underneath them.
For file conversion, batch transcoding, recording pipelines, small deployments, and any workload where live latency and very high concurrency are not the main constraints. In those cases FFmpeg is hard to beat. When you need a large number of live streams with AI analysis running continuously, a purpose-built engine starts to earn its cost.
No. The engine is built in-house and belongs to Visylix. It speaks open standards such as WebRTC, RTSP, HLS and SRT, and we use well-proven open-source libraries where they are the best choice. The engine itself is one of the things that sets Visylix apart.