Backend Cloud Storage Access in Video Streaming

Editor's Notes

• #2: For comparison purpose we set the SC3DMC coders to code with 8 bits and differential coding options. We compared the orignal captured meshes to the meshes decoded using a tool to measure the symmetric distance between the surfaces. This metric is often known as haussdorf distance. A set of live captured models compressed and decoded shows that the qualities are comparible. Note that lower value implies better quality.
• #13: So from this information , what is important to understand is that there are some parts of the media container that are important for this specific media processing operation. In our case this is the moov atom and sample boxes and the size of it matters as a bigger box means worst performance. This means that we could have a file format that will be designed in an optimal way to access these information. Finally, from this information we can conclude that fetching the critical data closer to the conversion node will improve the communication.
• #14: So based on that , to improve the communication between the origin and the storage, we propose to cache the critical data closer to the origin. Also the manifest file could be cached. This way the number of requests to s3 is reduced. To be able to do this we are using an existing technology that is part of the iso base media file format standard of mpeg.
• #15: This technology refers to the dref mpeg box. This box is part of the moov box and it can specify the location of the media data. So using this we can create containers which we call dref, that only hold metadata of the content and not any media data. The dref box will point to an external file that will hold the media data and it can be either a mp4 or fmp4. So by caching this dref together with the manifest file we can have a more efficient access to the remote storage.
• #16: To evaluate the proposed setup we carried out a set of experiments using this testbed that is the same with what we saw before but now we also the apache cache on the system and we have also created the dref boxes into the storage. For this evaluation we have used apache benchmark by generating a big amount of requests for a manifest and a segment both in dash and hls. Further for this experiments we have tested the testbed with three different configurations as you see here, where each the physical location of the these components is changed. For setup 1 we have everything in the same cloud like we did before, then for seup2 we move the client far in a different cloud, which is actually more realistic, and last we the Origin is moved in the edge lets say together with the client while the storage is in a different cloud.
• #17: So here you can see the results for latency when requesting two segments of sintel, that one is encoded in a low bitrate and the other in higher bitrate, in dash and hls. So here, the blue bars are the results when only the manifest file is cached, and the other bars are the results for dref for mp4 and fmp4. So as you can see here, in all setups caching the dref will perform better, and the latency of segments will be reduced since there will be less request to S3. The highest reduction we get for setup 3, with a reduction of 70% in the latency., even though in setup 3 the origin and the storage are far from each other.
• #18: Here you see the results for two segments of elephants dream encoded into a higer resolution what we see here, is that for the big segments encoded into 2Mbps, there is littlie improvement. This could be because the segment in this case is very big, is almost 11 times bigger than the same segment encoded at 200 kbps, so for this reason you don’t see much improvement. // Another interesting observation is that when dref is cached the file format of the source video does not matter and MP4 and fMP4 have almost similar performance, as anticipated by this approach. This allows one to avoid repackaging media collections stored using non fragmented MP4 file format. Since dref has the same performance for both fmp4 and mp4
• #19: Memory usage M and CPU usage are not increased significantly Next, you can see the results when requesting a manifest file for setup 3. As you can see here, when the dref is cached, the latency is greatly reduce almost to 97% This is because everything that the origin needs to generate a manifest file is basically in the cache so you don’t need to do any request to the storage. This results is very important as it can indicate that the starup delay of a video could be decrease, because in the startup of a video the client first request the manifest file, and an initialization segment which contains metadata that are stored in the dref.
• #20: So for this reason we tried to measure the startup delay when streaming from the proposed setup, by performing a simple experiment. So we try to measure manually the startup delay. So what we did is that we are using the dash.js player to stream video and at the same time we record this streaming . Then using a video player with high precision timing we put the stream in slow speed and we just measure the time from when the viewer selects the play until the first frame is rendered in the screen. And we have done this for both the baseline setup and the proposed setup with the dref caching. Of course there are some dependencies with the video player, like for example, when is the player loading the video, as there are players that do preload, also there is the buffering , some players need to do some buffering before they start measuring. But in any case we ignore this parameters as they affect the results the same way.
• #21: So here you can see the average startup delay, that is measured by repeating the experiment. Here we can see that is some reduction on the starup delay, as you see, for sintel you even achieve a reduction of 60% which is very big gain. This is an important achievement if you consider that startup delay is one of the most influential factors for quality of experience of the user. ider. This is mp4 case
• #22: So concluding on these results we have seen that caching the dref performs most of the time best. We have also seen that the starup delay is decreased. Furthermore when using the dref, the performance between mp4 and fmp4 is almost the same But this evaluation was done just by performing request for a manifest or a segment and we still havent test in large scale, which is what we are going to do next.
• #23: So doing a large scale testing means testing with a realistic workload from video player and also with a high number of concurrent connections. So this can be done using Tensor. But in this case we need to tune the apache server for high concurrent video streaming. And this is because we have a setup with high concurrency requirements when multiple activities need to be executed at the same time (cache connections, origin connection and their communication). And the server is under heavy load and so the server needs to handle large number of concurrent connections in an efficient way. And in this case the server performance can be the bottleneck due to the OS or web server constrains. This relates to the famous c10k problem, of course there are concurrency models developed in the server to be able to support high concurrent traffic, but some customization might be needed to adjust this with the application.
• #24: So finally the results for large scale testing, these are the results fro sinte and elephtnts dream for both mpd and fmp4. What we see is that the outgoing traffic is increased compared to the baseline results especially for mp4 we have a big increase. Also here you can see the conversion efficiency metric that we introduce before. As you see here the mp4 case has improved a lot for all videos reaching almost 1. Furthermore we see that there is no performance variation between mp4 and fmp4. their performance is almost the same.
• #25: Here you see the results for tears of steel. Again we see an improvement when caching the dref. As we see for fmp4 the improvement Is not that big, if you consider that fmp4 was performing well and fmp4 is ready for dash streaming and the moov atom is not that big
• #26: Here you can see the increase that we achieved in the throughput when looking at the different resolutions and for the two videos sintel and elpehadns dream for mp4 and fmp4 So as you see the throughput is always increase in all cases, even if for fmp4 the increase is jus 20%
• #27: So concluding on those results, we see that caching the dref increases the outgoing throughput, the conversion efficinecy is increase, latency is reduce and we have seen reduced startup delay in a test player. Furthermore a key contribution of this work is the design of an intermediate file format based on dref that can improve the cloud based media processing and reduce the storage access latency. Which relates to the NBMP emerging standard for standardization of formats and API’S for distributed media processing
• #28: Regarding future work, this work could be extended by using a more complex media processing function. For example you could have a media processing function that has multiple sources and you need to stitch content together. And this is possible in many applications such as crowsoursing video, ad insertion and personalize streams. Then you have more that one remote access on content, you have heterogenous inputs and you need to do stitching of content, video synchronization and others. Then it would be interesting to know how dref works in this case and what more we can do.