fix: Tizen video error fixed by checking the extended MIME type #4972
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
This should fix #4634 and possibly #4503 Some specific content was throwing 3016 error in some Tizen TV's, while playback worked fine in older versions of shaka. In these cases, one of the variants from the asset was not supported on these TV's, the lack of support was correctly detected in older versions, the variant was filtered out, and playback worked. In newer versions it was incorrectly identified as supported, and the playback error happened when we tried to play it. The difference comes from checking the extended MIME type, including info on the width, height, framerate, bitrate and channels as well. In the specific case that was failing, the variant was rejected if we included the width, and accepted if we didn't include it.
…ded type With the previous commit 4f3152d I had lost the conversion of codecs and mimeType that is done in some cases at getFullOrConvertedType function. This change's purpose is to convert the values first and then use those converted values as the input to get the extended type, using it to check if it is supported or not.
|
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
FernandoGarciaDiez
changed the title
|
Incremental code coverage: 100.00% |
github-actions
bot
added
the
status: archived
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.
We have reproduced an issue in some tizen tv's, and we think it's the cause of #4634 and possibly #4503
It happens with some streams that have 3 variants, 2 of them are supported on these TVs, but the one with higher resolution isn't. This variant uses this video: video/mp4;codecs="avc1.64002a";framerate="25";bitrate="6000000";width="1980";height="1080" and in this TV the higher resolution that is supported is 1920x1080
At filterManifestByMediaCapabilities function from stream_utils.js we were checking
Capabilities.isTypeSupported(fullType), where this "fullType" only includes the mime type and the codecs (video/mp4; codecs="avc1.64002a"for example). This is currently returning true, so the player believes that this variant is supported, but then it fails when it tries to play it.However, there was an older implementation that used shaka.media.MediaSourceEngine.isStreamSupported() function which internally checks
Capabilities.isTypeSupported(extendedMimeType), where "extendedMimeType" includes also the width, height, bitrate and framerate (for example,video/mp4;codecs="avc1.64002a";framerate="25";bitrate="6000000";width="1980";height="1080"), which in this specific case returns false because in this case the 1980 width is not supported (it should be 1920), the variant is filtered out, and the playback is started with the other 2 variants.In this proposed change I'm basically changing isTypeSupported(fullType) by isTypeSupported(extendedMimeType), keeping in mind that the codecs and mimeType could have been modified in the call to getFullOrConvertedType and we must keep using those modified values.
In this change I haven't modified the mutiplexed streams case (the case from the
if (video.codecs.includes(','))at filterManifestByMediaCapabilities), because the getExtendedType function gets the whole variant as parameter, I don't have any good way of testing the case, and also I think that the audio tracks are less likely to be affected by this issue, so it's probably not that important.