Add maxBufferAhead exception for text garbage collection

[peaBerberian]

The maxBufferAhead RxPlayer option allows to manually garbage collect media data that is too far ahead from the playing position.

It can be set to a number of seconds, and was previously applied to audio, video and text media segments.

For example when setting maxBufferAhead to 30, and playing at position 20, we would remove if present media data already buffered a position 50 or more (which could for example mostly happen when seeking back in the content).

We found out however that applying that same value to the text buffer may not always be sensible:

• maxBufferAhead is most likely defined by an application to restrict memory usage. The space taken by the text cues have much less weight than audio and video
• We encounter several contents where loaded text segments span for 1 minute, most likely because of how small those segments are. Here we risk progressively reloading the same segment as its end will be GCed multiple times.

Due to both of these situations, I decided for now to have a lower bound on the maxBufferAhead applied on the text buffer to 2 minutes. We also could have made the maxBufferAhead API more configurable by letting an application set a different setting per media type, but I thought that an application may not easily realize the issue.

[Florent-Bouisset]

When clearing data due to a maxBufferAhead, we may clear partial data from a segment, as we remove directly from the buffer: segmentBuffer.removeBuffer()
Maybe we can check the segmentInventory before removing data from the buffer, and don't remove data if the segment corresponding to it is within the range of the maxAheadPosition.

Before clearing:

         A                       B                     C
|=========|=====X=====|=========|
^CurrentPosition     ^MaxAheadPosition

After clearing (current behavior):

         A                     B                  
|=========|======|
^CurrentPosition       ^MaxAheadPosition

• B was partially cleared
• C was entirely cleared

After clearing (suggestion):

         A                     B                  
|=========|======x====|
^CurrentPosition       ^MaxAheadPosition

• B was not cleared
• C was entirely cleared

This may add to much complexities but it would handle the case if text segments are > 120s

[peaBerberian]

By maxAheadPosition, I suppose you mean the wantedBufferAhead? (or its derived value, the buffer goal)

So basically when GCing forward we shouldn't remove a segment which has a part of the data below it?
It may fix many unwanted behaviors but I'm still not totally convinced, as wantedBufferAhead may be set to limit memory usage. Here it would be a little un-predictible to an application.

Though in the current code we do risk re-downloading the same segment every maxBufferAhead - wantedBufferAhead seconds for segments that are larger than this difference (which should still be relatively rare).

We maybe could POC it.

[Florent-Bouisset]

You can set this in the config file something like: MINIMUM_MAX_BUFFER_AHEAD

[peaBerberian]

Done