Test "buffers partial TS video segments in sequence mode" failing on Chromecast

[joeyparrish]

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

What version of Shaka Player are you using?
main

Can you reproduce the issue with our latest release version?
No

Can you reproduce the issue with the latest code from main?
Yes

Are you using the demo app or your own custom app?
N/A

If custom app, can you reproduce the issue using our demo app?
N/A

What browser and OS are you using?
Chromecast

For embedded devices (smart TVs, etc.), what model and firmware version are you using?
Chromecast Ultra, firmware 1.56, Chrome 90.0.4430.225

What are the manifest and license server URIs?

N/A

What configuration are you using? What is the output of player.getConfiguration()?

N/A

What did you do?

Run all tests on Chromecast in the lab

What did you expect to happen?
Tests pass

What actually happened?

Test "buffers partial TS video segments in sequence mode" consistently fails with:

Shaka Error MEDIA.MEDIA_SOURCE_OPERATION_FAILED (4)
Error: Failed: video queue should be empty after destroy!

A git bisect shows that the issue began with revision 464f33c (PR #5217).

This may be purely a problem with the tests, or it may be an actual bug impacting the Cast platform. This is not yet clear.

[joeyparrish]

Since that revision, the test triggers a codec switch, which triggers the failure. The switch occurs via changeType. Forcing isChangeTypeSupported() to false triggers a codec switch via reset(), which fails with a timeout. Something about codec switching is fundamentally broken on Chromecast, which will block the v4.4 release.

[joeyparrish]

I'm purely speculating at this point about what could be the problem. It seems that changeType is detected, but doesn't work, which is not shocking to me for the Cast platform. But blocking the use of changeType and resetting the pipeline doesn't work either.

I may see an issue with the reset process that might affect Cast. It appears that a new MediaSource is created, with new SourceBuffers, then the video src attribute is set to the new one, without first shutting down the original MediaSource object as we would during destroy(). Perhaps having two overlapping MediaSource objects is a problem on Cast devices, which leads reset() to fail and the test to timeout.

[joeyparrish]

Also, the failing test doesn't explicitly cover codec-switching, so the fact that this test discovered this problem is likely a coincidence. The failing test should probably be adjusted so that codec-switching does not occur, and new, explicit tests should be created for codec-switching.

[avelad]

I found the issue, it's a issue with the test. Also, I think that codec-switching is broken on chromecast (changeType)