There is no need to, as the DEBUG logs are working and showed nothing is going wrong in the places I put that code, so nothing will be learnt by looking at the TRACE level.
@SaschaQ88 That shows it is getting a frame rate of 25 frames a second. @paglatz Yours is around 8.4 frames a second.
This was calculated by the time between the boundaries. My first thoughts are this may be a non thread safe piece of code causing a race. So does changing the FPS to a number of different values and pausing and unpausing the cameras have any effect? If the timing is changed it may change what is happening and give us a clue as to where the issue is.
Your all using Pi4 so it may be that my faster CPU does not reproduce the issue. Changing the FPS here does not allow me to reproduce any issues even at 25FPS with a single camera.
If I can reproduce it, things would move faster so we need to work out what is different. I’ll have another look tonight to see what I can do to log further into the serving out of the stream as the incoming code is working without issues.
I have exactly the same effect with my Foscam cameras. I have the OpenHAB running on Pi3B. To verify the problem, I have run the ipcamera binding on the computer in the development environment and everything is fine here. The stream is transmitted all the time without any flickering or freezing.
@matt1 Is there any need to do further debugging with your special jar-file? I could install it too an provide some trace information - or did you already get what you want?
In the meantime I duplicated my installation on a second pi. It turns out, that the flicker doesn’t happen synchronously on both machines using the same configuration, camera stream, etc… Each one flickers in its own rhythm. Seems, that systemload doesn’t have a considerable effect. In my case the machine with lower systemload did flicker more often than the other machine, but maybe this is pure coincidence.
I noticed that during night the flicker effect is noticeably lower than at daytime. During the night my camera picture is only black / white, while on daytime it has normal colours.
I did find a potential issue where if the FIFO buffer is running out of space it would cause the symptoms people are seeing. I added logging and increased the size of the FIFO in this build so it may fix/help the issue as well as log if that is the cause if it still happens.
HI @matt1
thank you, for trying to fix this problem. I tried the new jar. I think It’s better than before, but the the flickering is not totally gone.
I tried it on two different pi’s. While one the pi #1 it is nearly completely gone, on pi #2 it is reduced by maybe 70%. Both pi’s are Model 4b with 4 GB RAM, pi #1 is on Raspbian GNU/Linux 10 (buster), pi#2 on Raspbian GNU/Linux 11 (bullseye)". On pi#2 there is also a X-Window System online, this might cause additional load to the gpu, but I don’t know if the binding makes use of the gpu.
In DEBUG mode I get some of the following logs:
[DEBUG] [camera.internal.servlet.StreamOutput] - FIFO buffer has run out of space:Queue full
Not every a time a log entry is written the image is flickers, but every time the images flickers the log entry is written, sometimes two or three entries per flicker.
It will use a tiny bit more ram, not enough to mention or notice. The alternative would be to use a tiny bit more non stop CPU to detect when the start of a new jpg frame occurs to throw away a whole frame.
It would be interesting to work out why this happens on your setups and not mine. Perhaps you have plenty of network traffic, a network switch can not keep up, or your using the wifi network card on the pi4? I will have to look at the way the fifo buffer is implemented some more in depth to make sure it is streamlined as much as can be for low CPU devices. Since someone posted it did not get worse with higher system load then I suspect it is not that.
The thing I am wondering all the time is, why this did not happen on OH3.1 were it was perfectly fine.
To also give you a background info about the hardware:
I am running the pi4 with the official new PoE+ Hat, connected with Draka UC900 RJ45 Hirose TM31 Cable to a Unifi Pro PoE Switch where the INSTAR IN-9020 is also connected to. The switch has a 10GBit Uplink to a unifi dream machine pro. DNS is again a Pi 4 with Pi-hole connected in the same way. In my guess, the network components are not loaded at all.
Nevertheless, thanks again for your time, i am still very happy.
Thanks for the explanation! If i can support you further, just let me know…
One last thing: Can you drop a note in this thread here, when you publish the fix to the next stable OH Release? I would then switch back to the official version. Thanks
Hi @matt1, no the systemload hadn’t any influence to this phenomenon. I tracked the load a long time on my two different pis. My network is on 1GBit/s and I think I don’t have very much traffic in the network. Connections are routet by a switch (not a hub). I didn’t use the wifi module on any pi.
Happy new year this evening an thank you a lot for all your efforts! Let us know, if you need any support for testing or debugging further builds, if you want to do a deep dive in the fifo buffer implementation. I am very happy with the current solution!
Cheers,
Boris.
jwiseman
(Mr. Wiseman (OH 4.2 Snapshot on Pi4))
26
Where can I get this JAR so it doesn’t have to download it every time I clear my cache?
I just uploaded a newer build which needs testing. This one will keep the ipcamera.mjpeg stream running if the camera reboots or goes offline. When the camera comes back online the stream should go back to updating the picture without needing to refresh the browser.
I also fixed a bug for people that create the streams from rtsp sources.
Sorry I wont be doing that as the next stable is 6 months away. You can follow the progress at the link below yourself, after it shows up as “merged”, it will then be in the next Milestones and eventually in the Stable after that. I recommend you use Milestone builds if you tinker with openHAB at least once a month. The core is stable in all builds and it is easy to swap in and out the bindings if 1 of them has an issue as you have just seen.
