You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Relative Sequence index config, rsq, is great for setting up an HLS corruption quickly. Skipping the step of having to look up what the stream's current media-sequence number is.
However, it would be even more effective if the users could configure to target the corruption onto a segment calculated from the bottom of the playlist manifest, instead of the top, as this can be a cumbersome task to calculate depending on the size of the playlist manifest.
Corrupting the segments at/near the bottom of the manifest is a good way to simulate errors from players who get too close to the live edge in a stream, trying to access a segment file that is yet to be downloadable.
This improvement would streamline the process of simulating real-world scenarios and enhance the product's capability to replicate edge-case conditions encountered by HLS players.
Proposed Solution
I propose a solution for rsq to also be able to accept negative integers in which it will step from the bottom of the segments list rather than the top.
ie.
The Corruption query ?url=https://mock.mock.com/stream/hls/master.m3u8&statusCode=[{rsq:-1,code:404}]&delay=[{rsq:-2,ms:2000}]
Results in the following playlist manifest on the first load:
* feat(#48): Added support for negative indexing when using rsq
* fix: removed console.log and fixed wrong example url in readme
* chore: added info about the use of negative rsq values to README
* fix: removed console.log left over from testing
The Relative Sequence index config,
rsq
, is great for setting up an HLS corruption quickly. Skipping the step of having to look up what the stream's current media-sequence number is.However, it would be even more effective if the users could configure to target the corruption onto a segment calculated from the bottom of the playlist manifest, instead of the top, as this can be a cumbersome task to calculate depending on the size of the playlist manifest.
Corrupting the segments at/near the bottom of the manifest is a good way to simulate errors from players who get too close to the live edge in a stream, trying to access a segment file that is yet to be downloadable.
This improvement would streamline the process of simulating real-world scenarios and enhance the product's capability to replicate edge-case conditions encountered by HLS players.
Proposed Solution
I propose a solution for
rsq
to also be able to accept negative integers in which it will step from the bottom of the segments list rather than the top.ie.
The Corruption query
?url=https://mock.mock.com/stream/hls/master.m3u8&statusCode=[{rsq:-1,code:404}]&delay=[{rsq:-2,ms:2000}]
Results in the following playlist manifest on the first load:
The text was updated successfully, but these errors were encountered: