rxPlayer v4: discontinuities on Tizen devices #1635
Comments
|
Hi, It looks like something that was recently fixed by Florent (#1586). Can you re-check with our last development build: |
|
Unfortunately, that version fails in the same manner :( |
peaBerberian
added a commit
that referenced
this issue
Jan 24, 2025
This is approximately the 9001th commit trying to work-around bugs arising due to the fact that Tizen doesn't let us seek where we want to seek in a misguided attempt to improve performance (which actually just do the opposite here). Here #1635 told us about yet another issue where playback doesn't begin when there's a discontinuity right at the beginning. After looking at communicated logs, I think this was because of a very unfortunate chain of events: 1. We begin to play a content with both audio and video segments (creating both an audio and video SourceBuffer) accordingly 2. Audio segments are the first one to be loaded. We push them to the audio SourceBuffer 3. The audio SourceBuffer later report to us that what it has buffered begins at `0.016`, not `0`. We have no problem with that. However Tizen seems to be more broken than we thought from our understanding of the HTML spec because then `HTMLMediaElement.prototype.buffered` also report data beginning at `0.016` despite the fact that video hasn't been currently be pushed in its own SourceBuffer (so to me the "global" `buffered` should be empty). 4. Our `RebufferingController` sees that there's a discontinuity at `0.016` and thus seeks just over it. 5. We're now pushing the first video segments. Because we're unlucky, they begin even later, at `0.08`. 6. Now the "global" `buffered` speaks some sense: it is now the intersection of the audio and video SourceBuffers like we expect and thus it now begins at `0.08` 7. Our `RebufferingController` do not skip that now updated discontinuity because it is still in the process of skipping the (actually-not-real) `0.016` one and because it knows we're on a device on which seeking is broken, so it just waits until Tizen has processed that first seek.. 8. Our `PlaybackObserver`, which gives its opinion on whether we should be paused to buffer content, sees that the target position is still `0.016` so start its logic from there. At `0.016`, there's no data (it begins at `0.08` now), so for it, we should still wait for segments to be loaded. 9. Our "initial_seek_and_play" logic, which between other things perform the initial `play` call, thus see that for the `PlaybackObserver`, we should wait. It thus waits until the `PlaybackObserver` give the greenlight to start the content. To fix this, I updated the behavior of the `RebufferingController` on Tizen so that it continues checking for discontinuities even if we're already waiting for one to be skipped. I though had to not consider the currently-played position anymore but actually the perhaps-different "target" position we should be playing if the device wasn't as broken as Tizen is. To note that this bug perhaps showed us another Tizen issue which is the `buffered` thing (though perhaps I'm not up-to-date with the specs?). I didn't fix it at this level because it's much harder.
peaBerberian
added a commit
that referenced
this issue
Jan 24, 2025
This is approximately the 9001th commit trying to work-around bugs arising due to the fact that Tizen doesn't let us seek where we want to seek in a misguided attempt to improve performance (which actually just do the opposite here). Here #1635 told us about yet another issue where playback doesn't begin when there's a discontinuity right at the beginning. After looking at communicated logs, I think this was because of a very unfortunate chain of events: 1. We begin to play a content with both audio and video segments (creating both an audio and video SourceBuffer) accordingly 2. Audio segments are the first one to be loaded. We push them to the audio SourceBuffer 3. The audio SourceBuffer later report to us that what it has buffered begins at `0.016`, not `0`. We have no problem with that. However Tizen seems to be more broken than we thought from our understanding of the HTML spec because then `HTMLMediaElement.prototype.buffered` also report data beginning at `0.016` despite the fact that video hasn't been currently be pushed in its own SourceBuffer (so to me the "global" `buffered` should be empty). 4. Our `RebufferingController` sees that there's a discontinuity at `0.016` and thus seeks just over it. 5. We're now pushing the first video segments. Because we're unlucky, they begin even later, at `0.08`. 6. Now the "global" `buffered` speaks some sense: it is now the intersection of the audio and video SourceBuffers like we expect and thus it now begins at `0.08` 7. Our `RebufferingController` do not skip that now updated discontinuity because it is still in the process of skipping the (actually-not-real) `0.016` one and because it knows we're on a device on which seeking is broken, so it just waits until Tizen has processed that first seek.. 8. Our `PlaybackObserver`, which gives its opinion on whether we should be paused to buffer content, sees that the target position is still `0.016` so start its logic from there. At `0.016`, there's no data (it begins at `0.08` now), so for it, we should still wait for segments to be loaded. 9. Our "initial_seek_and_play" logic, which between other things perform the initial `play` call, thus see that for the `PlaybackObserver`, we should wait. It thus waits until the `PlaybackObserver` give the greenlight to start the content. To fix this, I updated the behavior of the `RebufferingController` on Tizen so that it continues checking for discontinuities even if we're already waiting for one to be skipped. I though had to not consider the currently-played position anymore but actually the perhaps-different "target" position we should be playing if the device wasn't as broken as Tizen is. To note that this bug perhaps showed us another Tizen issue which is the `buffered` thing (though perhaps I'm not up-to-date with the specs?). I didn't fix it at this level because it's much harder.
|
OK thank you, those logs have been instructive leading to the following fix attempt: #1637 Can you test it by updating in your "rx-player": "https://github.com/peaBerberian/rx-player/releases/download/autobuild.926473ff0067666ace41b0c0a530119c77edaa8f/rx-player.tgz"And re-installing dependencies? (It corresponds to a deploy of that development branch) |
|
Fix seems to be working :) Couldnt reproduce it anymore |
|
@TomaszKowalik which Tizen devices are you seeing this on? |
|
@JohnPaulHarold On Tizen SmartTV 2022, but this issue doesn't occur with every stream; so far, we've observed it with a few replay streams, and they need to start from the beginning. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi
After switching to RxPlayer v4 (4.2.0-dev.2024091600 to be specific), we came across a regression: for some content, we can observe discontinuities on Tizen devices, which are preventing playback. What happens after starting playback is that I can see the first frame of the video, the player tries to load it, and eventually, the session is closed, leaving a black screen.
We didn’t observe this issue on RxPlayer v3.
Here are the logs I gathered:
The text was updated successfully, but these errors were encountered: