LwTE: Light-Weight Transcoding at the Edge

Abstract

Due to the growing demand for video streaming services, providers have to deal with increasing resource requirements for increasingly heterogeneous environments. To mitigate this problem, many works have been proposed which aim to (i) improve cloud/edge caching efficiency, (ii) use computation power available in the cloud/edge for on-the-fly transcoding, and (iii) optimize the trade-off among various cost parameters, e.g., storage, computation, and bandwidth. In this paper, we propose LwTE, a novel Light-weight Transcoding approach at the Edge, in the context of HTTP Adaptive Streaming (HAS). During the encoding process of a video segment at the origin side, computationally intense search processes are going on. The main idea of LwTE is to store the optimal results of these search processes as metadata for each video bitrate and reuse them at the edge servers to reduce the required time and computational resources for on-thefly transcoding. LwTE enables us to store only the highest bitrate plus corresponding metadata (of very small size) for unpopular video segments/bitrates. In this way, in addition to the significant reduction in bandwidth and storage consumption, the required time for on-the-fly transcoding of a requested segment is remarkably decreased by utilizing its corresponding metadata; unnecessary search processes are avoided. Popular video segments/bitrates are being stored. We investigate our approach for Video-on-Demand (VoD) streaming services by optimizing storage and computation (transcoding) costs at the edge servers and then compare it to conventional methods (store all bitrates, partial transcoding). The results indicate that our approach reduces the transcoding time by at least 80% and decreases the aforementioned costs by 12% to 70% compared to the state-of-the-art approaches.INDEX TERMS Video streaming, transcoding, video on demand, edge computing.

DeepStream: Video Streaming Enhancements using Compressed Deep Neural Networks

“…Based on this example, it is motivated that bitrate ladders can be optimized over the end-devices with different upscaling methods. However, since constructing multiple bitrate ladders for every title significantly increases storage and CDN costs [19], a backward-compatible and scalable pertitle encoding approach is required to support end-devices with different processing capabilities, including CPU-only and GPU-available end-devices.…”

“…Therefore, the optimization of bitrate ladders per device capabilities is required to efficiently serve clients with different computational resources [18]. However, providing a higher number of bitrate ladders, consequently, a higher number of representations, results in a significant increase in streaming costs, including storage and CDN costs [19]. Hence, a scalable approach is needed to support end-user devices with different capabilities.…”

CD-LwTE: Cost- and Delay-Aware Light-Weight Transcoding at the Edge

“…In our previous work [5], we intended to answer the following questions: (i) How to design a light-weight transcoding method at the edge? (ii) How the proposed transcoding method can be cost-effective at the edge?…”

“…For the first research question, we introduced a novel technique for transcoding called Light-weight Transcoding at the Edge (LwTE), motivated by the aforementioned issues. In the direction of the second research question, in [5], we formulated the problem of selecting a policy, i.e., store and transcode, for each segment/bitrate under unlimited available resources at the edge. The results proved the LwTE's feasibility and cost-efficiency compared to the conventional and state-of-the-art methods for simple, yet practical scenarios.…”

“…To address the above issues, in this study, we extend our investigation in [5] by proposing Costand Delayaware Light-weight Transcoding at the Edge (CD-LwTE) as a more comprehensive and realistic approach. To evaluate CD-LwTE's performance in a more realistic situation, we relax some assumptions of [5] by adding resource constraints at the edge and considering a new policy, i.e., the fetch policy, for serving the requests at the edge. In the same direction, we also add serving delay to the objective of selecting a policy for each segment/bitrate, aiming to minimize the total cost and serving delay.…”