Implement a replacement strategy

[Endmaril]

Implement a simple chunk replacement strategy as proposed by Lucille:

• The starting point is: We want, and we need, to see the impact (of the editing) on the network. So we must consider streaming policies realistic enough. Whereby the need for implementing a replacement policy (along with both pyramidal and FB policies).

• Literature: Reviewing in particular the possibly relevant references mentioned in [22] of Giuseppe's report, namely 27,31,30,24,34,35,13,36,37, and TMM17 found by Romaric, it turns out that the only article mentioning the need for a replacement policy is 13 above (pages 4 and 5), attached.

• What we need: As we do not investigate nor compare buffering and replacement policies in the face of low network bandwidth, designing a simple policy is sufficient. Indeed, if the amount of head motion due to editing is able to impact the consumed bw with such policy, we can predict it will impact a more refined policy.

• Proposal of replacement policy: Starting from FB's slide at 4:20 of video https://developers.facebook.com/videos/f8-2017/-the-evolution-of-dynamic-streaming/ , having a visual representation of nbof_tiles buffers (spherical buffers, or one row per tile, with progressing playing bar). Described for pyramidal buffering.

  Let T_FoV (=0.5s for instance) be the update period of the FoV, T_ch (=1s) be the chunk duration, T_bufmin (=5s) be the target duration in buffer q=0 and q=1 be the low and high quality, resp.

  
  At each T_FoV {
  
  if all nbof_tiles buffers have more than T_bufmin{
  if all buffers have q=1 for the next T_bufmin{
      dl sequentially the tiles at q=1 starting from the current FoV tile
  } else if FoV tiles not at q=1 for the next T_bufmin{
      replace next chunk of FoV tiles with q=1
  } else{
      replace one tile closest to FoV with q=1
  }
  } else {
  dl q=0 for buffers (tiles) with the fewest number of seconds stored
  }

}

[Endmaril]

The new buffer base on arraylist is now operational.

We linked it with the skeleton of the replacement strategy made by Giuseppe and Savino and I'm now working on understanding how to complete the replacement based on this skeleton and the internal exoplayer behavior.

The player can read DASH mp4 content. Non dash mp4 can't be read (at least locally) and hls is not supported. I am not sure about the support of other formats.

[Endmaril]

The new buffer is ok but the replacement strategy still have issues as noticed before the demo. I talked with Diane and will try to put in place some test cases with only one clearly identified tile replaced and identify when exactly the bugs happen to be able to efficiently debug the whole system.

Firing the downloads for the replacement and storing the incoming data into a temporary array works fine. The bottleneck seems to be the actual replacement of the data from the buffer with the downloaded replacement data.

[Endmaril]

Giuseppe has implemented a simpler replacement strategy taking advantage of the existing functions in Exoplayer2. Though simple, this strategy should be enough for our purpose. We need to stress test this solution and document it properly.

[Endmaril]

Giuseppe's replacement strategy has limitation when it comes to using it with dynamic editing. Because of the way the buffering is manage when dynamic editing is active, high quality is buffered for any tile that will be in the field of view of the user after the snap change.

Because the strategy proposed by Giuseppe discards everything in the buffer from the point where we want to start replacing, we may end up removing high quality segments that have been buffered after a snap change because the user has moved and the quality in his field of view before the snap change is low and we want to adapt to this.

This could lead to a higher bandwidth consumption than the standard editing which is not good. And it is only due to the fact that we are discarding data that does not need to be discarded. We couldn't think of a simple way (given the tools provided by the framework) to overcome this limitation. The only workaround that we could think of is to log every download and remove the weight of the duplicate downloads from the total bandwidth consumed to have the actual bandwidth that would have been consumed if the replacement were done correctly. However this will not reduce the bandwidth actually consumed by the application and thus will not allow us to do tests in limited bandwidth conditions.

In the meantime I investigated a bit more the replacement I started implementing a while ago and found some issues. I am working on fixes on those issues while also monitoring the work of Giuseppe on the replacement and helping him finalize the strategy he proposed.