# Efficient Transcoding and Encryption for Live 360 CCTV System
## 4 Performance Evaluation
### Evaluation  
As shown in Figure 15, the input video bitstream had a duration of 10.03 s, and the average transcoding time for the six sessions was approximately 7.05 s. In six transcoding sessions, there were three sessions using ARIA encryption and three sessions without encryption. In sessions with  
Figure 14: Full equirectangular projection (ERP) and windowed ERP. Figure 13: The 360 video test sequences: (**a**) DrivingInCity; (**b**) Harbor; (**c**) KiteFlite; (**d**) Trolley; and (**e**) GasLamp. encryption, transcoding was approximately equivalent to non-encryption sessions, and, in Session 1, the total time was only 7.02 s. For example, for larger videos, a concatenated video from DrivingInCity test sequence was 100.3 s, and transcoding and encryption averaged only 69.04 s, as shown in Table 2. Through the transcoding and encryption of different lengths of various 360 videos, we conclude that the transcoding and encryption system could process two 4K sessions or six 1080p sessions, and only took up around 70-75% of the video duration. The average transcoding rate was 36.4 frames/s for 1080p and 33.6 frames/s for 4K resolution video. Table 3 shows that the proposed method could also transcode 2D video in real-time, and the transcoding time was approximately 60% of 2D video duration. As shown in Tables 4 and 5, a comparison between x265 and proposed transcoding was processed based on measurements of 2D and 360 video test-sequences. We used libx265 [34] with FFmpeg to verify all transcoding sessions for these test sequences. Consequently, we conclude that the proposed method \begin{table}
\begin{tabular}{l c c c} \hline \hline
**Test_Sequence** & **Video Duration (s): Transcoding Time (s)** & **Video Duration (s): Transcoding Time (s)** \\ \hline DrivingInCity\_1920 \(\times\) 1080 & 10.03 (s) 7.04 (s) & 100.3 (s):69.15 (s) \\ DrivingInCity\_3840 \(\times\) 1920 & 10.03 (s):8.92 (s) & 100.3 (s):88.36 (s) \\ GasLamp\_1920 \(\times\) 1080 & 12.00 (s):8.45 (s) & 120.0 (s):84.04 (s) \\ GasLamp\_4096 \(\times\) 2048 & 12.00 (s):9.07 (s) & 120.0 (s):90.21(s) \\ Harbor\_1920 \(\times\) 1080 & 12.00 (s):8.58 (s) & 120.0 (s):85.32 (s) \\ Harbor\_4096 \(\times\) 2048 & 12.00 (s):9.13 (s) & 120.0 (s):90.54 (s) \\ KiteFlite\_1920 \(\times\) 1080 & 12.00 (s):8.66 (s) & 120.0 (s):85.23 (s) \\ KiteFlite\_4096 \(\times\) 2048 & 12.00 (s):9.01 (s) & 120.0 (s):90.29 (s) \\ Trolley\_1920 \(\times\) 1080 & 12.00 (s):8.64 (s) & 120.0 (s):86.12 (s) \\ Trolley\_4096 \(\times\) 2048 & 12.00 (s):9.15 (s) & 120.0 (s):90.76 (s) \\ \hline \hline \end{tabular}
\end{table} 
Table 2: The 360 test sequences—common transcoding time. Figure 15: The DrivingInCity test sequence H.264/AVC to HEVC—six 1080p transcoding sessions. \begin{table}
\begin{tabular}{l c c c c} \hline \hline
**Test_Sequence** & **QP22** & **QP27** & **QP32** & **QP37** \\ \hline Basketball\_1920 \(\times\) 1080\_500 frames\_25 fps & 11.89 s & 11.964 s & 11.965 s & 11.956 s \\ Cactus\_1920 \(\times\) 1080\_500 frames\_25 fps & 11.92 s & 11.676 s & 11.529 s & 11.075 s \\ Kimono\_1920 \(\times\) 1080\_240 frames\_25 fps & 5.61 s & 5.67 s & 5.84 s & 5.76 s \\ ParkScene\_1920 \(\times\) 1080\_240 frames\_25 fps & 5.596 s & 5.643 s & 5.678 s & 5.715 s \\ \hline \hline \end{tabular}
\end{table} 
Table 3: JCT-VC 2D test sequences—common transcoding time. could speed up the transcoding by up to 195% when compared to x265. The highest achievement was 7.03 s for 360 transcoding time with a speed of 42.8 frames/s, and 2D video transcoding speed could achieve up to 42.88 frames/s. To evaluate the efficiency of ARIA encryption, we used FFprobe (a tool of FFmpeg software) and hevcbrowser software to verify output HEVC bitstreams for both HEVC only and HEVC within encryption. As shown in Figure (a)a, FFmpeg tools showed that HEVC bitstream of Session 0 was easy to parse or decode. Figure (b)b shows that output HEVC encrypted bitstream of Session 1 could not be parsed or decoded. The reason was the first NAL units were encrypted to a different format.