refacto: Rename stream submodules to improve readability

Author: peaBerberian

src/README.md

@@ -91,7 +91,7 @@ it:
 Stream (./core/stream)   │                                       │    └──────┐
 ┌────────────────────────┼────────────────────────────────┐      │           │
 │                        ▼                                │      └─────────┐ │
-│ Create PeriodStreams  ┌────────────────────────────┐    │       Ask to   │ │
+│ Create TrackSelectorStreams  ┌────────────────────────────┐    │       Ask to   │ │
 │ based on the position │      StreamOrchestrator    │    │       load     │ │
 │ and settings          │(./core/stream/orchestrator)│    │       and      │ │
 │                       └────────────────────────────┘    │       parse    │ │
@@ -100,7 +100,7 @@ Stream (./core/stream)   │                                       │    └─
 │                          │            │           │     │                │ │
 │                 (audio)  ▼    (video) ▼    (text) ▼     │                │ │
 │ Create the right ┌────────┐   ┌────────┐   ┌────────┐ uses┌────────────┐ │ │
-│ AdaptationStream │        │   │        │   │        │────>│SegmentSinks│ │ │
+│ RepresentationSelector │        │   │        │   │        │────>│SegmentSinks│ │ │
 │ depending on the │ Period │─┐ │ Period │─┐ │ Period │─┐ │ │    Store   │ │ │
 │ wanted track     │ Stream │ │ │ Stream │ │ │ Stream │ │ │ │(./core/segm│ │ │
 │ (One per Period  │        │ │ │        │ │ │        │ │ │ │ent_sinks)  │ │ │

src/core/entry/core_entry.ts

@@ -612,8 +612,7 @@ function loadPreparedContent(
 
     /**
      * Stores last discontinuity update sent to the Core for each Period and type
-     * combinations, at least until the corresponding `PeriodStreamCleared`
-     * message.
+     * combinations, at least until the corresponding `StreamCleared` message.
      *
      * This is an optimization to avoid sending too much discontinuity messages to
      * the main thread when it is not needed because nothing changed.
@@ -853,7 +852,7 @@ function loadPreparedContent(
           });
         },
 
-        periodStreamReady(value) {
+        streamReady(value) {
           if (preparedContent === null) {
             return;
           }
@@ -863,13 +862,13 @@ function loadPreparedContent(
             value.adaptationRef,
           );
           sendMessage({
-            type: CoreMessageType.PeriodStreamReady,
+            type: CoreMessageType.StreamReady,
             contentId,
             value: { periodId: value.period.id, bufferType: value.type },
           });
         },
 
-        periodStreamCleared(value) {
+        streamCleared(value) {
           if (preparedContent === null) {
             return;
           }
@@ -890,7 +889,7 @@ function loadPreparedContent(
             value.type,
           );
           sendMessage({
-            type: CoreMessageType.PeriodStreamCleared,
+            type: CoreMessageType.StreamCleared,
             contentId,
             value: { periodId: value.period.id, bufferType: value.type },
           });

src/core/stream/orchestrator/README.md …core/stream/1-Period_selection/README.mdsrc/core/stream/orchestrator/README.md renamed to src/core/stream/1-Period_selection/README.md src/core/stream/orchestrator/README.md renamed to src/core/stream/1-Period_selection/README.md

@@ -92,7 +92,7 @@ less permissive way than custom ones:
 - An error coming from one of them will lead us to completely stop the content on a fatal
   error
 
-## PeriodStreams
+## TrackSelectorStreams
 
 The _DASH_ streaming technology has a concept called _Period_. Simply put, it allows to
 set various types of content successively in the same manifest.
@@ -126,11 +126,11 @@ As such, they have to be considered separately - in a different Period:
         TV Show               Italian Film            American film
 ```
 
-In the RxPlayer, we create one _PeriodStream_ per Period **and** per type.
+In the RxPlayer, we create one _TrackSelectorStream_ per Period **and** per type.
 
-_PeriodStreams_ are automatically created/destroyed during playback. The job of a single
-_PeriodStream_ is to process and download optimally the content linked to a single
-_Period_ and to a single type:
+_TrackSelectorStreams_ are automatically created/destroyed during playback. The job of a
+single _TrackSelectorStream_ is to process and download optimally the content linked to a
+single _Period_ and to a single type:
 
 ```
 - VIDEO BUFFER -
@@ -159,7 +159,7 @@ _Period_ and to a single type:
 
 To allow smooth transitions between them, we also might want to preload content defined by
 a subsequent _Period_ once we lean towards the end of the content described by the
-previous one. Thus, multiple _PeriodStreams_ might be active at the same time:
+previous one. Thus, multiple _TrackSelectorStreams_ might be active at the same time:
 
 ```
 +----------------------------   AUDIO   ----------------------------------+
@@ -189,16 +189,16 @@ previous one. Thus, multiple _PeriodStreams_ might be active at the same time:
 
 ### Multi-Period management
 
-The creation/destruction of _PeriodStreams_ is actually done in a very precize and optimal
-way, which gives a higher priority to immediate content.
+The creation/destruction of _TrackSelectorStreams_ is actually done in a very precize and
+optimal way, which gives a higher priority to immediate content.
 
 To better grasp how it works, let's imagine a regular use-case, with two periods for a
 single type of buffer:
 
 ---
 
-Let's say that the _PeriodStream_ for the first _Period_ (named P1) is currently actively
-downloading segments (the "^" sign is the current position):
+Let's say that the _TrackSelectorStream_ for the first _Period_ (named P1) is currently
+actively downloading segments (the "^" sign is the current position):
 
 ```
    P1
@@ -214,7 +214,7 @@ Once P1 is full (it has no segment left to download):
    ^
 ```
 
-We will be able to create a new _PeriodStream_, P2, for the second _Period_:
+We will be able to create a new _TrackSelectorStream_, P2, for the second _Period_:
 
 ```
    P1     P2
@@ -259,15 +259,15 @@ Once P1, goes full again, we re-create P2:
 _Note that we still have the segment pushed to P2 available in the corresponding media
 buffer_
 
-When the current position go ahead of a _PeriodStream_ (here ahead of P1):
+When the current position go ahead of a _TrackSelectorStream_ (here ahead of P1):
 
 ```
    P1     P2
 |======|===   |
         ^
 ```
 
-This _PeriodStream_ is destroyed to free up ressources:
+This _TrackSelectorStream_ is destroyed to free up ressources:
 
 ```
           P2
@@ -277,15 +277,15 @@ This _PeriodStream_ is destroyed to free up ressources:
 
 ---
 
-When the current position goes behind the first currently defined _PeriodStream_:
+When the current position goes behind the first currently defined _TrackSelectorStream_:
 
 ```
           P2
        |===   |
     ^
 ```
 
-Then we destroy all previous _PeriodStreams_ and [re-]create the one needed:
+Then we destroy all previous _TrackSelectorStreams_ and [re-]create the one needed:
 
 ```
    P1
@@ -305,7 +305,8 @@ re-create P2, which will also keep its already-pushed segments:
 ---
 
 For multiple types of buffers (example: _audio_ and _video_) the same logic is repeated
-(and separated) as many times. An _audio_ _PeriodStream_ will not influence a _video_ one:
+(and separated) as many times. An _audio_ _TrackSelectorStream_ will not influence a
+_video_ one:
 
 ```
 ---------------------------   AUDIO   --------------------------------
@@ -324,13 +325,14 @@ For multiple types of buffers (example: _audio_ and _video_) the same logic is r
      ^
 ```
 
-At the end, we should only have _PeriodStream[s]_ for consecutive Period[s]:
+At the end, we should only have _TrackSelectorStream[s]_ for consecutive Period[s]:
 
 - The first chronological one is the one currently seen by the user.
 - The last chronological one is the only one downloading content.
-- In between, we only have full consecutive _PeriodStreams_.
+- In between, we only have full consecutive _TrackSelectorStreams_.
 
 ### Communication with the API
 
-Any "Stream" communicates to the API about creations and destructions of _PeriodStreams_
-respectively through `"periodStreamReady"` and `"periodStreamCleared"` callbacks.
+Any "Stream" communicates to the API about creations and destructions of
+_TrackSelectorStreams_ respectively through `"streamReady"` and `"streamCleared"`
+callbacks.