This is a pull request for the new discarding strategy.
Every time a new download has to be scheduled, we can check whether we should discard some chunks before. Chunks are actually discarded if:
the desired quality in the FoV is higher than the current one
When the quality in the field of view is low but the tile is picked, it means that the user has repositioned himself to a new FoV, and we should probably react and switch to good quality as fast as possible.
the current buffer has enough stored information
On this we use the safe margin, which is now dinamic to reflect the fact that under good network conditions, the buffer will probably be full, and viceversa. The more chunks we have, the more we can allow ourselves to discard without incurring into a rebuffering event. We never discard if the buffer is not "healthy" (also because that means that putting a good chunk at the end of the buffer still provides sufficient responsiveness).
a snap change is not about to happen in a few seconds
Otherwise, we avoid discarding because it's not worth it. We know that after the snap change we already have the desired quality. Plus, the presence of snap changes (and only this) can lead to discarding high quality chunks, so we need to make sure that it doesn't happen very often.
we have low quality chunks in the buffer
The discarding actually happens starting from the first low-quality chunk after the safe margin. High quality chunks are generally not downloaded BEFORE the discarding happens (otherwise we would have reacted before), unless there is a snap change involved which forces the quality to be high without requiring replacements for previous low-quality chunks.
For testing we need newly encoded videos, so as to avoid that drift in the timestamps that we experienced in the app. The basketball video, and the counter are okay instead.
The parameters that I considered are 1 second as minimum safe margin and 6 seconds as maximum (also used for computing the max distance of the next snap change from the playback position), but of course, being parameters, they can be adjusted.
Finally, I would suggest you to set the buffer size to 10 seconds (for both the minBufferSize and the maxBufferSize).
If something doesn't make sense (both in the code and in this post :D) we can talk about it whenever you want 👍
This is a pull request for the new discarding strategy.
Every time a new download has to be scheduled, we can check whether we should discard some chunks before. Chunks are actually discarded if:
the desired quality in the FoV is higher than the current one When the quality in the field of view is low but the tile is picked, it means that the user has repositioned himself to a new FoV, and we should probably react and switch to good quality as fast as possible.
the current buffer has enough stored information On this we use the safe margin, which is now dinamic to reflect the fact that under good network conditions, the buffer will probably be full, and viceversa. The more chunks we have, the more we can allow ourselves to discard without incurring into a rebuffering event. We never discard if the buffer is not "healthy" (also because that means that putting a good chunk at the end of the buffer still provides sufficient responsiveness).
a snap change is not about to happen in a few seconds Otherwise, we avoid discarding because it's not worth it. We know that after the snap change we already have the desired quality. Plus, the presence of snap changes (and only this) can lead to discarding high quality chunks, so we need to make sure that it doesn't happen very often.
we have low quality chunks in the buffer The discarding actually happens starting from the first low-quality chunk after the safe margin. High quality chunks are generally not downloaded BEFORE the discarding happens (otherwise we would have reacted before), unless there is a snap change involved which forces the quality to be high without requiring replacements for previous low-quality chunks.
For testing we need newly encoded videos, so as to avoid that drift in the timestamps that we experienced in the app. The basketball video, and the counter are okay instead. The parameters that I considered are 1 second as minimum safe margin and 6 seconds as maximum (also used for computing the max distance of the next snap change from the playback position), but of course, being parameters, they can be adjusted. Finally, I would suggest you to set the buffer size to 10 seconds (for both the minBufferSize and the maxBufferSize).
If something doesn't make sense (both in the code and in this post :D) we can talk about it whenever you want 👍