DEV Community: RUSEGAL

RUSEON Core – Self-hosted video infrastructure for RTSP and AI

RUSEGAL — Thu, 27 Aug 2026 07:39:40 +0000

I built RUSEON Core — a self-hosted server for working with RTSP cameras, video streaming, archive recording, and connecting AI pipelines.
The project came out of a work-related task. We needed to stream surveillance cameras to the website of a government organization. The cameras themselves are portable: they are installed with IoT routers and constantly move between different sites. Therefore, a traditional NVR at each site was not suitable — the video infrastructure had to be centralized. The task was simple: receive RTSP and deliver it as HLS (or any format that can be played in a browser without problems). We also needed 24/7 recording with at least two weeks of storage.

For the first three years — Wowza, everything worked well, but with huge resource consumption. Then — Flussonic, which was better, but even now 60 permanently active cameras and 15–20 occasionally active cameras consume around 10 GB of RAM.
At first I looked at MediaMTX, which seemed to be as close as possible to what I needed. But around the streaming layer, there were still many other things needed — UI, archive handling, camera-specific data, monitoring, AI integration.

Instead of forking MediaMTX, I took gortsplib as the foundation and started building my own system on top of it. The pipeline looks roughly like this: RTSP – RUSEON Core – WebRTC/HLS/Recording – gRPC – AI worker – AI Metadata. At the moment there is a web UI, Prometheus metrics, RBAC, camera tags and folders, camera history, traffic accounting, fragmented archive with timeshift, MQTT and gRPC integration.

For WebRTC/HLS, no unnecessary work is done. In 90% of cases, the Zero-Alloc and Zero-Transcoding principles are followed. In particular, one of the features is that when a codec is not supported, WebCodecs is used on the client side. As well as AI detection through ONNX Runtime in the browser (while still retaining the option of using traditional AI).

Some things in the implementation also turned out to be quite interesting, for example using the OS page cache so that the archive does not have to be kept in memory, and implementing batching through sendmmsg() for WebRTC, which reduced CPU load by about 27% in my tests. Speaking of tests, during an 8-hour test with 600 incoming RTSP streams, 18,000+ incoming FPS, 1,800 HLS viewers, 240 WebRTC peers, 10 API workers, 20 gRPC AI workers, and an event bus — average memory consumption was 707 MB, average CPU usage was 52.4%, with a peak of 98.1%. On average, about 3.2 cores out of 12 were used. (12 cores, 32 GB RAM)
An important clarification — the load generator and RUSEON Core were running on the same machine. This is not a distributed benchmark. Logically, the numbers should be better without competition for resources.

I don't consider the project finished yet. I especially want to understand whether the architecture itself makes sense and whether I am trying to solve too many things with a single server. I would be especially interested in feedback from people who have worked with RTSP/media servers, WebRTC, NVRs, or computer vision pipelines.

Source: https://github.com/RUSEGAL/ruseon-core

Scaling WebRTC Streams with Engine Pooling in Go

RUSEGAL — Tue, 18 Aug 2026 06:01:36 +0000

FATAL: crypto/rand: blocked on getrandom() syscall, or 100% CPU at the 25th Client

The title is catchy enough—now let’s get to the point.

This error is a classic side effect of the default Pion WebRTC setup in Go. It is easy to reproduce: you read the usual Pion usage guides, deploy a nice-looking WHEP handler, open a couple of—okay, okay, not literally a couple, just a figure of speech—browser tabs with the player, and suddenly the server starts choking.

Handshakes begin taking seconds, ICE times out, and half of the pprof flame graph is filled with crypto/elliptic.p256OrdSqr and map allocations somewhere inside the engine.

Surprised?

There is really nothing surprising about it if you read most WebRTC tutorials for Go a little more carefully. I get the impression that many of them were written by people who never load-tested their implementation with even fifty concurrent viewers—at most a couple of streams, and that was apparently enough for them.

Here is what they usually do: for every POST request containing an SDP offer, they create a new webrtc.NewAPI(), register the default codecs, call api.NewPeerConnection(), and happily return the response.

On localhost, with a couple of clients, it flies.

In production, however, it turns into a disaster.

The problem here is not WebRTC itself—and certainly not Pion, which is a great library—and it is not Go either.

The problem is that expensive global “infrastructure” is being created for every single request instead of simply being reused.

Let’s dig into what is actually happening

A small disclaimer: from this point on, I am not going to explain every single term in detail. If something is unclear, it is better to check the documentation or ask in the comments—otherwise, this would turn into an extremely long post.

The first expensive operation is generating cryptographic material for DTLS.

For this, ECDSA P-256 keys are generated and later used to create the DTLS certificate. It is important to understand that key generation is not just a couple of constructor calls and writing a few bytes into memory.

