Low-cost Video Transcoding at the Wireless Edge

Overview:

This paper talks about providing video transcoding solution using the low-cost hardware device, Raspberry Pi (RPi). RPi is a low cost hardware device which includes a GPU and a hardware decoder and encoder which can accelerate the video transcoding process. This hardware based solution (TransPi) is in-lieu of many other software based solutions which use adaptive bitrate approach  and video transcoding techniques. The video transcoding solution runs at the wireless Edge (attached to the wireless Access Point(AP) / home WiFi Access Points), which provides more agile adaptation to sudden changes in the network and is able to quickly incorporate client feedback. This solution offers real-time video streaming service, and therefore enhances the user experience while watching any live-streaming videos without any interruption or re-buffering.  

Key Points:

1. Video transcoding converts the input video stream to pre-configured format to overcome any issues presented by multiple formats of the video streams.
2. Preprocessing approaches like “adaptive bitrate” where media server maintains multiple versions of a video, encoded in different bitrates and qualities, have limitations such as accurate prediction of the network changes so that the corresponding version could be loaded for streaming. TransPi, a cost-effective, real-time video transcoding solution solves this problem by processing the incoming video on the fly with minimal delay.
3. TransPi supports two streaming formats HLS ( HTTP Live Streaming) and DASH (Dynamic Adaptive Streaming over HTTP), where it just follows their specifications and not the rate adaptation algorithms, since TransPi uses a hardware encoder and decoder to transcode input video data to a single-rate output Stream based on user’s network connectivity.
4. HLS is HTTP based media streaming protocol which breaks the video stream into small fixed length chunks. DASH, provides high quality streaming of media content delivered over web-servers. Both use adaptive bitrate streaming technique to adapt any network changes. A client may select from a number of different alternate streams containing the same material encoded at variety of bitrates based on network bandwidth.
5. Digital Academic Television Network  (DATN) has been used as media source. Paradrop AP is used to have programmable AP and tweak network bandwidth for experiments.
6. Results from their initial experiments brings out the following limitations and hence motivates to have a low latency edge powered solution which could incorporate high fluctuations in the network.
1. HLS and DASH are either too conservative or too aggressive in choosing the optimal bitrate.
2. The number of bitrates selected are too less to handle network dynamics
3. Bitrate adaptation technique doesn’t work well in the wireless environment, especially when the last hop to the client is wireless
7. Video Streaming service near the access point improves the quality of video by maximizing bandwidth utilization as well as by selecting the video bitrates accordingly.
8. TransPi uses channel-aware bitrate decision approach, which is as follows:
1. Bandwidth monitor periodically(100 ms) sends client’s information to the encoder on RPi, which helps in determining transcoding parameters instantaneously.
2. Video transcoder fetches the requested stream, decodes and encodes with the adapted bitrate (once per second) based on client’s information.
9. Client plays the transcoded output segments in real time with a delay of 400ms ( ~75 KB, also chosen as the output queue size in the transcoder).  

Strengths:

1. Authors have done extensive research in the related domain to find the limitations of the current solutions, and hence try to get a unique solution ( hardware based) which opens new possibilities for future improvements as well pertaining to hardware based solutions.
2. Authors discuss about the design pretty well and have evaluated their proposed algorithms by testing them extensively.
3. Authors have accounted for any scalability changes (number of users in the network), and proposed solutions to address problems arising with that ( clustering multiple RPIs along with transcoding manager).

Weaknesses:

1. The implementation of the transcoding algorithm is not discussed much in detail, as to how RaspberryPi utilizes the hardware encoder/decoder as well the use of GPU.
2. Scalability of RPIs can be a limitation (discussed in paper as well), since TransPi works best when number of streams is more than number of users in the network.
3. 400 ms as the size of output queue has been empirically set. This value has not been played around with, in the experiments.

Discussion Points:

1. How valid is it to assume that the last wireless hop is the bottleneck in the network? There might be other parameters that might be affecting network bandwidth.
2. Can there transcoding algorithm be parallelized on a single device (they talked about parallelizing multiple processes in a rack of RPIs), since we know transcoding is computationally intensive and Raspberry has a GPU?
3. How would the size of output queue (taken as 400 ms) impact their transcoding results, had the authors experimented with that attribute?
4. It would be insightful to have the results of using this transcoding technique in a multiple APs environment (like our University where we have multiple Wifi APs) where the tasks can be offloaded to other wifi APs (nearest APs) if the number of users accessing a particular wireless AP are high.