Camera's timestamp and BI timestamp don't match and progressively diverge

[IAmATeaf]

Have you tried setting the fps for the substream to be the same as the main stream to see if that helps?

[adam7456]

Here is my latest response from Reolink.



This is Ian from the Reolink Senior Support Team.

I have reported this issue to our R&D team, and we will carefully analyze the information you've provided. We'll strive to provide you with an update as soon as possible.

Thank you for your patience.

[Pogo]

I hope to do a few configuration variation experiments with my 811 over the next day or so -- both in the Reolink app and Blue Iris. I tried a couple variations in Blue Iris yesterday to try breaking the stream but it hung on and refused to die or even stutter. How well it was streaming in real time was impossible to determine due to it being pointed at a relatively static nature scene and no comparison camera available. That will be changed to a side-by-side driveway shot alongside another camera and a couple others that will all see traffic simultaneously -- or should -- today.

An important aspect to making configuration changes to the camera software is to ensure a reboot afterwards and make any necessary changes in the Blue Iris config to reflect what was done in the Reolink software..., primarily frame rate and encoding info..., not to mention hardware acceleration considerations. But to the latter, I'm only running a 4th gen i7 which doesn't even recognize H265 yet with QuickSync and hands it off to the CPU..., and it still works. Regardless, Blue Iris is not going to automatically adjust itself to optimize Reolink specific software changes even though it may reflect them in the status window. Manually ensuring they match is the best way to give both a chance to be implemented successfully and hopefully with the desired results.

My money is on an H265 encoding mismatch that neither the Blue Iris team or Reolink haven't been wiiling to bend on, especially the Blue Iris development team. Reolink is at least attempting to accomodate the matter even though their approach works fine (in my experience) with the VLC platform, Amcrest and others..., even tinyCam Pro.

Anyway, I'll report on anything significant using the firmware at my disposal. One thing I am certain about, there is a lot of downright bad and inaccurate information out there on the general Reolink/BI subject that needs to be put to rest.

If I can make a RLC-811A work like it should, anyone can..., and it's getting backhauled to my LAN over a wi-fi bridge.

[TimG]

Such enthusiasm. You will never be bored with Reolink cameras

[Pogo]

Re-aiming the 811A to the same basic view as an adjacent 5MP camera sharing the same POE switch and bridge to my LAN yielded the results I expected. Perfect sync as observed after 12 hours of continuous operation of the 811A with the beta firmware and the basic ONVIF config in Blue Iris. Nothing fancy or any RTMP workaround stuff. Default generic main stream profile - presumably h265 since that's all there is for the 811A main. BI indicates its typical HW mismatch, most likely due to the h265 main not being recognized by QuickSync given my i7 4790. Sub stream profile is default h264.

Came config was full 4K resolution / 20fps / 4096 CBR / I-frame interval 2 seconds for main. 640x360 at 10fps / 256 CBR / I-frame interval 4 seconds for sub.

Played around with some settings today with nothing conclusive since the camera was rebooted a few times and every change made in BI obviously restarted the camera which also restarts its phantom 'time clock' for either staying in sync or lagging behind over time.

Left the BI config as basic ONVIF with conventional RTSP/Media ports and changed the I-frame interval to I second in the Reolink configs this evening along with de-activating the RTMP port just to scale it all back a hair and to eliminate any port confusion that may be inherent with the BI Reolink defaults. Set both NTP servers for windows sync and added OSD time to both camera configurations but left Blue Iris time stamp absent from the streams since it will be on any clips to check sync with the cams anyway. Should provide a fairly accurate sync comparison, though a squirrel running around in perfect sync with itself this morning was also a great way to verify it!

Will let things cruise overnight and see what we have in the morning. If all holds together as I anticipate it will, the BI Reolink Find/Inspect approach will be next to see where that takes us.

[adam7456]

Reolink is at least attempting to accomodate the matter even though their approach works fine (in my experience) with the VLC platform, Amcrest and others..., even tinyCam Pro.

Their support team has had me run some tests using VLC and checking the preference for Input/Codec to use RTP over RTSP. When I did that the VLC stream was within 1-3 seconds of real time which I consider fine. The delay never expanded even after multiple hours of running. BI5 instantly showed an old time and the time delay grew.

I would have to agree that something in H265 compression isn't right. The Reolink 410, 520, and 522 cameras I have connected to BI5 all work fine but they are using H264.

[Pogo]

Another 22 hours of RLC-811A sync. No drops. No stutter. No issues. It actually stayed ahead of the companion comparison camera by about 3 seconds from start to finish during the entire testing period. I added the BI overlays earlier this morning for additional comparisons today. There will likely be a difference due to the wi-fi aspect, but it should be consistent depending on the respective time server sync cycles among all the devices involved. I intend to address that (to the extent possible) as well this afternoon.

BI Sync.jpg (205.41 KiB) Viewed 61060 times

This is what I've been running for the current tests as entered manually. Find/Inspect based purely on the generic/ONVIF selection returns the same config minus the substream entry which is available as a selection. PTZ is also discovered. I intend to revisit the configuration obtained from the BI Reolink selection I've used in the past to see what that yields. It specifically uses ports 1935 for RTMP and 8000 for Discovery/Onvif, (though I always reverted to 554 to use RTSP instead anyway). This is what is working now with no issues.

Reo Generic.jpg (125.47 KiB) Viewed 61060 times

[adam7456]

So you are only pulling the low bitrate H264 stream? The problem is seen with their H265 compression. All the other Reolink cameras I run are older and only have h264 streams which work fine.

[adam7456]

Got my first BS response from Reolink which is very disappointing. They are trying to wash their hands of the problem claiming "it must be a bandwidth issue on you end". Apparently the camera connected to 30ftof cat6, into a gigabit switch, which is connected to by BI5 machine by 20ft of cat6 is overwhelming the network and computer. That is a sad and pathetic response from Reolink. Not to mention I just connected another Reolink 411 to the BI5 machine today and it is running with no time problem. If there was a bandwidth issue everything should have gone haywire by adding another camera. Then there is the fact that I ran a test where I disabled all the other cameras in BI5 except for the 811A and it continued to have the problem.

That problem is in the H265 compression. Either Reolink did something funky or BI5 has done something. Given that VLC can play the H265 stream of the camera with no time delay issues, that points to BI5 having the problem.

[TimG]

That problem is in the H265 compression. Either Reolink did something funky or BI5 has done something. Given that VLC can play the H265 stream of the camera with no time delay issues, that points to BI5 having the problem.

There are a lot of threads on the internet regarding Reolink cameras having problems with various other software NVR's. Since my chosen Dahua cameras just work, I am thinking that the Reolink hardware and firmware isn't quite as compliant to the same standards that Dahua are. Reolink are a budget camera so maybe design compromises are made - could it be that simple ?