Under the hood, it uses crypto/ecdsa, heavy elliptic-curve mathematics, and cryptographically secure randomness from crypto/rand.

The second expensive operation is allocating hundreds of small structures on the heap for all possible codecs, RTCP interceptors, RTP headers, header extensions, and other internal components.

None of these allocations are exactly free.

The third expensive operation happens at the end: the implementation goes into the OS and opens a bunch of random UDP ports for ICE candidate gathering and binding.

In a typical configuration, this means allocating new network resources for every PeerConnection.

So, for every new connection, the pipeline looks roughly like this:

New viewer

    │

    ├── ECDSA P-256
    │   └── crypto/ecdsa + crypto/rand
    │
    ├── Creating and initializing WebRTC structures
    │   └── hundreds of small heap allocations
    │
    ├── Registering codecs and interceptors
    │
    ├── Creating the network transport
    │
    └── UDP sockets + ICE candidate gathering

And what is the result?

Thirty viewers connect simultaneously—the CPU gets hammered by key generation, the connection tracking table starts ballooning, and the garbage collector strikes a pose while trying to clean up tons of dead objects left behind after every closed connection.

There is no point in building workarounds here.

The architecture needs to be designed properly from the beginning:

everything that can be reused should be reused.

The solution we used

In RUSEON Core, all of the heavy work was moved into an isolated singleton engine in internal/webrtc/engine.go.

Certificate generation now happens exactly once through:

ecdsa.GenerateKey(elliptic.P256(), rand.Reader)

when the server starts.

The browser does not care whether the certificate was created a second ago or has been sitting in RAM for months. All it needs is a cryptographically valid fingerprint in the SDP offer—and nothing more.

The codec registry is initialized at startup as well and no longer constantly touches the heap.

The network layer is also usually a bottleneck.

But instead of opening dozens of random ports, we attached webrtc.NewICEUDPMux to a single UDP socket.

One port is used by the entire system.

The OS kernel multiplexes all incoming STUN, DTLS, and SRTP traffic through a single file descriptor, while Pion distributes packets between ICE and WebRTC sessions in userspace.

No port exhaustion.

No need to dance around opening a 50000–60000 port range in the firewall.

On top of that, an engine pool is used through sync.Pool:

var WebRTCEnginePool = sync.Pool{
    New: func() interface{} {
        return newWebRTCEngine()
    },
}

Important: sync.Pool is not used here as guaranteed storage for a predefined set of objects.

Its purpose is to allow temporary engine objects to be reused and reduce unnecessary allocations on the hot path. If the runtime clears the pool, New simply creates a new instance.

When a WHEP request arrives in internal/api/handler.go, the handler does not create anything unnecessary.

It retrieves an already warmed-up and ready instance, feeds it the pre-generated certificate through:

baseConfig.Certificates = []webrtc.Certificate{*e.certificate}

and immediately returns the SDP response.

In practice, the time from request to response is reduced to just a couple of system calls—not counting, of course, the creation of the PeerConnection itself, DTLS/ICE configuration, and SDP negotiation.

The end result is that a new viewer no longer forces the entire WebRTC stack to be created from scratch.

It creates only its own connection-specific state on top of an already prepared engine.

Pitfalls when using the H.264 codec

If you simply take NALU packets from the ring buffer and feed them directly into the stream, the video on the client will constantly freeze.

In our case, the browser’s hardware decoder requires clean Annex B with proper 0x00 0x00 0x00 0x01 delimiters, and every key IDR frame must include the stream’s SPS and PPS parameters.

One of the solutions we used was to allocate a pre-sized 100 KB byte buffer in internal/webrtc/muxer.go.

This makes it possible to reliably avoid slice reallocations while concatenating headers at 30 FPS.

Why does this matter at all?

Because append() on the hot path can be a scary thing.

As long as there is enough capacity, everything is fine.

But once there is not, Go allocates a new array, copies the old data into it, and the old array eventually ends up as dinner for the garbage collector.

At 30 frames per second, this can mean dozens of additional allocations for every stream.

And you never really know when the accumulated garbage will become significant enough to trigger the collector.

Multiply that by the number of streams and viewers, and I think the outcome is obvious.

The whole idea comes down to this: if the approximate size of a working buffer is known and bounded, allocate it once and reuse it.

Do not allow a slice to grow dynamically at every stage of the hot pipeline.

The numbers

For testing, we used our own load-testing utility, cmd/loadtest/main.go.

It simultaneously ran:

50 synthetic cameras
the REST API
30 HLS clients
30 active WebRTC viewers

Results:

[WebRTC WHEP] Sessions OK: 30 (err: 0) | RTP Packets: 488 214 | Egress: 9.04 MB/s

