-
Notifications
You must be signed in to change notification settings - Fork 131
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
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.
- Loading branch information
1 parent
fc38766
commit 00e6a5a
Showing
3 changed files
with
126 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters