During the ACM ICN 2017 conference we performed a demonstration for “360-degree panoramic video streaming“. The demonstration used a tiny PC (Raspberry Pi 3) as a publisher. This document show an adaptive frame rate control scheme considering the in-network cache and the publisher’s processing load.

Issue

An issue of delivering video streaming is how to deliver the best video to users with various network qualities. Currently, the publisher provides videos with various quality, and each user selects the optimum video quality. For example, YouTube offers 7 levels of video quality.(As of Oct. 2017)

However the variety of contents can affect negatively the cache hit ratio. For example, when there are 3 video quality levels and each user requests different video quality, the benefit of the in-network cache is null (see Fig.1). To cope this problem, the bitrate selection technique for fairness was proposed. But we will show other approach for tiny PC.

Adaptive Frame-rate Video Streaming

A video is a sequence of continuous images called as “frames”. The adaptive frame rate control method is to change the number of frames to be displayed per second (see Fig.2). In particular, each frame has a unique “name” on ICN. Consumers decide the requesting frame according to their own network quality. Even if each consumer’s frame rate is different, they utilize in-network cache because they require the same “frame”.

The advantages of this method are as follows:

• Utilizing in-network cache
• Producer need only image compression, does not need video compression
• Producer compresses only required frame

This advantages reduces Producer’s processing and transferring load, thus we can deliver the 360-degree panoramic video by the tiny PC (Raspberry Pi).

Sequence Number Estimation

A usual video streaming sequentially requests segments of consecutive numbers. However the above video streaming scheme requires to discretely request the frame number. To cope with this, we estimate the frame number as follows (see Fig.3):

1. Consumer requests Metadata at Base Time
2. Producer replies Metadata including the current frame number (m) and frame interval
3. When Consumer requests a frame, it estimates the frame number at which the request packet will arrive at Producer based on Base Time and Metadata
4. To adjust clock gap and skew, Consumer requests Metadata with a certain interval

This estimation scheme is simple but operates normally.

Conclusion

In-network cache is a feature of ICN, but how to utilize it is one of the challenges. Since the current approach on IP-based architecture is not always optimal, when we design an application, it is important to think how to benefit from ICN’s features, and this work is a concrete example of how to do it.