[ViacomCBS] LG Ad Period Stalls

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

What version of Shaka Player are you using? 2.5.14, 2.5.16, 3.0.4 - Happens in all three versions

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? Demo app produces same issue as our player

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

What browser and OS are you using? WebOS

For embedded devices (smart TVs, etc.), what model and firmware version are you using?

In the 2.5.x version this was the only one that had issue. Device: LG 2019 Model: 32LM620BPUA WebOS: 04.72.10

In 3.x version Platform: LG Device: 49UM7300AUE WebOS: 04.80.10

Device: LG 2019 Model: 32LM620BPUA WebOS: 04.72.10

What are the manifest and license server URIs? Will send content and script to get DAI version and DRM info etc.

What did you do? Transition from preroll to content Transition from content to 1st midroll Play all ads from last midroll & Transition to content

What did you expect to happen? It would play the Ad periods and Content periods without stalling and requiring a seek to march on.

What actually happened?

It stalls at that boundary (only on some LGTV and some content).

Temp workaround 90% effective, stallSkip was set to 1 second. This work okay for most LG tvs but not the two mentioned above. Got worse in 3.x

Perhaps a DAI Ad encode or conditioning/insert issue? I say this because, our content without “DAI influence” plays well across periods on LG. I first thought of DRM init issue like we saw with Samsung, but in this case once stalled, I can seek 1 second forward to get it unstuck, which I could not do with the DRM issue.

As mentioned we found stallSkip setting but I also found this warning in the docs:

stallSkip: number - The number of seconds that the player will skip forward when a stall has been detected. If 0, the player will pause and immediately play instead of seeking. A value of 0 is recommended and provided as default on TV platforms (WebOS, Tizen, Chromecast, etc).

Since StallSkip does not solve for all LGs and this warning we figured we should start the ticket and see what your team thinks.

The fact I can seek to the other side of that “gap” and get playback to continue, leads me to believe encoding is contributing something to this issue. We think since it is inconsistent with our content, that some ad encodings and some of our content encoding is not meshing well on with this decoder.

[joeyparrish]

@MilosRasic, I have been thinking about our gap-jumping/stall-detection for a while, and I am starting to think it needs to be burned to the ground and redone completely. It may have been built on bad assumptions, and it was definitely built to compensate for browser behavior from many years ago. Desktops have moved on, and it’s CE devices that really benefit most from manipulating the timeline and seeking automatically.

[MilosRasic]

We had exactly the same issue on all LG models with the same kind of content and it turned out to be caused by gaps in the manifest which are in turn caused by b-frames in both ads and encrypted content. LG is far more sensitive to these than other devices. We solved this by encoding ads without b-frames for LG in order to minimize the number of gaps and applying a workaround to detect stalls and unstall playback by moving currentTime by a fraction of a second, 0.8 to be exact.

Should be in production soon so that we can see whether the hardcoded value of 0.8 does the trick on all the models in the wild, but I’d definitely love to see a more universal solution in Shaka Player.

Not sure how our solution differs from Shaka’s stallSkip option. Maybe @bcupac can shed some light on that.