-
Notifications
You must be signed in to change notification settings - Fork 6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Publish HLS media structure defined by EXT-DISCONTINUITY tags #5665
Comments
This issue does not seem to follow the issue template. Make sure you provide all the required information. |
Generally, we consider the entire playlist as one piece of media and thus do not publish the discontinuity tags in any way at the moment. @AquilesCanta Ignoring the effort to implement it - Would it logically make sense to divide the HLS playlist along its discontinuity tags to create multiple periods similar to DASH? This would allow better playback customizations for cases like this. @AfanasievAnton Do you know the positions of the discontinuity tags in the app? If so, can you send a message similar to how it's described in #4176 to seek to the desired position? In pseudocode something like |
Yep. We've discussed this in the past, but it has not been on our roadmap. |
Thank you for you reply. Just wondering how precise |
It's not frame precise at the moment because it just sends a Handler message to another thread while playback is continuing. The enhancement to block playback until the message has been handled is tracked by #5660. It seems such an option would be helpful for cases like this where the message pauses, stops or seeks the player and the short blocking of playback is intentional. I'll use this issue to track the support for better publishing the media parts of HLS playlists. Note that this is probably low priority and we won't get around to do that soon. |
@AfanasievAnton |
[REQUIRED] Searched documentation and issues
#4983
#4176
[REQUIRED] Question
We have an HLS SSAI stream with ads separated by #EXT-X-DISCONTINUITY tag. As part of our flow we should be able to play ads even if user seek behind the ad position. So basically when we detect that, we are doing basic seek adjustment to the beginning of the ad. The problem raises when ad had reached to the end and we want to adjust that seek position to the initially requested one(by the user).
Currently we request playhead position once in ~1s. When ad length is 2.5s player will start playing content that comes immediately after ad for 0.5s. Only next getCurrentPosition() request would notify us that ad has ended and we need to adjust seeking to the originaly requested position.
Basically we can adjust our calls getCurrentPosition() to be more frequent (something that we want to avoid). I was thinking that hence we have a #EXT-X-DISCONTINUITY tag that separate our ads from content - notification of reaching that tag might be really useful for us to detect that transition.
Are you planning to expose that behaviour? Is there anything to be aware of if we decide to implement it by our own?
Any input from you will be really useful.
Thank you in advance.
The text was updated successfully, but these errors were encountered: