Posts made by joseph_1979

@reolink-fiona Surely that the team has to prioritize and evaluate their implementation. This is what I do at work. But at least there is the list with the time lines and updates. Listening is not enough. Customers seek action.

Hello,

In this chat there are a lot of fantastic ideas and it would be great that these are somehow collected in a table and Reolink support give a follow up say every week. Customers wish to know what is being done on each proposed suggestion or issue. Informing customers that your suggestion will be forwarded to the engineering team is not enough. Customers have to be constantly updated. And one must give some proposed dates of implementation. Reolink engineering team has to be aggressive in implementing new functions and sorting out bugs. Other suppliers takes this seriously and sort out issues quicker. We are here not just to complain but to improve your products and support.

@reolink-fiona I opened a ticket with support and have no issue to have direct communication with him. I am an engineer too.

@philippe this is not the right place to tackle the issue. Will take it up through support. Just do the same.

@reolink-lorenz all you need is to increase the cache and once connectivity is established then transmit the packets.....but the ftp transmission rate from camera side has to be increased and not leaving at St merely 1.2Mbps.

@crimp-on_62210811129 that's the trend with most suppliers. No rigorous testing and most important to be first in the market. Time is money and support costs amd that's a burden.

@bevgaskin_499300720500895 ... Just pull it out. I suggest you to insert the SIM in your smartphone to check that you have the data service. You need to add the APN if your SIM provider doesn't provide the auto setup through an SMS.

Hi Reolink Team,

I did capture some traces at both the RLC511WA and the Client sides and noticed that the all the packets transmitted by the camera have reached the clients. You have a byte denoting the packet number. When the playback was set to low, the video preview was smooth and the sound was continuous. This means that at low resolution setting the camera was able to transmit the packets at a CBR with no packet loss or delays between packets.

Then I changed the resolution to CLEAR and despite that there were no missing packets, the video can be seen sometimes freezing and the sound chopped. This is apparent when there is movement in both live and previews. There was no issue of bandwidth at all and both the source and the target were on the same subnet. Thence the issue is at source. It could be inefficient H264 encoding (I guess software encoding is used) at high resolution or hardware issue. I also noticed that the max downloading speed for FTP is 1.2Mbps. This is low especially when you are on the same subnet.

I even changed the bit rate for 5Mbps with the recommended value of 1536kbps but didn't observe any improvements.

I checked another model, the Argus 2 and the same issue has been observed at high resolution. Appreciate if the engineering team check and get back to us with their findings.

Regards,
Joseph

@philippe France Orange I used to deal with them on transit traffic but no longer. Connectivity is right and you are using a simple switch. See if you see any transmission issue on the egress side using Wireshark. For streaming Reolink are using UDP as most suppliers do for P2P. UDP is a much faster, simpler, and efficient protocol, however, retransmission of lost data packets is only possible with TCP. In my previous reply I have asked if Reolink can change the transport on our profile and we test. Moreover it could be that the decryption and H264 decoding routines at the client side are not efficient at high speed and Reolink need to optimize it. Reolink should change the H264 to H265, something which has been implemented by the competitors for quite some time.

Nevertheless a delay if 3 to 4 seconds is expected to play the first video but subsequent videos should play immediately. The protocol is encrypted and not so easy to decrypt.

I also noticed that the Reolonk camera is sending the RTSP with DSCP DF (CS0). This is best effort. I would recommend Reolink to increase this to CS4 (higher priority). Indeed the Internet is a jungle and nobody follows the rule and so there are a number of operators which treat all traffic as best effort. For instance VOIP is assigned DSCP 46 (EF) which has the highest priority over any other traffic.

@philippe This only holds when the peer and the camera are on the same subnet. A 5M camera requires 15Mbps bandwidth and you can check it out using the Reolink client and Win task manager. I did change the network and used LTE and here I noticed that sometimes the video freezes and the soun is chopped when setting the playback at high resolution. I didn't notice any errors in transport. Perhaps not all the packets are arriving at the destination. One can check this if Reolink Administrator changes the transport from UDP to TCP and we check it out through wireshark trace. I had no issue on the UL/DL speeds as I changed the configuration from the HLR. I think that Reolink engineering team has to delve through this using distinct networks (Wifi and LTE). The application needs a lot of improvements (and stability) and they need to have rigorous testing before releasing the application to the general public. On the other hand it is not that easy too as the appl has to execute on numerous devices with different OS and configuration. Anyhow we are here to assist Reolink Team to improve their products.

BTW where your WAN connected to? ISP? And what is the UL/DL speeds?

@faasio82_480971996033257 Issue is more upload bandwidth related (camera side). If you are on the same wifi network the loading and viewing of recorded videos is very fast.