## 4 Proposed Video Latency Measurement Technique  
The video latency measurement solution, which was developed and presented in [12], was upgraded here by adding the possibility for full encryption of the video stream data. The best available way to add security services is using hardware (FPGA)-based implementation, as the software-based implementation introduced significant delays into the video data transmission. The solution presented here can be applied to any system, which features video transfer over the Internet (or a LAN) in real-time. The proposed solution is highly portable and can be used for latency measurements of unsecure/secure video streams in any system which possesses transfer of video over IP. In addition, the proposed solution is modular and can be easily adapted to implement higher levels of security, instead of only encryption security. The proposed architecture is based on the video server component described in [12], which was upgraded with applications, which are able to run on platforms with NI Linux RTOS (real-time operating system) [47]. In addition, the modules which perform the encryption/decryption and have to be executed on the FPGA platform were also integrated into the software of [12]. The major applications were developed in LabVIEW, while video decoding was performed by a third party component called FFmpeg [48] (version 4.0 built by gcc (GNU Compiler Collection) 7.3.0). As shown in Figure 2, the architecture consists of the following nodes:  
* Timestamp Sender
* Camera Server
* Encrypt/Decrypt Applications
* Camera Client
* Latency Measurement. Timestamp sender and latency measurement applications screenshots of Figure 2 are presented in Figure 3. The latency measurement application is the starting point for running of all tests (all other applications must be in running mode before executing this application). The purpose of this application is to initiate communication with other applications, which should result in receiving the IP camera video stream. Other applications from Figure 2 serve as clients/servers for parsing the data, encrypting/decrypting the stream when necessary and for providing reference time for latency measurement (timestamp sender). The main functionalities of the latency measurement application are: decode video and measure video latency. The IP camera node in Figure 2 represents a physical device with its own firmware. The rest of the nodes represent LabVIEW applications running on either: Windows PCs, NI Linux RTOS or FPGA targets. Connections marked with LAN denote links over Gigabit Ethernet network. All nodes of Figure 2 exchange information by using UDP and TCP protocols. \begin{table}
\begin{tabular}{c c c c c c} \hline \hline
**Tool/Work** & **Network** & **Time Sync** & **Latency** & **Encryption** & **Latency [ms]** \\ \hline \multirow{4}{*}{Our previous work [12]} & Internet & Dedicated NTP & Network & N/A & 40.92 \\  & LAN & Dedicated NTP & Network & N/A & 1.52 \\  & Internet & Dedicated NTP & Video & N/A & 558.00 \\  & LAN & Dedicated NTP & Video & N/A & 488.00 \\ \hline TSN [35] & LAN & IEEE 1588-2008 & Video & N/A & \textless{}2.00 \\ Sen [43] & LAN & N/A & Network & AES, ECC & approx. \textgreater{}4.0 \\ [PERSON] [17; 23] & N/A & N/A & Video & N/A & 19.18 \\ [PERSON] [22] & N/A & N/A & Video & N/A & 40.00 \\ vDelay [20] & Internet & Generic NTP & Video & N/A & 69.00 \\ AvCloak [18] & Internet & Generic NTP & Video & N/A & 50.00 \\ VideoLat [21] & Internet & N/A & Video & N/A & N/A \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Summary of literature review techniques and results. This architecture can be used in different configurations using options of protocol type, encryption string length and encoding algorithm. In terms of protocol type, there are two possible choices: UDP and TCP. This option modifies the way video data is streamed from the IP camera to the latency measurement node. When UDP is selected, all channels (both TCP and UDP) shown in Figure 2 are used.