Replies: 5 comments 9 replies
-
|
@sevans466 Can you provide Flyleaf and FFmpeg versions? You could also try to use ffplay / ffmpeg directly to ensure that is not an FFmpeg issue? Next thing would be to disable audio (if any) to see if the leak comes from video or audio. A partial trace log might help. |
Beta Was this translation helpful? Give feedback.
-
|
No, there are no memory leak related issues at all. My understanding is that it's not a VRAM but a RAM issue. So if hardware accelerating is working then the leak is not with the frames but with the packets. If that's an issue with Flyleaf that might be related with the timestamps and min buffer duration. It was a leak there in the past, because of wrong timestamps it would calculate negative buffer duration so it would buffer without stopping at all. But again if that's a live stream it wouldn't have enough to buffer. This looks more like an FFmpeg issue. Logs would reveal this if it is happening. |
Beta Was this translation helpful? Give feedback.
-
|
Hi - I'm the dev on this issue. The Nuget package used is FlyleafLib.Controls.WPF 1.3.7 The stream is 'nearly' live, due to VMS quirks it's getting a feed that is about 3 seconds behind real-life, though it does more or less catch up if we use a max latency value. The issue doesn't manifest if there are less than 3 streams being consumed simultaneously; it only seems to happen if there are 4 or more views on screen at one time, though it seems to get exponentially worse the more feeds we use. Disposing the Player and reloading does seem to release the associated memory, though in a non-linear way, with the first release providing little or no benefit, and subsequent disposals recovering most (all?) unreleased memory. The problem only shows on H.265, the same setup configured using H.264 seems to be stable. Also, the parameters posted by sevans466 are only the latest in a long series of attempts to fix. Nothing I've tried seems to make much difference, for 10 cameras the totalBytes reported by VideoDemuxer doubles over a period of about 75-200 seconds and increases linearly at the same rate. (I didn't know a WPF app could manage 60GB until yesterday!) I'll have a look into FFmpeg logs, currently we don't have anything captured, but that can be fixed. Any insights greatly appreciated. |
Beta Was this translation helpful? Give feedback.
-
|
If you could ensure that is a codec specific and more than 3 inputs at the same time then this ensures that it is not a Flyleaf issue. It could be either an FFmpeg or WPF issue. Maybe you think it happens with H.265 but not with H.264 because H.264 uses hardware acceleration but H.265 does not. If that's the case disable hardware acceleration for H.264 and re-test. You could try use WinForms instead of WPF (or even WinUI 3) to see if that fixes the issue. Last thought, maybe multiple monitors are related with this issue and possible GPU/driver. I will try to reproduce it as well. (Logs logs logs 😄) |
Beta Was this translation helpful? Give feedback.
-
|
Cannot reproduce it with 4 streams (one of them HEVC 4K). I use the sample from Tests/Multiplayer. (However those were not live streams with max latency on) |
Beta Was this translation helpful? Give feedback.
-
|
thx - that's helpful - we need to dig deeper now |
Beta Was this translation helpful? Give feedback.
-
|
Hello, we got distracted by other factors, but I now have a small WPF test app with 9 image views of the same camera (I have not written/edited code in a long while!). The mem profile is below:
The trend is for the memory of the process to rise slowly for 90 seconds then climb more steeply - heading into several GB very quickly. This is the HikVision stream config:
Changing Flyleaf settings and stream settings does help/change the numbers a bit....but the key problem remains present. I do see it with only 4 cams, 9 is just quicker and more representative of our use cases. We must be doing something very wrong to consume such a vast amount of memory - any thoughts welcome. Below is the new objects we see during the rapid growth in unmanaged memory:
|
Beta Was this translation helpful? Give feedback.
-
|
p.s. if you want my terrible app, I am happy to share it with you. |
Beta Was this translation helpful? Give feedback.
-
|
As a final comment for the evening - it looks as if NO memory is being released....as 20GB is reached in < 1 hour! |
Beta Was this translation helpful? Give feedback.
-
|
I've encountered a similar growth before and it had to do with the app using integrated graphics rather than the GPU. This was on a laptop so it was a default power saving thing. |
Beta Was this translation helpful? Give feedback.
-
|
Guys, if you don't provide me enough information so I can reproduce it I can't really help. I'm not even sure if that an Audio or Video leak, if Video Acceleration has to do with that, if that's related with the OS/FFmpeg libs/GPU. |
Beta Was this translation helpful? Give feedback.
-
|
Sorry we're being slow, there's a major presentation going on tomorrow, and minds are a bit distracted.
The setup throughout was 8 video streams, running near live (~500ms latency), no audio, at 1920 x 1080. As you can see for the first part it ran sweetly, with a little bump where I added a full screen (9th) view of one of the cameras, then closed that view. 18 minutes in, all the hosts and players were recycled, and replaced with what should be an identical set, viewing the same cameras, however memory use was completely different. I recycled the set 4 more times, with similar results. The flattening off on 3 of the peaks occurred where I opened a full screen view (???!), but I have no idea why that might reduce the problem. The thought that it might be GPU related is a good one, as this problem is more severe on HP ZBooks than it is on relatively low cost NUCs though the graphics seem to be similar. I've hunted through the demuxer, decoder and rendering code for any apparent bottlenecks, but cannot find anything of interest, suggesting that it's in the FFmpeg library. If you can provide any further pointers, or suggest ways in which this might occur, I would be most happy to hear them |
Beta Was this translation helpful? Give feedback.
-
|
@RichardP-Pinnacle I would do the following test if I could reproduce it
|
Beta Was this translation helpful? Give feedback.
-
Hello, We have been using Flyleaf for a year or so for Hikvision cameras (RTSP) - and this works well for us. We have recently started using it for Avigilon streams (from Avigilon AAC) which works, but seems to:
(a) Consume a lot of memory (not so surprising given resolutions) and
(b) That memory leaks and continues to climb - either slowly or more rapidly over time to prohibitive levels (climbing from 1 or 2GB for a 4 cam display to maybe 15 or 20GB over a 24 hour period!
Below is an image from DotMemory:
This was done with 4 cams - 1 is 4K res (MPeg4) and 3 are 2500x1500 (mpeg-h)
Has anyone seen memory leaks like this and if so are there any diagnostics (or solutions?) we should turn to? It is key for us that the application is stable over time.
We have done a lot of experiments, and the unmanaged memory seems to grow at different rates - but always growing.
Any council is welcome.
Our settings are below:
var config = new Config();
config.Player.Stats = false;
config.Player.MaxLatency = TimeSpan.FromMilliseconds(maxLatency).Ticks;
config.Video.AspectRatio = isFillSpace ? AspectRatio.Fill : AspectRatio.Keep;
config.Decoder.LowDelay = true;
config.Demuxer.FormatOpt["reconnect_delay_max"] = "7";
config.Demuxer.AllowTimeouts = true;
// Attempt to rein in the huge memory use
//config.Demuxer.BufferDuration = TimeSpan.FromMilliseconds(500).Ticks;
//config.Player.MinBufferDuration = 0;
//-----------------------------------------------------------------
// Player - for this FlyleafHost
result = new Player(config);
Beta Was this translation helpful? Give feedback.
All reactions