Reloading same URL using loadSource fails with errors #4621
Comments
naktinis
added
Bug
Needs Triage
|
Sorry for bumping this, but maybe someone has insights into why it is impossible to reuse the HLS instance by detaching and attaching again (or loading a new source for that matter). It would be useful if detachMedia could stop all processing and reset the player to a clean state.
|
robwalch
removed
Needs Triage
|
Hi @naktinis, The main issue here is with the test page implementation. By calling As for the comment in your bump, I'm not sure if that's related to the same problem with your test page or something else. I did just post a fix for resuming loading of alt-audio after detaching and attaching here #4816. You only need to attach once, and you don't need to call loadSource in a callback. I would recommend you don't use the attached callback at all. |
|
Hi @robwalch! Thank you for the response.
So do you mean instead of this: I should do something like this (attach once, not use callback)? However, this doesn't load the video at all. Most likely I misunderstood what you meant – could you maybe show the correct way of setting a new source without reinstantiating Hls? |
|
You would still need to call reset() in the example above. There are examples in the README and API markdown docs. |
|
Sorry, I wasn't being clear, that was just an excerpt showing the significant/conceptual part. Here's the full updated demo: I've seen the examples in the README, but I couldn't find any example there that demonstrates loading source twice on the same hls instance. I'm also attaching the full updated demo code below for reference: |
|
Hi @naktinis, Thanks for the update. When calling There may be a regression with just calling loadSource on the same URL, but there isn't a good reason to do this when you can just seek to 0 to restart playback. In fact in older versions of the player we always recommended that users destroy the player instance and create a new instance when loading another stream. |
robwalch
changed the title
|
For context, one of the reasons loadSource does not detach/attach when the url is the same is to avoid recursive behavior when you use the attached event callback to call loadSource (#3732). So rolling back that change is not an option. |
|
@robwalch thanks for taking a look at this. So I tested this by loading a new URL and it still doesn't work as expected. Added link to the demo below. I tried 3 methods to change the source:
These quality drops, by the way, is something I described in my original description of this issue and I can't seem to find a way to avoid them. For example, I tried So I still haven't found the correct way to properly load (without quality drops and warnings) a new source on an existing Hls instance – which was the main goal of this issue. Maybe I'm missing some cleanup method (other than |
HLS.js does not maintain quality between loading of items. This is not an error and requires a separate feature request to deal with. I am reviewing this issue only from the perspective that The best way to maintain quality between sessions is to instantiate a new instance of HLS.js with each item, and update the player configuration for each player to use the estimated bandwidth ( |
For HLS lazy-loading, there was a race. If a call to switch streams occurred during a fetch-and-append operation in StreamingEngine, there would be two calls to createSegmentIndex() for the same stream. This was being mishandled in the HLS parser, such that the second call would return immediately without waiting on the creation of the segment index. This fixes HLS's createSegmentIndex() method to ensure that multiple calls on the same stream return the same Promise. Closes video-dev#4621
|
Closing, as |
robwalch
added
Works in latest
What version of Hls.js are you using?
1.1.5
What browser (including version) are you using?
Chrome 99.0.4844.83 (Official Build) (x86_64)
What OS (including version) are you using?
macOS 12.3
Test stream
https://gist.githack.com/naktinis/832f23419b4a90a5b0e3756227d32d04/raw/6a1dc4acd0440cd9ae4339d4e7a997d909251d70/hls-reload.html
Configuration
Additional player setup steps
No response
Checklist
Steps to reproduce
Hlsinstance.Expected behaviour
The player should reload without errors and choose the quality that matches the estimated bandwidth.
What actually happened?
The player produces errors:
Sometimes it still loads after a while, but when it does, it drops the quality initially (for the first fragment or so), and then recovers. Initial load after page refresh always serves the higher quality on my connection, so it really seems to have to do with these errors.
Console output
Chrome media internals output
No response
The text was updated successfully, but these errors were encountered: