Always seek to the start position to mitigate impact of timestamp misalignments #135
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
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.
Description
This PR mitigates the impact of timestamp misalignments in on-demand streams.
Hints
We discovered an issue with our new stream packaging solution based on AWS MediaPackage.
On-demand content currently delivered contains timestamps, which are not strictly excluded per RFC AFAWK but that MUST be aligned between media playlists if present. In our case the various media playlists have misaligned timestamps (sometimes off by more than a minute!) and we figured out that this makes the player start at different default positions (not necessarily zero) depending on the variant initially selected (sometimes more than a minute!). From a user perspective this means that depending on the player frame size (e.g. on iPad where Split View can be used) a faulty video can start at different locations, which is annoying.
A proper fix must be made on the packaging side, likely by AWS (a dedicated issue has been reported). Timestamps should either be aligned (AWS fix) or dropped (our choice). In our case they can be dropped since the content we usually publish has no use of timestamps (we are here namely talking about TV series or movies, as timestamps could make sense for on-demand content obtained as a result of a DVR playlist being ended). Either fix will take time, though, and affected videos (more than 3000 at RTS, less for other BUs) will not be processed again since they need to go through the whole upload / encoding / packaging workflow again, even though the issue is in the packaging itself.
We discovered, though, that our Pillarbox player is more resilient to this issue and could identify why. Pillarbox namely always sets a start position, even when it is the default one (zero). This has no noticeable negative effect on startup times (confirmed by having a look at Pillarbox startup metrics with / without the associated code) but ensures a more reliable behavior. This PR applies the same approach to SRG Media Player to make it resilient in the same way.
Changes made