Stalls on WebOS

[avelad]

Have you read the FAQ and checked for duplicate open issues?: Yes

What version of Shaka Player are you using?: v2.5.0-beta2

Can you reproduce the issue with our latest release version?: Yes

Can you reproduce the issue with the latest code from master?: Yes

Are you using the demo app or your own custom app?: Both

If custom app, can you reproduce the issue using our demo app?: Yes

What browser and OS are you using?:
WebOS 3.5 & WebOS 4.0

What are the manifest and license server URIs?:
https://cdn.digital.com.bo/__cl/cg:default/__c/BOLIVIATV/__op/dash-default/__f/manifest.mpd

What did you do?
Load the stream on the TV

What did you expect to happen?
There is a smooth reproduction as in Chrome/Firefox/Tizen/...

What actually happened?
A few seconds after load the stream (~30-40 seconds), there are a stall not recoverable without seek or unload/load.

After investigate a bit, I found that the function shaka.media.GapJumpingController.prototype.handleStall_ cause the stall in the TV. If use the condition if (!this.video_.paused && this.video_.playbackRate > 0 && !navigator.userAgent.includes('Web0S')) { all works perfectly.

Do you have any idea why this happens?
Would you accept a PR with this change?

[joeyparrish]

We don't have a WebOS TV yet, so we have no way to test or verify on that platform.

Disabling gap-jumping or stall-recovery on the whole platform does not sound like a solution we would accept, though. I would prefer if we could improve the signals we use to detect gaps/stalls to cover this additional platform.

Could you please investigate a little more and find out what conditions differ between WebOS and other platforms? For example, for both WebOS and a browser that works, check the values of playbackRate, paused, readyState, currentTime, and buffered and compare them.

[SemihGk]

Although it is hard to say something without internal TV logs, we had a similar issue like this one. After further discussion with LG engineers, they told us their platform does not support seeking before 'loaddata' event. If you try to change video.currentTime before this event, it was causing the playback to stall. Check this doc page . So, they were suggesting us that we should use mediaOptions if we want to adjust video.currentTime before 'loadeddata' event. You may try to investigate your issue which is based on this platform limitation.

[avelad]

I think that is not the same error. We can reproduce some seconds (30~40) and after the stall is produced without any intervention. The problem is not on the stream intialization.

@joeyparrish Tomorrow i'll try to get more logs and the values when the player enter in handleStall_ . Thanks.

[avelad]

I attach the logs from the TV:

In this case, the problem occurs after 5 seconds of load the video, with the first message of "Flushing media pipeline due to stall inside buffered range".

[joeyparrish]

Based on the log, it does appear to be stalled. It's not paused, playbackRate is 1, readyState is 4 (HAVE_ENOUGH_DATA), and currentTime isn't moving for 1 full second.

But you said that if the platform is excluded from these checks, playback doesn't stall at all? Or does it stall and then self-correct?

In addition to that clarification, one more thing would be helpful: can you log the full buffered ranges instead of the object? For example:

shaka.log.debug('handleStall_', this.video_.paused, this.video_.playbackRate,
    this.video_.readyState, this.video_.currentTime, buffered.length);
for (let i = 0; i < buffered.length; ++i) {
  shaka.log.debug('buffered[' + i + ']:',
      {start: buffered.start(i), end: buffered.end(i)});
}

This way, we can see the full contents of buffered. Thanks!

[avelad]

Hi @joeyparrish

"But you said that if the platform is excluded from these checks, playback doesn't stall at all? Or does it stall and then self-correct?"

• The playback doesn't stall at all. There are a video smooth.

I attach a new image with the text selected when the stall is produced.

I'll send you a private video with the current behaviour and the behaviour with my proposal.

[joeyparrish]

That's really strange. Because the debug logs show that all the conditions for stall detection are correctly met: video.currentTime doesn't advance, it's not paused, and the current time is well inside a buffered range (current = 125, buffered = 121 through 143).

Can you produce one more set of logs for us? This time, instead of excluding WebOS, comment out this.video_.currentTime += 0.1; and leave the rest. That will show us logs saying when a stall would have been corrected, without correcting it.

I expect to see one of two things with that:

1. The video plays smoothly, but currentTime isn't properly updated until much more than 1s have passed
2. The video plays smoothly, but currentTime is never updated

Either of these would amount to a WebOS platform bug.

[joeyparrish]

I just looked at the videos you sent us. I noticed that it seems that the stall happens at the same time as the resolution changes. Does the issue reproduce if adaptation is disabled?

player.configure('abr.enabled', false);

[avelad]

I made the first test (comment out this.video_.currentTime += 0.1)

Logs:

Full logs on txt:
full-log-1.txt

No with the abr.enabled = false

APP configuration:

Logs:

Full logs on txt:
full-log-2.txt

Note: there are the same error.

[Kogoruhn]

Similar problem on WebOS (SDK Version: 3.3.0, Firmware Version: 05.30.25) with HLS.
Drm-ed .mpd plays normal, but m3u8 streams lagging every 3-4 seconds for a 2-3 sec... For hls i use mux.js
On win desktop & Tizen both streams works fine.

[Kogoruhn]

I think, this may be due to the webOS jvm oddity (just a guess)

[avelad]

@joeyparrish, have you been able to review my previous results?

[Kogoruhn]

After investigate a bit, I found that the function shaka.media.GapJumpingController.prototype.handleStall_ cause the stall in the TV. If use the condition if (!this.video_.paused && this.video_.playbackRate > 0 && !navigator.userAgent.includes('Web0S')) { all works perfectly.

@avelad Hi! I noticed, that when handleStall_ fires, default condition
(!this.stallCorrected_ && this.stallWallTime_ < Date.now() - 1000) passed because on WebOS (in my case) stallWallTime_ almost every time is a little bit more than Date.now() - 1000, e.g.
stallWallTime_ = 1545311690351 when Date.now()= 1545311691368
So we can just increase this 'time of trust' to 1200-1500.

upd
But on first 5-10 seconds of playback still get hickups.

[avelad]

@Kogoruhn with 1500 for me it's not working.

[avelad]

I just tested with 3000 and it works 99% of the time

[makisp]

@avelad && @Kogoruhn . How do you use the GapJumpingController ? I checked the shaka.media and the GapJumpingController object is missing.

Can you provide me with a sample / example code? I Couldn't find anything useful in the documentation either.

Thanks, Makis.

[joeyparrish]

@avelad, if you have a patch that is working for you locally, could you please create a pull request? I can test your PR thoroughly on the devices that we have in our lab, so that we can be confident the fix doesn't create any regressions for any other platforms. Thanks!

[skipness]

I have simular issue on both TizenOS and WebOS. I loaded a live stream(DASH with DRM) on both platform, although the behaviour on both platform are different but at last the stream will stall.
I added code suggested here for more details.

Below are the details information for both platform.

TizenOS

Device / OS version : UA43NU7100 / TizenOS 4.0
Behaviour: Stall at the beginning
Log:

WebOS

Device/ OS version: UK6300PCD / WebOS 4.0.0-1601805
Behaviour: Can play for a while(~ 6-7 minutes) then stall. Need to restart the app in order to play again
Log:

---

If any additional informations are needed, please let me know.

[avelad]

@joeyparrish I created a patch, I'll wait to make PR to next week in case someone from the thread has objections.

diff --git a/AUTHORS b/AUTHORS
index 54101434..5c4e2bbc 100644
--- a/AUTHORS
+++ b/AUTHORS
@@ -15,6 +15,7 @@
 
 AdsWizz <*@adswizz.com>
 Alugha GmbH <*@alugha.com>
+Alvaro Velad Galvan <alvaro.velad@mirada.tv>
 Bonnier Broadcasting <*@bonnierbroadcasting.com>
 Bryan Huh <bhh1988@gmail.com>
 Esteban Dosztal <edosztal@gmail.com>
diff --git a/CONTRIBUTORS b/CONTRIBUTORS
index 1a84c719..e9c17884 100644
--- a/CONTRIBUTORS
+++ b/CONTRIBUTORS
@@ -23,6 +23,7 @@
 # Please keep the list sorted.
 
 Aaron Vaage <vaage@google.com>
+Alvaro Velad Galvan <alvaro.velad@mirada.tv>
 Andy Hochhaus <ahochhaus@samegoal.com>
 Benjamin Wallberg <benjamin.wallberg@bonnierbroadcasting.com>
 Bryan Huh <bhh1988@gmail.com>
diff --git a/lib/media/stall_detector.js b/lib/media/stall_detector.js
index d701ff56..834acf37 100644
--- a/lib/media/stall_detector.js
+++ b/lib/media/stall_detector.js
@@ -18,6 +18,7 @@
 goog.provide('shaka.media.StallDetector');
 goog.provide('shaka.media.StallDetector.Implementation');
 goog.provide('shaka.media.StallDetector.MediaElementImplementation');
+goog.require('shaka.util.Platform');
 
 /**
  * Some platforms/browsers can get stuck in the middle of a buffered range (e.g.
@@ -141,6 +142,9 @@ shaka.media.StallDetector.MediaElementImplementation = class {
 
   /** @override */
   shouldBeMakingProgress() {
+    // If we are in WebOS platform disable StallDetector
+    if (shaka.util.Platform.isWebOS()) { return false; }
+
     // If we are not trying to play, the lack of change could be misidentified
     // as a stall.
     if (this.mediaElement_.paused) { return false; }
diff --git a/lib/util/platform.js b/lib/util/platform.js
index d2de07bb..821b7200 100644
--- a/lib/util/platform.js
+++ b/lib/util/platform.js
@@ -60,6 +60,15 @@ shaka.util.Platform = class {
     return shaka.util.Platform.userAgentContains_('Tizen 3');
   }
 
+  /**
+   * Check if the current platform is a WebOS.
+   *
+   * @return {boolean}
+   */
+  static isWebOS() {
+    return shaka.util.Platform.userAgentContains_('Web0S');
+  }
+
   /**
    * Check if the current platform is a Google Chromecast.
    *

Note: I checked that with 3000 is not working always, with some combination on encoder+packager is not working, but the solution disabling the stall Detector is always working.

[joeyparrish]

That would certainly not affect other platforms. :-) Since we don't have a WebOS device ourselves, we will trust that your PR solves this issue for you. So please submit the PR at your earliest convenience.

[joeyparrish]

@skipness, please wait until we close this issue with @avelad's PR. If, after the PR is merged, you still have the issue you described, please file a separate issue on github, and we will investigate. Thanks!

[skipness]

@skipness, please wait until we close this issue with @avelad's PR. If, after the PR is merged, you still have the issue you described, please file a separate issue on github, and we will investigate. Thanks!

Sure, no problem👍

[avelad]

@skipness, please wait until we close this issue with @avelad's PR. If, after the PR is merged, you still have the issue you described, please file a separate issue on github, and we will investigate. Thanks!

I'll send the PR this monday. Thanks!

[joeyparrish]

Fixed in #1820