Switching quality/bitrate of video and seeking to different position immediately causing green artifacts #2968
Comments
|
I also had similar issue on the latest version. @epiclabsDASH can you please have a look and update? |
|
@epiclabsDASH Any update on this issue? I can provide more information if needed. |
|
@iamprem, @smithpayel, sorry for the late reply. Could you please check if you can reproduce the issue in nightly version? In #2973 there is a fix regarding the way buffers are managed that could cause this kind of issues (buffers were not always rightly cleared). |
|
@epiclabsDASH I've tested with the latest development branch and i could still see the same issue happening. |
|
For now to fix this problem, i'm ignoring requests that are of type "InitializationSegment" from the abort call: The hack has to be put in the HTTPLoader's abort method: dash.js/src/streaming/net/HTTPLoader.js Lines 308 to 316 in 78e482c Fix: |
|
@iamprem, @smithpayel, could you please check your manifest and see if representations of your video adaptationset are using different id's? I recently saw a problem similar to what you mention and the problem was related with the initialization segments cache mechanism that implements dash.js. If for some reason you use same ids across different renditions (not allowed by DASH IOP) you could have this kind of green artifact issues. |
|
As far as i can tell, each Representation under an AdaptationSet has unique "id". If that was the case, I should be able to reproduce the issue without having to seek and just by changing the quality. Right? Pasted couple of sample Representation from the video AdaptationSet for your reference. |
|
@iamprem, would it be possible sharing that stream with me? |
|
@epiclabsDASH The stream is DRM protected and we use in-house solution to vend the certificate and license to the player. So i can't provide access to a stream for you to test. I even tried to spin up a server to just serve license for one sample video, but looks like the license request from the player is session specific and the license obtained from another session of the same video doesn't work. |
|
Ok, let me generate a specific debug version with some extra logs that could help to locate the issue. Thanks |
|
Any update on this issue? |
|
Another user having this problem which i believe related to this race condition: https://stackoverflow.com/questions/52035242/init-dash-js-with-certain-quality |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
stale
bot
added
the
stale
|
This issue has been automatically closed because no further activity occurred. If you think this issue is still relevant please reopen it. Thank you for your contributions. |
|
We have replicated this issue in 3.2.1 have applied a patch with PR #3603 which appears to resolve the issue |
Environment
Note: This issue happens regardless of the browser (observed both in Firefox and Chrome, because we use Widevine DRM) and OS.
Steps to reproduce
Note: This issue is little hard to reproduce because the nature of the events that triggers this issue.
You need the ability to switch quality in the player (Currently I have a UI element that allow me to switch bitrate, you can also do it programmatically using the setQualityFor API but you need to seek to a different position as fast as possible after changing quality)
Play the video with whatever initial quality that it choose to start with.
Switch the quality and immediately seek to different position in the video.
Three things could happen,
4.a. (Happy Case) The quality switch initiated the init request and completed appending to the buffer and then seek request loads further fragments.
4.b.(Happy Case) The quality switch haven't initiated the init request but the seek request is handled first without aborting any inflight requests and then the quality switch is handled.
4.c. (Failure Case) Quality switch is handled first where it issued init segment request, while it is being loaded, the seek request is handled and to support faster seeking it aborts in-flight requests. This results in incompatible init segment to decode the seeked fragments.
This bug is intermittent as i described above and i didn't succeeded in reproducing this issue using the 2.9.2 reference player. But i've attached the happy case logs and error case log from my application for your reference and to give better understanding of this issue.
Observed behaviour
The player is failing to decode the video fragments from seeked position and starting to produce weird green artifacts when the quality switch happens.
Console output
After looking at the logs produced, it looks like the onPlaybackSeeking method in ScheduleController is aborting the Init Fragment request made by the quality switch request when the two events happen very quickly in order to support faster seek response.
You can see on line 36857 it is loading video_5 and later on line 36862 the quality change is triggered to load video_4 fragment url. But if you look even further on line 37013 the init fragment request for video_4 is aborted to support faster seek.
The text was updated successfully, but these errors were encountered: