Is the Nx Cloud up? Visit our Status Page for the current health and performance of the Nx Cloud.

Status Page

Memory leak when using HLS streams

Completed
Andy Knuts

Hello,

We recently started using HLS streams to make some streams available in browsers. This works perfectly fine in terms of functionality, but since enabling HLS, our NX Witness server has started crashing every 2–3 days. Previously, the server was extremely stable and never crashed, ever.

We've noticed that when using HLS streams, the server’s memory usage increases steadily over time. It starts off low, but every hour the memory consumption goes up, eventually causing the Linux system to use swap space. If we don't manually restart the server, the whole system becomes unresponsive.

As a test, we disabled all HLS streams for a week, and during that period everything remained stable—so the problem seems directly related to HLS usage. When testing manually, we also see the memory consumption rising while we start/stop HLS streams repeatedly.

Could you please investigate this issue? At the moment, our system is unstable and we are forced to restart the server regularly.

Thanks in advance for your help!

Best regards, Andy

0

Comments

4 comments

Date Votes
  • Norman
    • Network Optix team

    Hi Andy Knuts,

    Using the HLS method can sometimes lead to issues due to differences in stream formatting.

    Historically, up to and including version 4.2, the system provided a primarily procedural-style API, with endpoints beginning with /api/, /ec2/, and older media formats. These are now referred to as the "LEGACY & BETA" API. This includes experimental functions that may contain known issues and are not considered production-ready. Use of these legacy and Beta APIs are at the developer’s own risk.

    Starting with version 5.0, a new RESTful-style (CRUD) API was introduced, featuring endpoints under /rest/. This is now the recommended and supported approach, offering greater consistency and reliability. In the API function tree, both the legacy and REST APIs are labeled with their respective names as section headers.

    For your use case -streaming over HTTPS - you should use the GET /rest/v3/devices/{id}/media endpoint.

    Here’s the general format of the request URL:

    https://<serverIp>:7001/rest/v3/devices/<cameraId>/media

    For example: 

    https://81.64.212.148:7001/rest/v3/devices/27eaf5e3-a709-0d29-681a-f01fac2b6503/media

    You can find more information and details in the API documentation.

    With kind regards.

    0
  • Andy Knuts

    Thanks for your response!

    We decided to use HLS because it was the only method that allowed us to start streaming instantly in the browser. With HLS, the video starts playing almost immediately after clicking a button, which is exactly the experience we’re looking for.

    From your reply, I understand that you recommend using the new REST API, but as far as I can see, this API doesn’t provide HLS streams—only MP4, MJPEG, etc. Unfortunately, in our experience, these formats don’t load as quickly in the browser as HLS does.

    So my question is:
    What are the current options for achieving truly fast (near-instant) playback in the browser, comparable to what we see with HLS?
    Is there a recommended way to get this low-latency, fast-start streaming experience—ideally in a stable way and officially supported by NX Witness?

    Thanks again for your help!

    0
  • Andy Knuts

    Today, we tested WebRTC functionality and found that, while it works flawlessly in Chrome, we’re experiencing issues in Safari on both macOS and iOS. Specifically, Safari appears to reject the H264 offer and instead falls back to VP8 (transcoding), which is not the desired behavior for our setup.

    Is there a way to force NX Witness to use H264 with WebRTC? Or is this a known limitation with Safari? For context: our streams are encoded in H264 and have a resolution of 4000x3000.

    0
  • Norman
    • Network Optix team

    Hi Andy Knuts, 

    WebRTC would be the fastest solution, and the one I would have suggested. 

    Safari (or Apple OS in general) tend to be less flexible when it concern large resolutions (larger than the screen resolution. So my first check would be to use `resolutionWhenTranscoding` and reduce the resolution to 1920 x 1080 and check if this resolves the issue, otherwise, please submit your request in our Developer forum, so our team there might give your some guidance, since this is beyond my knowledge. 

    With kind regards. 

    0

Post is closed for comments.

Didn't find what you were looking for?

New post