Commits on Apr 18, 2023

1. Add representationListUpdate event for the v4 …

   While migrating some Canal+ application to the future v4.0.0 version, I
   noticed that an event, listing when the list of available
   `Representation`s associated to a currently-chosen track, was missing.
   
   ---
   
   Let's consider for example an application logic which stores
   information the current available qualities (so `Representation`) of the
   current video track.
   
   With the `v4` it can constructs its list any time the video track
   is initially set or changes for any Period, simply by respectively
   listening to the `newAvailablePeriods` event (for when it is initially
   set) and to the `trackUpdate` event (for when it is changed).
   
   This seems sufficient at first.
   
   But now let's consider that we're playing encrypted contents, and that
   one of the `Representation` of those current video tracks became
   un-decipherable. Here, an application won't be able to select that
   `Representation` anymore, so it generally will want to remove it from
   its internal state. However, there was no event to indicate that the
   list of available `Representation`s had changed.
   
   ---
   
   I thus decided to add the `representationListUpdate` event. Exactly like
   the `trackUpdate` event, it is only triggered when that list
   **changes**, i.e. not when the track was initially chosen.
   
   The exact semantic (and thus documentation wording) is even more blurry
   than that sadly: this event is sent when the list of `Representation`
   **MAY HAVE** changed. As in, it may also be sent when the exact same
   `Representation` are in fact available for that track.
   
   This last part is because implementing a logic checking that it does
   have changed is doable, but costs more effort (in terms of code writing,
   performance, storage of previous event etc.) than it should save (I
   expect that event listener to be relatively idempotent where it matters,
   as in: triggering two times the same event should not lead to an issue).
   
   Yet I still prevent most of those false positives by:
     1. checking that the event is only sent once for each track type
        (e.g. "audio", "video"...) and Period couple
     2. checking that the corresponding track is actually the
        currently-chosen one for that Period.

   

   peaBerberian committed Apr 18, 2023
   Configuration menu

   • View commit details
   • Copy full SHA for 8d427eb
   • Browse repository at this point

   Copy the full SHA

   8d427eb View commit details

   Browse the repository at this point in the history