Handshake Latency: p50=3.21ms | p95=6.84ms | max=11.20ms

HeapAlloc: 34MB | GC Pause Total: 3.82ms | Goroutines: 142

Almost half a million RTP packets, a stable 9 MB/s of outgoing traffic, and exactly zero negotiation errors.

Handshake latency dropped from 800+ ms to 3 milliseconds.

Final thoughts

The main takeaway from this article is simple:

If WebRTC is not “handling” real video workloads, do not blindly trust the tutorials.

Especially when those tutorials suggest solving such problems by pulling in heavy CGO bindings to C++.

Our experience shows that the bottleneck is not the runtime itself, but rather mindlessly regenerating cryptography for every little thing and constantly hitting the allocator on the hot path.

WebRTC is not slow. The architecture around it is slow.

Source code: https://github.com/RUSEGAL/ruseon-core

HLS Lazy Muxing 2.0: How to Cut CPU Usage by 80% Without Stopping Archive Recording

RUSEGAL — Tue, 18 Aug 2026 05:55:41 +0000

If anyone has ever worked with video streaming over the internet—i.e., used a classic media server operating on an RTSP-to-HLS model (or similar protocols)—then they know the kinds of problems that arise. As an example, let’s take two industry giants: Flussonic and Wowza. Flussonic’s documentation provides clear hardware specifications at which CPU usage will hit 100%: 250 cameras at a bitrate of 2 Mbps on a Xeon E3-1230v5 3.4 GHz with 32 GB of RAM. Wowza does not provide equally specific examples, but if we extrapolate a bit, roughly 350–400 cameras at 2 Mbps on the same hardware would also max out the CPU.

Let me add one caveat: I understand that this hardware is fairly old. But around 80% of small and medium-sized businesses still run on something in this range—at least those that do not use cloud infrastructure or rent hardware in a data center. So, at first glance, you might think: well, that’s just the workload, what can you do? The problem is that, at any given moment, nobody may actually be watching these streams. The hypothetical security guard is scrolling through their phone, drinking coffee—and meanwhile, the server continues 24/7 to package raw frames into HLS segments and write the archive, heating up the server room.

It is simply a waste of resources when they are not actually needed. And in an era where hardware costs money, these things are worth paying attention to.

The solution seems obvious, and many people are already familiar with it: On Demand mode. No viewers—shut down the camera. A viewer appears—serve the HLS stream. At first glance, everything seems perfect. Problem solved, everyone can go home.

But this is where the main problem with classic On Demand appears: as soon as there are no viewers and the camera is shut down, archive recording stops as well. For any security system, that is a major red flag.

While developing RUSEON Core, I spent a long time wrestling with this architectural trade-off, because the main goal of the project is to consume as few resources as possible while delivering the maximum benefit. Eventually, I came up with a feature that I call Lazy Muxing 2.0 (sounds pretty good, doesn’t it?).

The idea is simple: the core runs continuously, the archive is always recorded, and only the heaviest component—the HLS muxer—goes to sleep. Now, let me explain how this was implemented and what pitfalls can be found along the way.

Low-Copy approach

A traditional video server pipeline is essentially monolithic. But as I mentioned in previous articles, RUSEON is architecturally split into independent components. These are not microservices, nor is this an attempt to move everything into separate processes. The point is specifically to isolate modules within a single process—meaning that no module should drag another one along with it, much less affect its lifecycle.

If we look under the hood (ring.go), we can see an isolated goroutine continuously pulling the RTSP stream. Frames are placed into a ring buffer, and from that point onward a low-copy approach is used.

Disk recording (recorder.go) is simply a subscriber to that buffer. It reads pointers to memory and writes the bytes to disk. That’s it. It does not care in the slightest whether anyone is watching or not. The archive is recorded 24/7.

// internal/recorder/recorder.go (simplified)

func (r *Recorder) run() {
    // Subscribe to the RingBuffer (Data Plane)
    reader := r.ringBuffer.NewReader()
    defer reader.Close()

    for {
        // Read a pointer to the frame without copying the actual bytes (Low-Copy)
        frame := reader.Read()
        if frame == nil {
            break
        }

        // Write NAL unit bytes to disk
        r.writeToDisk(frame)
    }
}

The heavy HLS muxer (muxer.go), on the other hand, is not a mandatory part of the pipeline. It simply sits there like a “lazy plugin” and attaches to the same buffer only when there is an actual consumer.

No HTTP requests for the playlist? The muxer does not even exist in memory.

This creates a simple principle:

Archive is permanent. HLS is temporary.

This separation makes it possible to avoid wasting server resources on creating and running an HLS stream for a camera that nobody is currently watching.

So how is this different from what Flussonic does?

