Posts made by joseph_1979

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.