giano574

> Thank You, I've just watched a video about software encoding H265 performance and I see even with powerful Desktop CPU the performance is horrible, so there's no point going...

Looking at the code, I can see that it happens in [encoder.c:310](https://github.com/aler9/rtsp-simple-server/blob/a8d1f91646f320ea25f18563cf456e7d334c781a/internal/rpicamera/exe/encoder.c#L310) when trying to enqueue a buffer. It would be nice if rtsp-simple-server tried to recover instead of just...

I can't rule out that it's hardware related, but I can say for sure that when it happens, restarting rtsp-simple-server works as a method of recovery. My best guess is...

Example of restart of rtsp-simple-server working that happened right now: ```bash pi@picam:~/rtsp-release $ ./rtsp-simple-server [22:02:19.837038036] [3271] INFO Camera camera_manager.cpp:293 libcamera v0.0.0+3730-67300b62 [22:02:19.877092398] [3272] WARN CameraSensorProperties camera_sensor_properties.cpp:174 No static properties available...

I think this creates a memory leak. I tried running it without `exit()` and when a lot of `ioctl` errors happened, memory usage exploded.

I haven't been able to reproduce it lately, and I also don't know what to look for the the pprof reports. Do you think anything can be done in order...

Maybe I don't understand, but why does the segment grow in size when queueing fails? Should the frames that couldn't be encoded not just be ignored? And what will happen...

Ah, I see. So the actual frames that aren't encoded are just lost, but then no new IDR's are added to the segment? So non-IDR frames are dequeued and put...

If I set `hlsSegmentMaxSize` and `hlsSegmentCount` so that `hlsSegmentMaxSize * (hlsSegmentCount + 1) < available RAM - some margin` then it shouldn't be possible to exhaust the RAM, correct?

Is this something that is on the roadmap?