A fair question arises here: is this actually something fundamentally new? No.

For example, Flussonic has long implemented separation between stream ingestion, DVR, and delivery.

In their documentation, Flussonic describes its approach as just-in-time packaging: the server receives the stream once and can immediately package it on the fly into different formats—HLS, DASH, RTMP, and so on. At the same time, the DVR, which is their archive, operates as a separate module that continuously records the stream.

So, roughly speaking, their architecture looks like this:

                  ┌──────────────► DVR / Archive
                  │
Camera ──► Ingest
                  │
                  └──────────────► JIT Packaging
                                      │
                                      ├── HLS
                                      ├── DASH
                                      └── other protocols

However, there is an important nuance when it comes to the term On Demand.

In Flussonic, ondemand primarily refers to the lifecycle of the input stream itself: if there are no viewers, the source is shut down, and when a request appears, the stream is started again. This is more about saving resources on ingestion and traffic.

Our implementation takes a somewhat different approach.

The stream itself and recording never depend on whether there is a viewer. The RTSP stream is always being ingested, the ring buffer remains active, and the recorder writes the archive 24/7.

On-demand behavior applies only to the heaviest part of the pipeline—the HLS packaging.

In other words, our architecture looks roughly like this:

No viewer
     ↓
Do not create the HLS muxer
     ↓
Ingest keeps running
     ↓
Archive keeps running

Based on that, it would be more accurate to say that Flussonic’s On Demand manages the lifecycle of the source itself—the RTSP connection—while Lazy Muxing in our implementation exclusively manages the lifecycle of the heavy pipeline component, the HLS packaging layer, while keeping the source RTSP stream hot and active for recording.

At the same time, Flussonic’s overall approach is, of course, much broader than our implementation. It is a full-featured system for delivering a single source through multiple output protocols.

Our task is much narrower: not keeping HLS multiplexing active for cameras that nobody is currently watching.

This allows us to tightly tie the lifecycle of the muxer to the presence of an actual HLS viewer.

Late viewers and low-latency startup

Another problem with On Demand is its relatively slow “wake-up” time.

The client presses Play—or autoplay is enabled, but they have just opened the browser or player—and... they are staring at a spinning loader for 5–15 seconds.

Why?

The issue lies in the HLS protocol itself. An HLS segment must begin with an I-frame, or keyframe.

As a result, the muxer wakes up and simply waits for the camera to send the next keyframe. If the camera’s GOP is configured for 2, 3, 4, or 5 seconds, the client will have to wait that long, plus the buffering time of the player itself.

In the worst cases, the total time from the first click to the appearance of an image can approach 30 seconds.

Nobody likes latency. HTTP/3 is on the horizon, and one of its advantages is precisely reduced latency.

So what did we do to work around this?

When the lazy muxer starts, it does not wait for new frames at all. Instead, it performs a dump of the RingBuffer. Since the buffer is circular—and we keep roughly 30 frames in it—it is guaranteed to contain the previous keyframe.

The muxer immediately extracts this historical GOP, assembles the first .ts segment, and serves it to the player.

The viewer gets an image almost instantly, aside from the player’s own buffering, which obviously does not disappear.

// internal/hls/muxer.go

func (m *Muxer) run() {
    // Get a channel where the RingBuffer will IMMEDIATELY provide
    // the historical GOP
    reader := m.ringBuffer.NewReader()
    defer reader.Close()

    for {
        frame := reader.Read()

        if currentBuf == nil {
            // Ignore everything until the first historical I-frame from the dump
            if !frame.IsKeyFrame {
                continue
            }

            // Instantly generate the first .ts segment!
            tsWriter = mpegts.NewWriter(currentBuf, tracks)
        }

        // ...
    }
}

The nuance here is that the video starts roughly a second behind real time, but for the viewer, the image appears almost immediately.

There are limitations, of course.

If your cameras—usually extremely cheap Chinese PTZ cameras—produce a keyframe once every 10 seconds, or God forbid even less frequently, then keeping such a large buffer in RAM becomes memory suicide.

Our buffer is tuned for a relatively small number of frames and frequent keyframes.

We are not trying to compensate for poor camera configuration by endlessly increasing the buffer size.

How do we know that the viewer has left, or: a mini watchdog

With WebRTC, everything is straightforward. The socket disconnects, the viewer is gone.

With HLS, however, things are a little more complicated.

It is plain HTTP. The player simply requests the .m3u8 file every few seconds.

At first, there was an idea to implement sophisticated analytics based on TCP sessions, but in the end, it was decided not to overcomplicate things.

Why reinvent the wheel when you can avoid it?

Instead, we implemented a very simple, brute-force, and straightforward watchdog.

I’ll just leave the code here:

// internal/stream/stream.go

// 1. Called on every HTTP request to the .m3u8 playlist
func (s *Stream) WakeUpHLSMuxer() *hls.Muxer {
    s.muxerMu.Lock()
    defer s.muxerMu.Unlock()

    s.lastHLSRequest = time.Now() // Update the timer

    // If the muxer is sleeping, start it
    if s.hlsMuxer == nil {
        s.hlsMuxer = hls.NewMuxer(s.ID, s.ringBuffer)
    }

    return s.hlsMuxer
}

// 2. Watchdog goroutine running in the background
func (s *Stream) lazyHLSWatchdog() {
    ticker := time.NewTicker(1 * time.Minute)

    for range ticker.C {
        s.muxerMu.Lock()

        // If there has been no activity for more than 60 seconds,
        // gracefully shut down the muxer
        if s.hlsMuxer != nil && time.Since(s.lastHLSRequest) > 60*time.Second {
            s.hlsMuxer.Stop()
            s.hlsMuxer = nil // Release memory and CPU
        }

        s.muxerMu.Unlock()
    }
}

The numbers

Words are great, but let’s look at the metrics.

A lot of features look great on paper, and then in production you suddenly discover goroutine leaks.

For testing, I wrote a utility that simulates 100 cameras running at 30 FPS.

That is 3,000 frames per second.

Two scenarios were compared:

100 active HLS viewers + recorder
100 sleeping HLS viewers, with only the recorder running

The memory graph in the second scenario is a perfect sawtooth. The average baseline is 1.3 GB.

And what happens to CPU usage?

It drops by almost 5×.

The core handles 3,000 FPS for continuous archive recording without even breaking a sweat, because it no longer has to perform multiplexing.

Sleeping viewers genuinely free up server resources instead of simply sitting there as dead weight.

In essence, you get stream density similar to a bare RTSP relay, while still retaining the convenience of web players and full archive recording.

========================================
RUSEON Core Capacity Test
Cameras: 100 | Viewers: 100 (Sleeping) | Duration: 60s
========================================
[*] Starting cameras and pipelines...
[*] Load test running...
Memory: 1056 MB (Alloc) | GC Pauses: 10
Memory: 1660 MB (Alloc) | GC Pauses: 11
Memory: 1241 MB (Alloc) | GC Pauses: 12  <-- GC cleanup (Perfect sawtooth)
...
Memory: 2471 MB (Alloc) | GC Pauses: 14
Memory: 1355 MB (Alloc) | GC Pauses: 15
========================================
RESULTS
Frames Ingested: 181 800
Average Ingest FPS: 3026.68
Final Memory Alloc: 1517 MB (Baseline)
========================================

Source: https://github.com/RUSEGAL/ruseon-core

Writing terabytes to disk in Go: Stopping the OS Page Cache from eating all your RAM (FADV_DONTNEED)

RUSEGAL — Sun, 09 Aug 2026 06:04:49 +0000

Hello everyone! This is the second article about the development of RUSEON-core, a Zero-Copy video streaming server for AI platforms and Edge video infrastructure. In the first article, I talked about the fundamental reason why we decided to create our own server in the first place. I also covered the main problem with most similar solutions — the "thundering herd" — and how we managed to squeeze out 8 Gbps on a single CPU core. By the way, I forgot to mention in that article that besides simple streaming, we also record the streams in fMP4 format. It’s stored locally for N amount of time, and it can fly off to an S3 bucket (depending on how long the clients want to keep the recordings).

This article is precisely about a non-obvious (well, at least to me, maybe for someone else it's an everyday thing) problem related to data storage and its specifics across all Operating Systems. So, let's dive in.

We rolled out our first release to production (100 cameras), made the clients happy, and started working. About an hour passed, and the alerts started flying. I SSH into the server, open htop, and see there's only 100 MB of free RAM. Uh-oh. I should clarify that the production server had 32 gigs of RAM. The expected behavior was that the CPU is chilling, the network card is chewing through the traffic, RAM usage is around 250-300 MB, and the disks are not heavily loaded. So, when you see numbers like that in htop, you start blaming yourself and your crooked hands that wrote this piece of "garbage". But still, we decided to go to Google, ChatGPT, and the like. Fortunately, the answer was found quickly, and we stopped beating ourselves up.

The code was absolutely not the culprit; Linux itself ate the memory. If you've ever written tons of data to a disk, I think you already know what’s going on. There is an "invisible enemy" known as the Page Cache. That was exactly the root of this problem.

How does the Page Cache work and what to do with it?
When your function that is supposed to write data to the disk actually writes data, it doesn't write it to the disk. It writes it to RAM. The logic of the Linux kernel is simple and trivial, and it is aimed at accelerating the "responsiveness" of the system. The whole essence can be explained like this: "Oh, they just wrote a hundred gigabytes of data, they will probably need to read this data soon. Let me keep it in the cache, the user will be happy they could read it so fast." And so it goes, gigabyte after gigabyte, until the server runs out of physical memory.

The typical solution to the problem is writing a bash script that runs echo 3 > /proc/sys/vm/drop_caches once an hour. And some people just ignore it and let the system kill random processes via the OOM Killer. But we are building a fault-tolerant thing. That doesn't work for us. The task is to explain to the OS kernel that our fMP4 video archive segments are write-only trash for a short amount of time (because if the client doesn't want to keep records for long, the archive gets cleaned up, and if they do, we send the archive to S3 after N time, and still clean up the local copy). So everything should work on the principle of "write and forget".

