# Real-Time, Content-Based Communication Load Reduction in the Internet of Multimedia Things
## 3 Methodology
### System Composition
#### 3.2.5 Video Compression Algorithm  
The previous Section described the system design. This Section illustrates the flow of data in a series of steps, describing how it is processed at the sender and receiver. There are two algorithms: one running at the sender and the other at the receiver, as illustrated in Figure 4.  
Figure 3: Combination of Farnet and Rivest-Shamir-Adleman (RSA) to encrypt the data at source.  
The sender first opens a video file and starts reading frames, as shown in Figure 4. The first frame of a video sequence is sent in its original form to the receiver, so that it is kept as a reference for subsequently received data. For all subsequent frames, a frame difference is calculated, converted to grayscale format and checked for any non-zero pixel intensity values. If the number of non-zero intensities in the difference frame \(F_{D}\) exceed a given threshold, that is, a percentage of changed intensities to total frame size in number of pixels. For small frame sizes this percentage is set to 50% and for larger frames it is 10%, to avoid loss of data. In the case that \(F_{D}\) meets the given threshold, then a rectangular region containing the remaining non-zero values is extracted as \(F_{Region}\) and the co-ordinates of the starting and ending pixels are saved and sent along with this information. In Figure 4 at the sender, this is summarized as Motion detection. Otherwise, a single integer value is sent to the receiver as an indicator that no frame data will otherwise be sent. Here, a counter variable is used to maintain a record of how many times an integer is sent in place of a frame and every time the counter reaches eleven, that is, after a complete twelfth frame is forwarded. Each time, \(F_{C}\) or \(F_{Region}\) is sent, it is JPEG encoded and then encrypted. For every new frame a reference frame \(F_{R}\) is maintained, namely the previous \(F_{C}\) frame. This process continues until the end of the video sequence or stream. A detailed algorithm, including communication software primitives for a Sender is given as Algorithm 1.  
Figure 4: Processing steps at a sender and at a receiver.  
The receiver node also has its socket created and connected to a sender. Upon a video request, the receiver receives data from sender as \(F_{Recv}\) in an encrypted form. \(F_{Recv}\) is decrypted and the acquired data is checked as to whether it is a frame, a region of a frame (or ROM) or simply an integer value. After a decision is made, at this stage, the algorithm follows any of three sequences. If an integer value is received, it shows no motion is detected and results in a repetition of a previous frame at the display. On the other hand, if a frame is received, it is first decrypted and decoded as \(F_{C}\) and then displayed while the previous frame \(F_{Prev}\) is updated by the current frame \(F_{C}\). Then, if an image region is received, it is decrypted and decoded, by using the co-ordinates of the starting and ending pixel, \(F_{Prev}\) is updated and displayed. This processing loop continues in the same manner until the sender stops or closes its socket. Figure 4 includes a flowchart for the receiver side algorithm and a pseudo-code representation of the detailed software code is given as Algorithm 2.  
```
1. sock = socketUDP()
2. sock.send(\"Send Video\")
3. while(1)
4.\(F_{Recv}\) = sock.recv ()
5. data = decrypt(\(F_{Recv}\))
6. If(frame data is null)
7. return
8. Else If(data has \"Region\")
9. startRow, endRow, startCol, endCol = decodedData [region_Locations]
10. FPrev[startRow:endRow, startCol:endCol] = decode(regionOfMotion)
11. imshow(\(F_{Precv}\))
12. Else
13. If(data has [0])
14. imshow(\(F_{Precv}\))
15. Else
16.\(F_{Curr}\) = decode(data)
17.\(F_{Prep}\) = \(F_{Curr}\)
18. imshow(\(F_{Curr}\))
```  
**Algorithm 2** Receiver