DASH: Fix Period overlap resolution logic for when the first Period is removed #1311
Conversation
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
Some streaming technologies/protocol, such as DASH, have a concept of `Period`, which is a temporal subpart of the content with its own tracks and qualities. In the RxPlayer, Period are meant to be non-overlapping, to always rely on a single known list of available tracks (for audio, video and text) and available qualities at any given position. This means that you may have a Period from the position `10` (let's say seconds) to `20`, then from `20` to `30`, but never something like from position `10` to `25` then from `20` to `30`, as the `20-25` interval would be ambiguous regarding its available tracks and qualities: the two Periods are competing for it, which one should the RxPlayer consider here? Because the RxPlayer does not control the server providing the content, it has safe guards ensuring that Periods do not overlap, and in the rare cases where they do, has an algorithm to resolve such overlaps. Usually we give in that algorithm more priority to the later Periods (for example it makes sense for a live content, where a later Period most likely has been produced later and might thus be an updated version of the content if conflicting at some timecodes with a previous Period). We found out however that there was a bug in that code for when the initial Period was removed due to a later Period completely overlapping it (meaning: the later Period starts at the same time or before the initial Period). This commit fixes this, and add a test for it. This may be seen as a very rare situation, and it is as we just encountered for the first time lately, and most likely indicative of an issue at the back-end-side: why would a Period encoded later begins before (or at) a previous Period's start? It turns out that this is a trick made by some packagers in some ad-switching scenarios, to dynamically remove an ad from a content once it has been completely watched and replace it with the original content - which may even begin before the start of the now removed ad.
peaBerberian
added
the
bug
peaBerberian
changed the title
Florent-Bouisset
approved these changes
Nov 13, 2023
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Some streaming technologies/protocols such as DASH have a concept of
Period, which is a temporal subpart of the content with its own tracks, qualities and other characteristics. You can think of it for example as various programs in a contents, some having multiple audio languages and subtitles, other not.In the RxPlayer, Period are meant to be non-overlapping, to always rely on a single known list of available tracks (for audio, video and text) and available qualities at any given position.
This means that you may have a Period from the position
10(let's say seconds) to20, then from20to30, but never something like from position10to25then from20to30, as the20-25interval would be ambiguous regarding its available tracks and qualities: the two Periods are competing for it, which one should the RxPlayer consider at e.g. position22?Because the RxPlayer does not control the server providing the content, it has safe guards ensuring that Periods do not overlap, and in the rare cases where they do, has an algorithm to resolve such overlaps.
Usually we give in that algorithm more priority to the later Periods (for example it makes sense for a live content, where a later Period most likely has been produced later and might thus be an updated version of the content if conflicting at some timecodes with a previous Period).
We found out however that there was a bug in that code for when the initial Period was removed due to a later Period completely overlapping it (meaning: the later Period starts at the same time or before the initial Period).
This PR fixes this, and adds a test for it.
This may be seen as a very rare situation, and it is as we just encountered for the first time lately, and most likely indicative of an issue at the back-end-side: why would a Period scheduled for later begins before (or at) a previous Period's start?
It turns out that this is a trick made by some packagers in some ad-switching scenarios, to dynamically remove an ad from a content once it has been completely watched and replace it with the original content - which may even begin before the start of the now removed ad.