Murlet - Blog

Murlet now finds your cameras via ONVIF

2026-09-14T00:00:00+00:00

Murlet, my macOS network video recorder (NVR), used to require you to supply a cryptic RTSP string for each camera:</p>

rtsp://user:pass@192.168.0.125:554/cam/realmonitor?channel=1&subtype=0</span></span></code></pre>
How do you even construct one of these?  Well, you need three pieces of
information.  Firstly, you find your camera's IP address, likely by logging into
your router and browsing the list of devices, looking for something
camera-shaped.  Secondly, you probably Google for your camera model's RTSP URL.
Finally, you try to find the post-it note where you wrote down your camera's
password six months ago.</p>
Good news and bad news: I can't help you find your password, but everything
else</em> is now automated.  During onboarding (and later, from camera settings) we
show you a list of discovered cameras:</p>
</p>
Clicking any of the "Add" buttons brings up the password dialog.  Once you've
added a camera, you can see its status (e.g. "Online").  We even attempt to
check whether your password is valid before adding the camera.</p>
How ONVIF discovery works</h2>
Behind the scenes, this is all driven by ONVIF.  Which stands for Open Network
Video Interface Forum, obviously.  We blast out a
WS-Discovery</a>
Probe</code> (SOAP, remember it?) to the multicast group at 239.255.255.250:3702</code>,
and wait for any cameras to respond.  This provides the list of cameras that you
see in the screenshot above.  Then, once you've added a camera with a password,
we ask the camera for its RTSP address via GetStreamUri</code>.</p>
Easy, right?  Not exactly.  IP cameras are a swamp</em> of partially implemented,
non-compliant ONVIF stacks.  And people connect to them in creative ways.  Most
of the quirks below tripped me up on my own cameras (and I flag the speculative
fixes).</p>
Probing every network interface</h3>
If we don't specify an interface when sending the multicast WS-Discovery
message, it goes out on whichever one the OS picks as the default.  Most of the
time this finds your cameras, but if you have multiple interfaces (e.g. Wi-Fi
for regular traffic, and an isolated wired network for cameras) then it may
mysteriously show no devices.</p>
We address this problem by enumerating the machine's interfaces via
getifaddrs</a>,
and sending discovery messages out on each.  We intentionally skip
point-to-point interfaces to avoid adding cameras that are only reachable when a
VPN is up.</p>
Anchoring to the camera's clock</h3>
If you've ever had a camera reject credentials you know</em> are correct, returning
an ONVIF ter:NotAuthorized</code> or a WS-Security wsse:FailedAuthentication</code> error,
a clock mismatch might be to blame.  Every authenticated request we send carries
a
WS-Security digest</a>,
which is computed as</p>
base64(sha1(nonce + created + password))</span></span></code></pre>
where nonce</code> is the usual number-used-once, and created</code> is a timestamp.  Both
are also sent in the clear so that the camera can recompute the digest.</p>
The camera will reject the message if the timestamp is too far from what it
considers to be the current time, which could be absolutely anything</em> (two of
my cameras currently believe it's 2018... I don't have the heart to tell them).
So we first send a GetSystemDateAndTime</code> message to learn what the camera
thinks the current time is; this is one of the few calls that ONVIF requires to
work without</em> authentication.  We then anchor all subsequent timestamps to that
value by storing the clock delta.</p>
Cameras that lie about their address</h3>
When a camera answers our Probe</code>, its ProbeMatch</code> contains an XAddrs</code> field:
a whitespace-separated list of URLs for its ONVIF device service, e.g.</p>
http://192.168.0.125/onvif/device_service</span></span>
http://[fe80::2e0:4cff:fe12:3456]/onvif/device_service</span></span></code></pre>
We need to connect to one of these to ask the camera anything further.  The
problem is that we're trusting the camera to know its own address</em>.  It might
be stale if the camera has recently acquired a new address from DHCP, or maybe
it's the factory-baked default if the camera is truly demonic.  (All of
mine tell the truth, for what n=7 is worth.)</p>
The fix is to... not trust the camera.  We pick the first http</code> URL (skipping
https</code>, which we don't speak), and substitute the IPv4 address that the
datagram arrived from, keeping the port and path.  My assumption is that if the
camera is reachable at all, it's at the address it just answered from.</p>
This would of course break a camera that is only reachable at the address it
advertises (e.g. behind a proxy).  My hope is that these cases are sufficiently
rare that the rewriting approach leads to fewer connection failures overall.</p>
Not locking yourself out</h3>
Some cameras lock you out if you enter the wrong credentials too many times.
For a product that records camera streams, getting you locked out of your own
cameras because you typo'd a password is Not Good.  Concretely: you typo a
password, our reconnect loop retries it every few seconds, and then the camera
starts denying all requests.  Recovery runs the gamut of sysadmin tedium, from
"wait for a bit" to "power cycle the camera" to "perform a factory reset".</p>
So when authentication fails, Murlet won't retry that password in the background
for an hour:</p>
http://192.168.0.125/onvif/device_service rejected these credentials less than 3600s ago; not retrying yet</span></span></code></pre>
An hour is long enough not to trip a lockout and short enough that a camera with
flaky auth comes back the same day.  You can retry as often as you like
yourself: the backoff only applies to Murlet's own retries.  We record when each
credential was last rejected, so a fresh password is tried immediately.</p>
Picking a media profile</h3>
ONVIF supports multiple media profiles</em>, listed by GetProfiles</code>.  These
describe the different codec and resolution options available.  We heuristically
pick the highest resolution stream which we can decode.  Why heuristics?
Firstly, cameras may use different names for the same codec e.g. "H.264" vs
"H264" vs "h264".  Secondly, some may not report an encoding at all.  We keep
them, assuming a camera that can't name its codec is probably speaking H.264.
Finally, some may not report any dimensions, so again we just keep the profile,
but rank it below any profiles that report dimensions.  None of mine do any of
this, so no camera has exercised these fallbacks.  What could possibly go wrong?</p>
If your camera doesn't speak ONVIF</h3>
Not all cameras support ONVIF (Hi Wyze</a>).  Some do,
but only once you've dug through their settings pages to enable it (Hi
Reolink</a>).  Others need their own user account,
distinct from the login that you use in the web interface or mobile app (Hi
Tapo</a>, and Reolink again).  So as a fallback we
still support manually entering an RTSP URL.</p>
What I didn't build</h2>
Building the perfect discovery system would take forever.  Here's what didn't
make the cut:</p>

Cameras that get a new address</strong>: It's not uncommon for a camera to be
assigned a new IP address by DHCP.  When this happens you have to manually
reconfigure your camera in Murlet.  In theory</em> we can automatically detect
the moved camera using ONVIF Endpoint Reference (EPR) addresses, which are
meant to be stable, globally-unique identifiers.  And, of course, some cameras
reuse them across batches, or reset on reboot, so heuristics are the order of
the day.</li>
Media profile selection</strong>: I think there's value in exposing the media
profile choice, instead of always automatically deciding it for you.  Higher
resolution streams consume more resources, and they might not always be
needed.  However, I don't want to force</em> selection of the media profile if
our heuristics usually do a good-enough job.</li>
Manual subnet scanning</strong>: Right now we do periodic multicast "pings" while
discovering cameras.  This is akin to standing in the street and shouting "is
anyone there?".  One step up from this is to perform a TCP connect sweep of
all connected networks.  This is more aggressive, and more like knocking on
front doors.  It might also trigger corporate Intrusion Detection Systems.  If
Murlet were to support this behavior, it would have to be user-initiated.</li>
Default passwords</strong>: Many cameras ship with default passwords.  We don't
surface these in the UI, instead just presenting a dialog with empty user and
password fields.  As an alternative, I can imagine shipping a database of
default credentials, and suggesting any that match the camera's manufacturer
or hardware hints in the WS-Discovery replies.  I wouldn't want to
automatically</em> try credentials because (i) this risks camera lockout, and
(ii) trying passwords until one works is no longer in the realm of "camera
setup".</li>
</ul>
Does it find your cameras?</h2>
I've tested this on the seven cameras</a> I own, but I'm
undoubtedly missing edge cases.  If you're interested in helping make Murlet
more robust,
download the latest release</a>
and let me know</a> if any of
your cameras don't show up.</p>



Proving my Rust NVR doesn't leak memory (it did)
2026-08-28T00:00:00+00:00
Murlet, my macOS network video recorder (NVR), has to be utterly reliable</em>: an
NVR typically runs unattended for weeks at a time, and someone only interacts
with it when they need to review an event.  If in that moment they discover the
NVR crashed three weeks ago... yep, that would be a deal-breaker for me too.</p>
One pernicious source of in-the-field failures is data structures that slowly
grow without bound, especially those in third-party dependencies.  These are
invisible to tools such as the macOS leaks</code> command and the Clang
LeakSanitizer</a> because the data
is still reachable.  And when this growth is sufficiently slow, it can be
invisible during end-to-end testing, only causing memory pressure after weeks or
even months of uptime.  (To keep things simple, I'm going to call this kind of
unbounded growth a memory leak</em>.)</p>
I set out to prove to myself that Murlet wasn't leaking memory, and
discovered (horror of horrors!) that it actually was</em>.
This blog post is the story of how I found and fixed it.  We'll cover:</p>

How I separated the Rust and Electron heaps so that the macOS vmmap</code> tool
reports their sizes independently.</li>
How I taught Murlet to gather and log its own versions of the memory metrics
that Activity Monitor and vmmap</code> show, so that I can graph them over time.</li>
How I used the heap</code> and malloc_history</code> tools to trace the leak to wgpu.</li>
How I fixed the underlying issue. (And to be completely fair to wgpu, the leak
only happens when repeatedly hitting an error path, and it's already gone from
wgpu's trunk.)</li>
</ul>
There's a fair amount of ground to cover here, so I'm going to gloss over some
of the implementation details.</p>
Separating the Rust and Electron heaps</h2>
As discussed in my previous blog post</a>,
Murlet comprises an Electron frontend and a Rust backend, implemented as a
native Electron plugin. Electron's Chromium core uses a
shim</a>
to divert all memory allocations to its own
PartitionAlloc</a>
allocator.  Murlet's Rust backend runs in the same address space as the Electron
frontend, and therefore by default all Rust allocations also</em> use
PartitionAlloc.</p>
This makes it hard to disentangle Rust and Electron memory footprints: the
PartitionAlloc shim routes every allocation into a single shared partition,
losing each allocation's provenance.  I could</em> have recovered it using
Chromium's
heap profiler</a>,
which logs call stacks of sampled allocations.  But that tooling is built for
one-off investigations, where you already suspect a problem. I wanted
metrics I could leave on in the field, and graph as part of a pre-release soak
test.</p>
What to do about this?  First a brief detour into
libmalloc</a>, Apple's
system allocator.  This has the built-in concept of zones</em>: buckets
which applications can direct specific allocations into. Significantly, zones
are surfaced across the standard macOS debugging tooling. vmmap</code> reports each
one separately, and heap</code> and malloc_history</code> can inspect their contents.</p>
The zone-aware API is straightforward: create and name a zone
(malloc_create_zone</code>, malloc_set_zone_name</code>), then allocate through
zone-flavored versions of malloc</code>, calloc</code>, realloc</code> and free</code>.  I replaced
Rust's global allocator with a thin layer over this API.  It creates a dedicated
murlet_rust</code> zone and routes every Rust allocation into it.  Since Chromium's
shim
only intercepts the default zone</a>,
these allocations bypass PartitionAlloc entirely. It's not magical: about 150
lines of Rust to implement std::alloc::GlobalAlloc</code>, and a similar amount of
test code.</p>
Three asides:</p>

Replacing the global allocator is a smaller change than it might sound: in an
ordinary macOS process, Rust's default System</code> allocator is already libmalloc
(malloc</code> targets the default zone), so we're just pointing the allocations at
a named zone instead.</li>
Rust's allocator API lets callers request any power-of-two alignment, but
malloc_zone_malloc</code>, like plain malloc</code>, only guarantees 16 bytes.  For
larger alignments there's malloc_zone_memalign</code>, but no aligned calloc</code> or
realloc</code>, so I fill those gaps by hand, zeroing and reallocating by copy.
Rust's own
System</code> allocator</a>
plays the same tricks.</li>
Building on libmalloc (as opposed to using a bundled allocator such as
jemalloc or mimalloc) also gives me sanitizer coverage:
AddressSanitizer</a>
interposes the malloc_zone_*</code> functions, so when I periodically run Murlet's
tests under ASan, it still checks every Rust allocation.</li>
</ul>
With the zone allocator in place, pointing vmmap</code> at a running Murlet
instance shows the Rust heap as its own row.  For leak hunting, we care about
the "BYTES ALLOCATED" figure: these are the bytes that Rust is actually
holding (its live bytes).
murlet_live555</code> is a separate zone that I added to track allocations from
live555</a>, the C++ library that Murlet uses
for RTSP.  Fragmentation ("% FRAG") is a story for another time.</p>
$ PID=`pgrep -f /Applications/Murlet.app/Contents/MacOS/Murlet`</span></span>
$ vmmap -summary $PID</span></span>
                                          VIRTUAL   RESIDENT      DIRTY    SWAPPED ALLOCATION      BYTES DIRTY+SWAP          REGION</span></span>
MALLOC ZONE                                  SIZE       SIZE       SIZE       SIZE      COUNT  ALLOCATED  FRAG SIZE  % FRAG   COUNT</span></span>
===========                               =======  =========  =========  =========  =========  =========  =========  ======  ======</span></span>
[...]</span></span>
murlet_rust_0x109f24000                     38.1M      36.1M      36.1M        96K      48294      18.3M      17.9M     50%      24</span></span>
murlet_live555_0x13b10c000                  15.0M      3376K      3376K         0K         15      15.0M         0K      0%       5</span></span></code></pre>
What about Electron's C++ heap, which also used to contain Rust's allocations?
Chromium tags PartitionAlloc's memory regions with a dedicated constant, defined
in its
PageTag enum</a>:</p>
enum class</span> PageTag</span> {</span></span>
  // ...</span></span>
  kPartitionAlloc</span> =</span> 253</span>,</span>  // PartitionAlloc, no matter the partition.</span></span>
  // ...</span></span>
};</span></span></code></pre>
And sure enough, there it is as "Memory Tag 253" further up in the same vmmap</code>
report.  The 48.0G virtual size is PartitionAlloc's up-front address-space
reservation; its actual footprint is the sum of the "DIRTY SIZE" and "SWAPPED
SIZE" columns (pages it has written to).</p>
                                VIRTUAL RESIDENT    DIRTY  SWAPPED VOLATILE   NONVOL    EMPTY   REGION</span></span>
REGION TYPE                        SIZE     SIZE     SIZE     SIZE     SIZE     SIZE     SIZE    COUNT (non-coalesced)</span></span>
===========                     ======= ========    =====  ======= ========   ======    =====  =======</span></span>
[...]</span></span>
Memory Tag 253                    48.0G   327.4M   210.4M    2592K       0K       0K       0K     5333</span></span></code></pre>
This single anonymous row is all the visibility macOS tooling has into
PartitionAlloc.  As we'll see in the rest of this post, the Rust heap's zone
is debuggable using standard tools such as heap</code> and malloc_history</code>.</p>
Graphing memory over time</h2>
Now that we can see the Rust memory footprint, wouldn't it be nice if we could
graph it over time?  If it's flat we can sleep easy, and if it's
up-and-to-the-right, well... you already know where this is going.</p>
Murlet's Rust backend uses an actor architecture built on the
ractor framework</a>.  So I just added an actor
that periodically gathers Rust memory metrics (and some others while I was
there), and then logs them as key=value</code> pairs that I can scrape and plot.</p>
I ended up gathering three kinds of metrics, giving us programmatic versions of
what Activity Monitor and vmmap</code> show:</p>

Whole-task
totals</a>,
from calling the task_info</code> syscall with the TASK_VM_INFO</code> flavor, via the
mach2</a> crate.  These
mirror Activity Monitor's numbers (memory footprint, resident size, graphics
memory etc.).</li>
Per-tag region census, from traversing the process's VM map with
mach_vm_region_recurse</code> and bucketing each region by its
VM tag</a>.
These reproduce vmmap</code>'s "REGION TYPE" table (IOSurface, CoreMedia,
Memory Tag 253, etc.).</li>
Per-zone malloc
statistics</a>,
from malloc_get_all_zones</code> and malloc_zone_statistics</code>.  These give
vmmap</code>'s "MALLOC ZONE" table, including live bytes and block counts for
murlet_rust</code>.</li>
</ul>
Here's what these metrics look like when logged (census fields are region count
/ dirty megabytes):</p>
14:03:22.394  INFO Actor: main::memory_logger: Memory census: regions_walked=30233 iosurface=188/386mb ioaccel=12255/749mb videobitstream=0/0mb cm_xpc=0/0mb cm_rpc=0/0mb cm_memorypool=29/1mb cm_readcache=0/0mb cm_crabs=0/0mb cm_regwarp=0/0mb cm_hls=0/0mb malloc=53/215mb stack=185/3mb tag253=5967/216mb tag255=11273/12mb tag0=224/6mb elapsed_ms=63     id="0.1" name="memory_logger"</span></span>
14:06:22.327  INFO Actor: main::memory_logger: Memory totals: footprint_mb=3434 footprint_peak_mb=4205 resident_mb=1195 compressed_mb=15 internal_mb=985 graphics_mb=2745 regions=30204 rust_live_mb=16 rust_blocks=43759     id="0.1" name="memory_logger"</span></span></code></pre>
Don't be alarmed by the large graphics numbers: this is the steady-state cost of
decoding nine camera streams, and these values are flat over time.</p>
Here's the murlet_rust</code> zone's live bytes over a 22-hour run:
23MB grows to 146MB, at approximately 5 MB/hour.  We have a leak.</p>
</p>
The staircase shape, with each step twice the size of the last, looks
suspiciously</em> like a vector being resized...</p>
Finding the leak</h2>
Now we need to find which code is responsible for allocating the leaking memory.
This is boringly straightforward because the Rust heap is now an ordinary malloc
zone that can be inspected by the standard macOS debugging tools.</p>
First we start Murlet with full stack logging:</p>
$ MallocStackLogging=1 /Applications/Murlet.app/Contents/MacOS/Murlet</span></span></code></pre>
Next we let Murlet run for 30 minutes or so, and then we query its heap for any
allocation of at least a megabyte.  Fortunately, there's just one such
allocation in the murlet_rust</code> zone:</p>
$ heap $PID -addresses '.*[1m+]'</span></span>
[...]</span></span>
0xc39000000: non-object in zone murlet_rust_0x10e698000 (33554432 bytes)</span></span></code></pre>
Finally, we look at the history of this particular allocation:</p>
$ malloc_history $PID 0xc39000000</span></span>
[...]</span></span>
VM_ALLOC 0xc39000000-0xc397fffff [size=8388608]:  0x1825aac1c (libsystem_pthread.dylib) thread_start | 0x1825afc58 (libsystem_pthread.dylib) _pthread_start | 0x10fae267c (libmurlet.darwin-arm64.node) _RNvNvMs0_NtNtNtCsaLOjE9VYtxK_3std3sys6thread4unixNtB7_6Thread3new12thread_start | 0x10faf4fe4 (libmurlet.darwin-arm64.node) core::ops::function::FnOnce::call_once$u7b$$u7b$vtable.shim$u7d$$u7d$::h98fcc8a0db9e9237 | 0x10faf3e84 (libmurlet.darwin-arm64.node) std::sys::backtrace::__rust_begin_short_backtrace::hc35dc129a6894fe9 | 0x10fb03c28 (libmurlet.darwin-arm64.node) tokio::runtime::task::raw::poll::hef21ccbb927eb4b6 | 0x10fb0ee84 (libmurlet.darwin-arm64.node) tokio::runtime::scheduler::multi_thread::worker::run::ha9faf2e2f32456d0 | 0x10fb11140 (libmurlet.darwin-arm64.node) tokio::runtime::scheduler::multi_thread::worker::Context::run_task::h400e179067fd5d00 | 0x10f7610a8 (libmurlet.darwin-arm64.node) tokio::runtime::task::raw::poll::h1f21488cb6e6bbdc | 0x10f80fd74 (libmurlet.darwin-arm64.node) _$LT$tracing..instrument..Instrumented$LT$T$GT$$u20$as$u20$core..future..future..Future$GT$::poll::h8adaa44ecb0203b9 | 0x10f7b6d78 (libmurlet.darwin-arm64.node) ractor::actor::ActorRuntime$LT$TActor$GT$::processing_loop::_$u7b$$u7b$closure$u7d$$u7d$::_$u7b$$u7b$closure$u7d$$u7d$::h2f3158dcd6b33215 | 0x10f9e52d0 (libmurlet.darwin-arm64.node) _$LT$pipeline..actor..CameraPipelineActor$u20$as$u20$ractor..actor..Actor$GT$::handle::_$u7b$$u7b$closure$u7d$$u7d$::h3417ee7abf4abdbc | 0x10f9fcca4 (libmurlet.darwin-arm64.node) pipeline::actor::CameraPipelineState::process_queue_inner::hfff498e19554538a | 0x10fab4de8 (libmurlet.darwin-arm64.node) rescaler::Rescaler::render::hb284f42963a71177 | 0x10fb877f4 (libmurlet.darwin-arm64.node) _$LT$wgpu..backend..wgpu_core..CoreDevice$u20$as$u20$wgpu..dispatch..DeviceInterface$GT$::create_texture::h0c9f3620d92dc43c | 0x10fc3a574 (libmurlet.darwin-arm64.node) wgpu_core::device::global::_$LT$impl$u20$wgpu_core..global..Global$GT$::device_create_texture::hfdef2afe9f48bd30 | 0x10fc8fbe4 (libmurlet.darwin-arm64.node) wgpu_core::registry::FutureId$LT$T$GT$::assign::hf59e8fec70d3212e | 0x10feb57dc (libmurlet.darwin-arm64.node) alloc::raw_vec::RawVecInner$LT$A$GT$::reserve::do_reserve_and_handle::hd4458fea1d3fcd66 | 0x10feb56f4 (libmurlet.darwin-arm64.node) alloc::raw_vec::RawVecInner$LT$A$GT$::finish_grow::hd58298a5d62e1af5 | 0x1823db6f8 (libsystem_malloc.dylib) _malloc_zone_realloc | 0x1823cbeac (libsystem_malloc.dylib) xzm_realloc | 0x1823cb458 (libsystem_malloc.dylib) _xzm_malloc_large_huge | 0x1823b4894 (libsystem_malloc.dylib) xzm_segment_group_alloc_chunk | 0x1823b6cb8 (libsystem_malloc.dylib) _xzm_segment_group_alloc_segment | 0x1823b3ab8 (libsystem_malloc.dylib) _xzm_range_group_alloc_anywhere_segment | 0x18256ba64 (libsystem_kernel.dylib) mach_vm_map</span></span></code></pre>
Cleaning this up a bit, we have the following call stack:</p>
rescaler::Rescaler::render</span></span>
└ wgpu::Device::create_texture</span></span>
  └ wgpu_core::global::Global::device_create_texture</span></span>
    └ wgpu_core::registry::FutureId::assign</span></span>
      └ alloc::raw_vec::RawVecInner::finish_grow</span></span>
        └ malloc_zone_realloc</span></span></code></pre>
Hello FutureId</code>.</p>
Fixing the leak</h2>
Some background: the FutureId</code> in our stack is a texture id in the process of
being assigned.  Texture ids come from an
id allocator</a>
that contains both a free list and a next_index</code>:</p>
pub</span>(</span>super</span>)</span> struct</span> IdentityValues</span> {</span></span>
    free</span>:</span> Vec</span><(</span>Index</span>,</span> Epoch</span>)>,</span></span>
    next_index</span>:</span> Index</span>,</span></span>
    // ...</span></span>
}</span></span></code></pre>
If the free list is empty, next_index</code> is used as the id (and then bumped).
Released ids are returned to the free list.  Each texture is then stored in a
vector indexed by its id.  This is the vector that keeps growing.</p>
The bug: Texture creation is not the allocator's only client.  wgpu v30 also
prepares an id before asking the surface for a texture.  In cases where the
acquire
fails</a>
or
returns without a texture</a>,
the prepared id is dropped without being returned to the id allocator, so it
becomes unavailable for reuse.  Murlet's presentation is driven by a
CADisplayLink</code> callback, which keeps firing even when the window is covered, so
hitting the error path just requires a covered window (!).  This causes us to
leak texture ids at the display rate (about 60 per second).</p>
Interestingly, the leaked ids themselves don't increase the size of the vector.
They drain the id allocator's free list and then keep incrementing next_index</code>,
so every successful texture creation is given an ever-higher index, and these</em>
allocations grow the vector.  This is why the malloc_history</code> stack pointed at
the (innocent!) rescaler::Rescaler::render</code>, instead of the error path.</p>
The fix (wgpu#10184</a>) is
straightforward: a Drop</code> implementation on FutureId</code> that returns the id to
the free list. On successful assign we "defuse" the Drop</code> with mem::forget</code>.
It's merged into the v30 branch, but the bug is still present in the latest
crates.io release, v30.0.1, so Murlet builds against a fork with the fix
applied.  (A refactor has already removed the bug from wgpu's trunk.)</p>
With the fix in place, the same series is flat at ~18MB over a 208-hour run (the
spikes are only transient; I still need to investigate why they're happening).</p>
</p>
Conclusion</h2>
Slow, unbounded growth in data structures, especially in third-party
dependencies, is the stuff of reliability nightmares.  Rust is not a panacea
here: nothing prevents us from continually appending to a Vec</code>. But we can see
this particular beast coming by logging memory usage and checking for a flat
line as part of our pre-release soak test. And if we build on macOS libmalloc
rather than bundling an allocator, we get powerful tooling for tracking down the
cause of any "up-and-to-the-right" lines. Murlet's Rust heap has now been flat
for over a week of continuous recording.</p>


Zero-copy wgpu rendering inside an Electron app
2026-08-18T00:00:00+00:00
Murlet, a macOS network video recorder (NVR), displays
wgpu</a>-rendered video frames straight into Electron without
them leaving GPU memory. This contributes to a great local user experience: when
a user "scrubs" within a recording, the displayed video is quickly rendered to
the screen, giving the sense the output is "locked" to the cursor position.
Nice, but how is this implemented? This blog post talks about two different
approaches: "hole punching" and Electron's sharedTexture API, and explains why I
chose hole punching.</p>
Overview</h2>
First, a brief overview of the architecture: Murlet is decomposed into an
Electron frontend and a Rust backend. The frontend is a thin React layer that is
solely responsible for rendering the UI chrome and calling into the backend. The
backend is where the business logic lives: it renders video (using wgpu),
records RTSP streams, runs object detection and owns the data model. It is
compiled into a shared library that runs within the address space of the
Electron main process, and is exposed using NAPI-RS</a>.</p>
("Why Electron?" you might ask. Yep, good question. Basically, I know how to
quickly ship with it and I think it's "good enough" for most people. That said,
I'd love to explore a native implementation, and this would actually be pretty
easy given the current architecture. More on that later.)</p>
Back to business. Let's start by surveying all of our options for displaying
video frames into Electron, including those that aren't</em> zero-copy:</p>

Loopback restreaming</strong>: serve local RTSP / WebRTC streams from the backend,
decode within Electron; requires H.264 or H.265 encode/decode round-trip.
Great for uniform local/remote viewing story, terrible for latency.</li>
GPU readback</strong>: render to bitmaps on the backend, copy to the frontend,
re-render within Electron; adds some latency, burns CPU and GPU.</li>
Hole punching</strong>: render to a native NSView peeking through a transparent
hole in Electron's contentView. Zero-copy, platform-specific, fiddly. This is
what Murlet uses.</em></li>
Electron's
sharedTexture</a>
API</strong>: this imports shared textures into Electron as VideoFrames. Zero-copy,
platform-agnostic, experimental.  Murlet does not use this, although I did
prototype it.  It provides a useful comparison to the hole punching approach.</li>
</ul>
We're going to skip discussion of the first two options (loopback restreaming
and GPU readback), and jump right to the zero-copy options: hole punching and
Electron's sharedTexture API.</p>
Hole punching</h2>
The hole punching approach stacks a native NSView (the "underlay") beneath
Electron's contentView, onto which the backend directly renders video.  We then
render a transparent div within our Electron UI so that the underlay's video can
peek through.  (Because the backend lives inside the Electron main process, it
can reach Electron's NSWindow and add the underlay.)</p>
</p>
Aside: the hole punching technique has a lot</em> of prior art. DirectDraw overlays
on Windows and the XVideo extension on X11 both used color keying, where the app
painted a specific color where it wanted video displayed.  Android's
SurfaceView</a>
docs say that its dedicated drawing surface "is behind the window holding its
SurfaceView; the SurfaceView punches a hole in its window to allow its surface
to be displayed." Browsers themselves try to render video using hardware overlay
planes, leaving a transparent hole in the main content plane for the video to
poke through.  You get the idea.</p>
The benefit of this approach is that there's very little coupling between
Electron and the underlay; we just have to arrange for the frontend to tell the
backend where the transparent div is located. This means that we don't have the
performance impact of involving Electron's rendering pipeline for every frame.
We also preserve optionality for any future native port. The flip side of the
low coupling is that we're responsible for efficiently synchronizing both the
location and the content of the transparent div with the backend.  This is... a
little nuanced.</p>
Let's start with location synchronization.  When does the location change?
Either during window resizes, or else when the user moves the separator that
sits between the video thumbnails and the video player on the search view.  If
the backend responds too slowly, then we lose the illusion that the UI is a
"single pane of glass".</p>
</p>
We tackle the problem of location synchronization by simulating</em> the frontend's
layout algorithms (CSS grid and flexbox) on the backend, which allows us to
minimize communication. Simulation sounds complicated but it's actually
straightforward because we have a very simple UI: the live view just has a
navbar at the top, and otherwise the video fills the rest of the window.  The
search view adds a (resizable) panel on the left containing video thumbnails,
and again the video fills the rest of the window.</p>
So the div's position is fully determined by a handful of edge distances. For
each edge of the transparent div, the frontend updates the backend with the
distance between the div edge and the associated window edge (e.g. for the West
edge of the div, the distance to the West edge of the window).  Call these
"insets". The backend knows the window size, so it can predict the div's
location itself.</p>
The payoff is that the insets are invariant under window resizes due to how our
UI is designed: the frontend doesn't have to update the backend during resizes
at all, and the positions of the div and the rendered video on the underlay stay
in almost perfect agreement.</p>
</p>
That said, it's not a perfect solution: the West inset does change when the user
drags the divider on the search view, and there is some noticeable jank. My
judgement is that users rarely drag the divider, and even when they do the jank
isn't terrible.  So a pretty good set of tradeoffs overall.</p>
</p>
Let's now talk about content synchronization.  Here the issue is that when the
user switches between the live and search views we do not want to be temporarily
displaying the previous view's video in the new view.  Our solution is to first
render the div as an opaque black region so that the preceding view's video is
obscured.  We then signal the backend to start rendering the new video, and then
reveal it once its pixels are "on the glass".  Of course, we can't actually know
when a frame is visible, so we use a timing fudge factor which works well.</p>
Electron's sharedTexture API</h2>
Now let's talk about the road not taken (but prototyped, so I guess we went down
the road a little bit): Electron's
sharedTexture</a> API.
The idea here is pretty cool: a platform-agnostic way of sending textures to
Electron as
VideoFrames</a>,
without doing any copying!  And once we have video frames in the DOM, we can
build much richer user experiences than permitted by hole punching, e.g.
dragging and dropping live video, or applying CSS effects such as rounded
corners.</p>
But... the devil is in the details. We can't just "fire-and-forget" textures
from the backend to the frontend, because we still need to free them on the
backend after they've been composited.  So actually we maintain a pool of
textures on the backend, handing them off to Electron for display. Electron then
communicates back to the backend when it's finished with a texture
(allReferencesReleased</code>), whereupon we return the texture to the pool, ready
for reuse.</p>
This works remarkably well during steady-state operation.  Where it falls apart
is resizes:</p>

For each resize we need to reallocate the whole pool of textures (IOSurfaces
on macOS), which is not cheap.  Meanwhile, existing in-flight textures have
all been rendered at stale sizes, so they're stretched to fit the window's new
aspect ratio.</li>
Frames are serviced in bursts because the Electron renderer's main thread is
busy laying out the page.  And allReferencesReleased</code> callbacks are either
slow or else dropped (I didn't root-cause this), causing our pool to run dry.</li>
</ul>
I ended up "fixing" this by suspending delivery of frames during window resizes.
This is not great: users want to see what their video will look like while
they're resizing</em>, instead of "oh I overshot, let's dial it back a bit, oops too
much, there we go". This expectation is reinforced by macOS itself (e.g.
QuickTime, which live-resizes with a locked aspect ratio). Finally, I wasn't
keen on building on an experimental API, especially one where a single dropped
callback can cause the pool to run dry and freeze Murlet's video.</p>
Conclusion</h2>
We looked at two approaches for zero-copy display of video frames into Electron:
hole punching and Electron's sharedTexture API. Hole punching has loose
coupling, uses standard Cocoa APIs, and with a bit of work supports live
resizing. Electron's sharedTexture API requires much more coupling, but promises
to abstract entirely over platform APIs and to make video part of the DOM. But,
at least in my prototype, it gave a very poor user experience during live
resize.  For some, this may be ok, but for me it's a deal breaker.  So Murlet
ships with hole punching, and I'm pretty happy with the tradeoffs.  This also
leaves the door open for that native port.</p>

Murlet - Blog

Murlet now finds your cameras via ONVIF

Does it find your cameras?</h2> I've tested this on the seven cameras</a> I own, but I'm undoubtedly missing edge cases. If you're interested in helping make Murlet more robust, download the latest release</a> and let me know</a> if any of your cameras don't show up.</p>

Proving my Rust NVR doesn't leak memory (it did)

Zero-copy wgpu rendering inside an Electron app

Does it find your cameras?</h2>
I've tested this on the seven cameras</a> I own, but I'm undoubtedly missing edge cases. If you're interested in helping make Murlet more robust, download the latest release</a> and let me know</a> if any of your cameras don't show up.</p>