How to tame the Linux kernel via Go (the right way)
In C/C++, there is a system call for this: posix_fadvise. You can explicitly tell the OS exactly how you will be working with the file. In Go, this doesn't exist out of the box. But there is a very good package, golang.org/x/sys/unix, which allows you to easily replace the system call. The flag is called FADV_DONTNEED. We literally say to the kernel: "We wrote it, flush it to disk and get the hell out of the cache."

But there is one cruel nuance here, which I stumbled upon myself and racked my brain over for a long time (and all it took was reading the docs, but here, just like with assembling IKEA furniture: "Why do I need a manual, I know how to do it myself"). The Linux kernel does not remove pages from the cache if they are so-called "dirty" — meaning they haven't been physically written to the disk platter yet. If you just call Fadvise, nothing will happen.

First, you need to do a hard Sync().

// File: pkg/storage/localfs/file_linux.go
package localfs
import (
    "os"
    "golang.org/x/sys/unix"
)
type FileWrapper struct {
    *os.File
}
func (fw *FileWrapper) DropCache() error {
    // First, flush dirty pages to disk!
    if err := fw.File.Sync(); err != nil {
        return err
    }
    // And only then order the kernel to forget them
    return unix.Fadvise(int(fw.File.Fd()), 0, 0, unix.FADV_DONTNEED)
}

Architecture: How not to break the build on Windows
System calls are almost always a huge cross-platform headache. On Windows, the FADV_DONTNEED flag simply does not exist (hello there, Microsoft! Are you guys doing okay?). If you don't split the code for different OSs, the compiler will just tell you to get lost.

Therefore, a rather elegant (I invite you to argue this statement in the comments) interface was implemented. In the core of the recorder, there is now a check to see if the file descriptor knows how to drop the cache:

// OPTIMIZATION: Saving RAM from Page Cache
if dropper, ok := file.(registry.CacheDropper); ok {
    _ = dropper.DropCache()
}

And then comes the magic of Go build tags (thank you for those). In the file_linux.go file (with the //go:build linux tag), we call unix.Fadvise. And right next to it lies the file_others.go file (with the //go:build !linux tag), where the DropCache() method just does a regular Sync() and returns. The code is crystal clear, the linters are happy, and the build works everywhere.

So, what was the result?
We roll out the fixes, launch the exact same 100 cameras. I open the dashboard. The memory consumption graph looks almost like a perfect straight line. The server grabbed its rightful 250 megs for the Go process heap — and that's it. Hooray, victory! There is no more massive Page Cache growth. No processes are being evicted to swap. The server honestly writes tens of gigabytes per hour, and RAM is at peace.

By the way, when you are backing up databases, parsing giant logs, or simply writing heavy files — this feature will save you a mountain of headaches. I also don't understand why this flag is barely talked about or written about anywhere. Usually, people only write about how to properly allocate slices, but there is complete silence regarding the fact that at the level of file operations, your OS can reduce all your efforts to zero.

In short, in the open-source part of ruseon-core, this logic is now wired deep into the recording engine. The conclusion and advice I want to give is — don't blindly trust the kernel with memory, hoping that the OS is hypothetically "perfect and maximally thought out." Sometimes you have to slap the kernel on the wrist. Otherwise, you will run into similar problems as I did.

The source code, as always, is available on GitHub: https://github.com/RUSEGAL/ruseon-core

How We Served 8 Gbps of Video on a Single Go CPU Core (And Survived the Thundering Herd)

RUSEGAL — Fri, 07 Aug 2026 09:24:02 +0000

Foreword

There is a small side project I've been working on – relaying raw RTSP streams into HLS. Essentially, the goal is simple: allow any ordinary user to view the feed from their cameras without using proprietary cloud software from the camera manufacturer. First, that costs a lot of money, as many clients want to store camera recordings for quite a long time. Second, almost all camera manufacturers have different software, and it's simply inconvenient to have 10 different apps and/or portals just to view it all. And third, very few offer AI integrations (which is critically important for my clients). Even if this integration exists, it is either highly specialized, proprietary again, or costs a lot of money—and sometimes all of these combined. The solution is to use raw RTSP streams; 90% of all cameras on the market support and provide them.

So, the setup was quite simple: a few cameras, a simple backend, and we serve the video via HLS on a single resource for clients, using the hls.js player. Everyone was happy with it, everyone liked it. Fast, simple, convenient, and cheap. Tests worked perfectly, clients were satisfied. There was a chat with each client where the viewing link was shared, as well as a general chat with all clients where connection issues, financials, and other things were discussed. And then the moment of truth arrived: someone mistakenly dropped a link into the general chat... and that was the end. Apparently, the entire chat clicked on the link. 3 minutes in, alerts started flying in the bot: alarm, achtung, panic. We check the hardware: the server is down, OOM, all streams dropped. 20 minutes later, the chat was exploding with angry messages about nothing working for anyone. Curtain drop.

Welcome to the Thundering Herd problem.

If any of you have tried serving live video, you definitely know this problem. When hundreds or even thousands of viewers try to watch the same stream, a standard server's logic is simple – open a new connection or spawn a separate process for each viewer. Generally, the result of this action is always the same – OOM, and the processor is dead.
The simplest way to solve this would have been renting a more powerful cloud instance or buying new hardware. There's a saying that "if a problem can be solved with money, it's not a problem," but there was no money. Plus, we are engineers; consider it a challenge thrown at your professionalism. The idea emerged to write our own engine in GO. It’s cheap, and you can squeeze out maximum performance. And honestly, your own thing in GO – it's cool, trendy, and hip. The spoiler won't be long: in the end, we squeezed out 8.8 Gbps on a single CPU core, while the garbage collector was basically taking a vacation during all this.

Here’s how Ruseon Core was put together.

Why not the great and mighty FFmpeg?

Let’s be honest, FFmpeg is an "axiom" in the world of any video processing. It's awesome, truly. Essentially, it's the standard for ages. But my god, does it love to "eat." Launching even a hundred FFmpeg processes for restreaming is equivalent to suicide. We specifically want to get away from the same problems it has. Even if you use it as an ingest proxy, the overhead will zero out all the benefits.
While searching for a solution, MediaMTX came up. It’s a gorgeous project and essentially solves our "main" problem. But (I think "but" is becoming my favorite word, hehe), we need seamless integration with the AI pipeline, as well as archive recording. Out of the box, it doesn't have this, and writing plugins or wrappers takes a long time. Plus, what's the point if we already decided to solve the problem conceptually? Besides, "showing off" to clients that we only use our own proprietary development is a sweet deal. It also adds weight in the eyes of other engineers and companies.
So we wrote an engine from scratch, while trying to keep it "modular." That means the ability to embed it or use it as an SDK. The main rule during development – absolutely no transcoding (we just move bytes around), minimum overhead, maximum performance.

The main feature: Zero-Copy RingBuffer

When a new frame arrives from the camera (usually it's H.264, though we implemented the 265 codec too), it’s just another chunk of bytes.
Imagine this "brilliant" idea: we distribute this chunk to thousands of viewers by copying the bytes into separate response buffers. Pictured it, right? In the world of GO – that's a path to success (sarcasm). The garbage collector will be absolutely thrilled, trying somehow to deal with a mountain of trash. The CPU, instead of streaming, will be entirely busy cleaning up.
We decided to go a different route. We made a Zero-Copy RingBuffer and attached a sync.Pool to it.

How it works in theory:
A frame arrives from the camera.
We take an empty byte buffer from a pre-allocated pool.
We write the frame into it (just once!).
We hand out a pointer to this buffer to a thousand viewers.
When everyone has read it — we return the buffer back to the pool.

No allocations. No garbage collection pauses. 250 MB of RAM, 1-2% CPU load at 100 streams.

In benchmarks, it looks like this:

BenchmarkWriteFrame-12 13.9 ns/op 0 B/op 0 allocs/op

Here you can experience a true engineering "orgasm." When streaming video, seeing zero data volume per operation. When the processor is grinding out tens of thousands of frames, and the heap remains as minimal as it was.

Tests and load testing, where would we be without them?

I'm telling you all about how this was implemented, but we all love numbers (especially the numbers in a bank account). Writing fast code is cool, but you need to understand how it works in reality and where its limit is. For testing, we chose k6 by Grafana; it allows us to emulate exactly the problem that started this whole project.
Test scenario: 1000 users hammering our muxer, constantly downloading the playlist (index.m3u8), and snatching megabyte-sized .ts chunks as fast as the server allows.
There were thoughts that the "bottleneck" would start at 300 users... but thankfully I was wrong.

70 seconds of testing on a single core of a workstation Ryzen 5600x:

data_received..................: 81 GB  1.1 GB/s
http_req_failed................: 0.00%  ✓ 0 ✗ 60822
http_req_duration..............: avg=3.13ms p(95)=6.13ms

That is 8.8 Gbps of throughput (Carl!). 60 thousand successful HTTP responses. Not a single dropped connection.
Big numbers, looks nice, but what’s the catch? It’s simple here, the HLS segments are just sitting in RAM. When a massive request for a segment occurs, the server simply serves the exact same bytes from the cache. That’s it. The disk is resting, there's no repackaging, the processor is ordering a whiskey and cola.

Nuances

The question of infinite buffer accumulation arises, but there won't be infinite buffer accumulation (and subsequent OOM), as some protection against this is implemented:
The base Go network stack (net/http), which essentially operates at the delivery level. The server just hands a static chunk of memory to the socket. That's it. Whether it downloads fast or slow - it doesn't matter.

But at the core level (Ring.go), the protection implementation is more interesting - inside the core, subscribers (HLS Muxer or AI workers) read frames through channels in Go. Writing to the channel is implemented as a non-blocking send (via select + default). The channel has a strictly defined depth. If a subscriber lags, its channel gets clogged, the core doesn't wait for it and doesn't allocate new memory. Here the default branch kicks in - the frame is dropped for that specific subscriber. Here, unfortunately, you have to "sacrifice" a bad client for the sake of, say, 1000 "good" ones.
There's also the common problem of resynchronization and lag, which is solved as follows. If a subscriber inside the core drops a frame due to lagging, they cannot be given the next P-frame, because the picture will fall apart (by the way, this is even mentioned in gortsplib, the RTSP library used in the project). In this case, the core sets the NeedsIFrame flag to true for them. The subscriber stays silent until the next I-frame (keyframe) arrives; from there, reading resumes cleanly and with minimal losses. In real-world operation, this takes milliseconds and is essentially unnoticeable to the end viewer. Especially since the muxer keeps a "sliding window" of the last 5 segments in memory. If the end viewer has a really bad connection, when trying to download an outdated segment, they will get a 404. The player on the client (in 99% of cases, the player users have is hls.js or its implementations) catches the 404, realizes it has fallen behind the live feed, and jumps to the current segment, synchronizing with the rest.

And an important point: the HLS protocol is a PULL implementation. This means that an infinite accumulation of lag will not happen. That happens when the server tries to shove data into a socket, the socket gets blocked due to the client's poor network, packets pile up in the queue, and when the network "clears its throat," the client starts watching a video from 10 minutes ago. The mechanics here are different:
The muxer keeps a sliding window (Live Playlist) in memory — for example, only the last 5 segments (let's say, 10 seconds of video). Older segments are deleted forever.
A client with a terrible connection pulls segment 100 for more than 3 minutes.
Downloaded it, the player asks for the next segment, #101.
But the freshest on the server is 200. Segment 101 is physically no longer in memory.
The server serves an honest 404.
The player catches the 404, downloads a fresh index.m3u8, sees that the current segment is already 200, and jumps to the Live edge.

A client with a bad network will simply see constant "jumps" forward and buffering (which is logical with a dead network), but they will not force our server to store a personal 10-minute cache for them.

Why is this not a perfect mechanism?

In this implementation, your CPU is essentially chilling, load is at 1-2%. But at the same time, the load on the network will be colossal. Based on tests, 9 Gbps is basically the limit of a 10 Gigabit interface. The code will hold up, but the network card will start dropping packets. Physics has its limits. Also, don't forget that when we write about 0 B/op and 250 MB of RAM consumption for 100 streams, this refers only to userspace memory (the heap), the one the garbage collector is responsible for. Socket buffers aren't going anywhere. Hundreds or thousands of connections will eat up their rightful megabytes of memory for tcp_mem. This rather describes that the problem doesn't multiply at the software level, i.e., we are not allocating gigabytes of structures inside GO. You have to understand that OS memory is an unavoidable tax on networking.
The trickiest part is not messing up the sync.Pool implementation. Otherwise, your picture will just fall apart, and some frames will simply be green. All because another thread is already writing new bytes in there.
In short, the point of this article is that if you don't need transcoding, or you need minimal hardware load – then you shouldn't use heavy artillery like FFmpeg and the like. Control your memory. Move bytes around without copying.
The source code and load testing scripts are located in the Ruseon Core repository in the benchmarks/ folder. Go ahead and try to crash your computer (I've killed mine more than once).

Source code: https://github.com/RUSEGAL/ruseon-core