DISCONTINUITY_ENCOUNTERED errors after consecutive audio track switches, for DASH live content, result in an endless loop #1252
Comments
|
Hello, Interesting, I thought we completely fixed those types of Tizen issues. Which RxPlayer version are you using? For a little bit of history and explanation, Tizen is a peculiar platform which do not seek where we tell it to seek but instead to a close position where it thinks it will be able to restart playback faster. For example, the RxPlayer may want to seek at a position, say, To our understanding, this does not respect the HTML WHATWG standard (and is not observed in any other implementation) and we exchanged with Samsung about this, but they did not want to change this behavior, for different reasons. However, developing a multi-platform media player is complex as many unexpected scenarios may happen anywhere in the whole stack (from hardware and drivers to the RxPlayer), which we have to detect and work-around. The But with Tizen, those seeks to skip discontinuities may be brought back to a position milliseconds before, often "inside" the corresponding discontinuity hole. Because that discontinuity monitoring logic is central to the RxPlayer, we in the end preferred to keep that logic that way and to just add exceptions for Tizen: If the position appears to abnormally go back in time on Tizen, we forbid further seeks for 5 seconds (if 5 seconds have elapsed and we're still locked at the previous position, we re-enable the discontinuity-skipping logic because Tizen may actually really be stuck on the discontinuity). As far as we know, this logic fixed all Tizen auto-seeking issues we were previously having. In logs, if you enabled
When we detect that Tizen has seeked back. From this point, we will forbid discontinuity-seeking for 5 seconds.
When playback is still stuck but the RxPlayer is letting Tizen try to get out of a discontinuity by itself due to the 5 seconds rules explained earlier. And:
If those 5 seconds have passed but Tizen wasn't able to get out of the hole. Do you see any of these logs when the problematic behavior arises? |
|
Hi, In the "DEBUG" logs, I can find all of the logs you mentioned. In between of one discontinuity warning and another I can find logs like: |
Hi,
We have encountered an issue related to audiotrack switching for live content. It was discovered on Tizen 2020 Smart TV. We are using the default
"seamless"audioTrackSwitchingMode. After a few consecutive audio track changes, I'm seeingDISCONTINUITY_ENCOUNTEREDerrors with messages like:"A discontinuity has been encountered at position 1685101429.977 and was sought at position 1685101430.0586665". But after that anotherDISCONTINUITY_ENCOUNTEREDerrros are showing up, player keeps seeking to positions from errors messages, resulting in an endless loop. After a fewDISCONTINUITY_ENCOUNTEREDerrors,MEDIA_TIME_BEFORE_MANIFESTerrors also start showing up.To address this issue, I have implemented the following fix: After the first
MEDIA_TIME_BEFORE_MANIFESTerror, I seek back to a position ofrxPlayer.getMinimumPosition() + 5, and playback resumes from there correctly. However, the loop ofDISCONTINUITY_ENCOUNTEREDerrors persists until the first occurrence of theMEDIA_TIME_BEFORE_MANIFESTerror.I would like to know the best approach to resolve this issue. Please advise on the recommended solution.
Thank you.
The text was updated successfully, but these errors were encountered: