fix(Cast): Force TS content to be transmuxed on Chromecast #6262
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Although Chromecast natively supports TS content, it does not work in all cases. In particular, we have some sample live streams where some TS segments can be parsed by external tools as valid TS, but cause the Chromecast to throw a parsing error. We should reject TS content on Chromecast, and allow the builtin transmuxer to take over parsing. This also removes the use of cast.__platform__.canDisplayType to patch MediaSource.isTypeSupported on Chromecast. Current versions of Shaka Player are doing very rough filtering with isTypeSupported before calling MediaCapabilities.decodingInfo. And our MediaCapabilities polyfill calls cast.__platform__.canDisplayType directly, bypassing any polyfill we might install on isTypeSupported. So there is no longer any purpose to canDisplayType in isTypeSupported. Closes shaka-project#5278
|
Incremental code coverage: 80.00% |
alekzz
approved these changes
Feb 21, 2024
|
@joeyparrish Since TS causes so many problems, I wonder if we shouldn't reject it on all platforms and always use the transmuxer... |
|
We are practically there already. I'm okay with it. Or maybe it should be a config that's on by default, to give partners a choice about risking the native TS on a platform to save some CPU cycles. |
|
I would add a configuration to be able to use native TS or not, and if you do not have a transmuxer, always use the native one. And the default should always be to use the transmuxer for TS. With this code you always block TS even if it works in some cases (for example in VOD). My opinion is that it should be configurable... |
|
I agree. That sounds good to me. Let's make it an option that is not platform-specific, which defaults to always transmuxing TS when we can. |
joeyparrish
added a commit
that referenced
this pull request
Feb 26, 2024
Although Chromecast natively supports TS content, it does not work in all cases. In particular, we have some sample live streams where some TS segments can be parsed by external tools as valid TS, but cause the Chromecast to throw a parsing error. We should reject TS content on Chromecast, and allow the builtin transmuxer to take over parsing. This also removes the use of `cast.__platform__.canDisplayType` to patch MediaSource.isTypeSupported on Chromecast. Current versions of Shaka Player are doing very rough filtering with isTypeSupported before calling MediaCapabilities.decodingInfo. And our MediaCapabilities polyfill calls `cast.__platform__.canDisplayType` directly, bypassing any polyfill we might install on isTypeSupported. So there is no longer any purpose to canDisplayType in isTypeSupported. Closes #5278
joeyparrish
added a commit
that referenced
this pull request
Feb 26, 2024
Although Chromecast natively supports TS content, it does not work in all cases. In particular, we have some sample live streams where some TS segments can be parsed by external tools as valid TS, but cause the Chromecast to throw a parsing error. We should reject TS content on Chromecast, and allow the builtin transmuxer to take over parsing. This also removes the use of `cast.__platform__.canDisplayType` to patch MediaSource.isTypeSupported on Chromecast. Current versions of Shaka Player are doing very rough filtering with isTypeSupported before calling MediaCapabilities.decodingInfo. And our MediaCapabilities polyfill calls `cast.__platform__.canDisplayType` directly, bypassing any polyfill we might install on isTypeSupported. So there is no longer any purpose to canDisplayType in isTypeSupported. Closes #5278
joeyparrish
added a commit
that referenced
this pull request
Feb 27, 2024
Although Chromecast natively supports TS content, it does not work in all cases. In particular, we have some sample live streams where some TS segments can be parsed by external tools as valid TS, but cause the Chromecast to throw a parsing error. We should reject TS content on Chromecast, and allow the builtin transmuxer to take over parsing. This also removes the use of `cast.__platform__.canDisplayType` to patch MediaSource.isTypeSupported on Chromecast. Current versions of Shaka Player are doing very rough filtering with isTypeSupported before calling MediaCapabilities.decodingInfo. And our MediaCapabilities polyfill calls `cast.__platform__.canDisplayType` directly, bypassing any polyfill we might install on isTypeSupported. So there is no longer any purpose to canDisplayType in isTypeSupported. Closes #5278
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Although Chromecast natively supports TS content, it does not work in all cases. In particular, we have some sample live streams where some TS segments can be parsed by external tools as valid TS, but cause the Chromecast to throw a parsing error.
We should reject TS content on Chromecast, and allow the builtin transmuxer to take over parsing.
This also removes the use of
cast.__platform__.canDisplayTypeto patch MediaSource.isTypeSupported on Chromecast. Current versions of Shaka Player are doing very rough filtering with isTypeSupported before calling MediaCapabilities.decodingInfo. And our MediaCapabilities polyfill callscast.__platform__.canDisplayTypedirectly, bypassing any polyfill we might install on isTypeSupported. So there is no longer any purpose to canDisplayType in isTypeSupported.Closes #5278