Closed MicheleCardamone closed 5 months ago
Let's make this minimal. Can you try with one camera on the stream = subStream
with idle_disconnect = false
Also do you have any more in depth error logs from BI? Your neolink log just says. Connection fine, going into idle, camera disconnected from idle. Maybe BI dosen't like the idle camera state since it dosent send proper camera frames. Does it work with any other clients like VLC or ffmpeg?
@QuantumEntangledAndy HI. I carried out many tests, starting from your suggestion with a single cam 1) tried only substream with the settings listed above, result: RTSP 404 not found but the stream is visible in BI. 2) tried both streams, result: substream working, mainstream also appears working but a gray screen appears 3) tried only mainstream, result: only gray screen I'll attach some photos to you. The error mentioned in yellow (warn) always seems to appear and rarely even a Gstreamer error.
@QuantumEntangledAndy Tested with VLC: Both Main and SUB seem to work, but I notice that the SUB is very slow in terms of fps, but it works. So there's something BI doesn't like
If it is BI this will be very difficult for me to debug, since I own neither BI or a windows machine. I noticed you have some h264 cameras and some h265 camera do you know if you did your tests on the h265 one?
Also does it make any difference in BI if you select rtsp://
instead of http://
in the protocol dropdown box in the top left
I tried using http://
in ffmpeg but got a 500 error
If it is BI this will be very difficult for me to debug, since I own neither BI or a windows machine. I noticed you have some h264 cameras and some h265 camera do you know if you did your tests on the h265 one?
The h264 cams are other non-reolink cams, the reolink cams are all B800, and there is no setting (at least I think) to set them to h264 or 265. in BI, all reolink camera when they are running with 0.6.2 master, they are displayed with the wording “h264/h265”
Also does it make any difference in BI if you select
rtsp://
instead ofhttp://
in the protocol dropdown box in the top leftI tried using
http://
in ffmpeg but got a 500 error
@QuantumEntangledAndy I'll try it today. In fact, when I tested it with VLC http didn't work, I had to put rtsp. Regarding BI, clearly an investigation should be done on what has changed between 0.6.2 master (which works fine except memory) and the latest build. Any test you want to do I will run it, or if you prefer, we can run more in-depth tests on teamviewer or any other base
What I'm wondering if it might be the skip frame insertion. It was found that frigate would cause issues during a pause when no data was being sent. So I tried to mitigate this by inserting a skip frame (just repeating an IFrame). Perhaps the gray frame come from h265 skip frames not working in the same way that h264 do so that's why I asked.
The Reolink sets the camera format to h265 based on the resolution over a certain size it uses h265 below it it uses h264.
Also does it make any difference in BI if you select
rtsp://
instead ofhttp://
in the protocol dropdown box in the top leftI tried using
http://
in ffmpeg but got a 500 error@QuantumEntangledAndy I'll try it today. In fact, when I tested it with VLC http didn't work, I had to put rtsp. Regarding BI, clearly an investigation should be done on what has changed between 0.6.2 master (which works fine except memory) and the latest build. Any test you want to do I will run it, or if you prefer, we can run more in-depth tests on teamviewer or any other base
If you want to do an actual meeting. We'd need a full dev setup on your machine since it won't be reasonable to build on GitHub and wait that way. We would want to build and run during the meeting. How is your coding, do you have any experience setting up things like rustup and cloning with git if not it might be more effort then it's worth.
This is a build without the keyframe repeats. Maybe that is what gives you the gray stream
This is a build without the keyframe repeats. Maybe that is what gives you the gray stream
Well. I will carry out the tests as soon as possible and will let you know Mc
This is a build without the keyframe repeats. Maybe that is what gives you the gray stream
tried this build. I set RTSP to BI but the gray screen problem is still there
Can you find any decoder logs from BI? Maybe in the same folder as BI it might help to know what it dislikes during the deciding
Can you find any decoder logs from BI? Maybe in the same folder as BI it might help to know what it dislikes during the deciding
@QuantumEntangledAndy
There is a general log, I don't think there is a decoder log.
I see well if you see anything interesting in that log please let me know.
I'm considering possible sources of change. Since you say the repeat IFrame dosent effect the gray screen I'll enable the repeat again because it does seem to help with frigate disconnects during pause.
The next bit I want to check is how the initial buffer is filled. I slowed down the initial buffer rather than dumping the whole thing in the stream, which helps with keeping things on time. But I can try disabling that.
I see well if you see anything interesting in that log please let me know.
I'm considering possible sources of change. Since you say the repeat IFrame dosent effect the gray screen I'll enable the repeat again because it does seem to help with frigate disconnects during pause.
The next bit I want to check is how the initial buffer is filled. I slowed down the initial buffer rather than dumping the whole thing in the stream, which helps with keeping things on time. But I can try disabling that.
@QuantumEntangledAndy
I tried to do some research but there doesn't seem to be anything about a decoder log. Maybe the step to try to understand what creates the problem is to compare the changes between 0.6.2 master that works (except memory) with the build you entered here.
@QuantumEntangledAndy
Hi, as far as it may be relevant, I noticed that with 0.6.2 master after several hours of operation the sub and mainstream are not synchronized, there seems to be a difference of about 30 seconds
Anything in the debug log about push notifications? I need to know if this is an error in my part or the upstream fcm listener
Anything in the debug log about push notifications? I need to know if this is an error in my part or the upstream fcm listener
Hi! @QuantumEntangledAndy
sorry for the delay. I'm sending you 2 logs, one of the 0.6.2 master, the other of the test build. The fcm error seems not to be mentioned in the log, but in the cmd it is. It also seems that the master log is much
neolink 0.6.2 master.log
longer and richer in content than the test log
neolink build test.log
Hi! @QuantumEntangledAndy Any update?
@QuantumEntangledAndy
HI! I tried 0.6.3 and the problem still seems to be there. The only thing I noticed is that by enabling only 2 cams both a main stream and sub seem to work. By enabling more than 2 they work badly and intermittently, sometimes yes, sometimes no. can you help me? Thank you!
Edit: @QuantumEntangledAndy I have used different instances of neolink with different rtsp ports. each with 2 cams, the mainstream seems to present disturbance with gray screen
Yes your issue is why it is a release candidate and not a full release, wanted to get the features and bug fixes in for those that can use them.
A gray stream suggests that the video feed is corrupted, like your only receiving some of the frames and not all of them. The frames in h264/5 are done with differences most of the time so if you skip frames it become corrupted.
I have a few methods to prevent receieving delta frames without the full frames references from the camera so perhaps this is happening at the gstreamer level.
I am currently working on making gstreamer use a shared stream for all the rtsp connections and if that works I think I'll try bumping up the buffer size
From your logs your buffer size is currently about 11MB which i would hope should already be enough. So this as always might take a while to address.
Any chance I could get some more direct access to the camera?
There's no skip frame in the current rc build so at least it is not that. I just tried looking for places where the buffer might be dropping but cannot see any thing obvious. Theres one place that might cause it but only for the first few frames after a full buffer
Could also be that we are getting frames out of order from the camera for some reason, or something to do with the time stamps on the camera.
This build has frame reordering and some changes to how the fps is done. Perhaps you could try it out
I just went through your logs again and can see that
main stream is H265
sub stream is h264
This might explain why I cannot replicate as all of my cameras are H264, and explain why the issue is on the main stream
This build has frame reordering and some changes to how the fps is done. Perhaps you could try it out
Hi! I'll try this build and let you know. The other thing that seems strange to me is that using more than 2 cams the mainstream doesn't work at all, using 2 cams it works but then the gray screen appears
I just went through your logs again and can see that
main stream is H265
sub stream is h264
This might explain why I cannot replicate as all of my cameras are H264, and explain why the issue is on the main stream
Yes. It appears to be in the h264/h265 log. But I don't know how to change the parameter since the B800 can only be used through NVR. In the NVR parameters there is no setting regarding h264/h265
From what other people have reported Reolink makes there cameras use h265 is the resolution is > 2560x1440
If resolution is set greater then this it's h265
If less than this it is h264
From what other people have reported Reolink makes there cameras use h265 is the resolution is > 2560x1440
If resolution is set greater then this it's h265
If less than this it is h264
This build has frame reordering and some changes to how the fps is done. Perhaps you could try it out
tried this build. Same problem, nothing works. Every now and then it seems to hook up to some streams but nothing special. The only version I am able to run for now is 0.5.11 (with frequent no signals) and 0.6.2 with memory problems
I also noticed that every time I start neolink bi it crashes, and initially always displays the writing stream not ready. Then I restart but nothing works anyway. @QuantumEntangledAndy
I'll ask again then. Any chance I can get more direct access to the camera? I don't think I can solve this without proper analysis
I'll ask again then. Any chance I can get more direct access to the camera? I don't think I can solve this without proper analysis
How do I give you access to the cams remotely? we can arrange a meeting on teamviewer if that's okay with you
Contact me via email then and we can arrange from there
Hey how is it going, sorry for disappearing for so long life things happened. I may have found the source of the issue (some of the video frame packets were not deseralising on the newer encryption format correctly). Hopefully it is fixed in latest. If you can replicate on the master branch please let me know, otherwise I will close this
HI! Tested the latest build mentioned in the closed topic regarding memory. With this version BI fails to capture any stream. neolink.log
bind = "0.0.0.0"
[[cameras]] name = "cam1" username = "admin" address = "192.168.3.30:9000" stream = "both" use_splash = false