Fix directfile audiotrack selection on Tizen #1170
Merged
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
We noticed an issue on some Samsung TVs where some (but not all) directfile contents were playing without sound. After investigation, it seems that what breaks was the action of disabling __ALL__ of an `HTMLMediaElement`'s audio tracks before enabling the one wanted, which is something we did (instead of just disabling the unwanted tracks first) due to a playback issue on Safari which would happen without (Safari would just decide to not play). So basically, an ugly-but-functional-and-still-logically-sound work-around fixed Safari but broke Tizen. In the end, I chose to keep the ugly-but-functional-... solution by default and just perform the original not-ugly solution for Tizen, because it seems to me there's more chance to re-encounter the Safari issue (e.g. because another device rely on a similar webkit build) than re-encounter the Tizen issue (which is especially known to be a broken target anyway in terms of compat - much more than safari in general) on a future new device. Though the more broken target is the only one which profit from the more elegant logic, which seems counter-intuitive! I added that in `src/compat` to make it clear that this whole logic is an ugly compat-oriented work-around.
peaBerberian
added
bug
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 noticed an issue on some Samsung TVs where some (but not all) directfile contents were playing without sound.
After investigation, it seems that what breaks was the action of disabling ALL of an
HTMLMediaElement's audio tracks before enabling the one wanted, which is something we did (instead of just disabling the unwanted tracks first) due to a playback issue on Safari which would happen without (Safari would just decide to not play).So basically, an ugly-but-functional-and-still-logically-sound work-around fixed Safari but broke Tizen.
In the end, I chose to keep the ugly-but-functional-... solution by default and just perform the original not-ugly solution for Tizen, because it seems to me there's more chance to re-encounter the Safari issue (e.g. because another device rely on a similar webkit build) than re-encounter the Tizen issue (which is especially known to be a broken target anyway in terms of compat - much more than safari in general) on a future new device.
Though the more broken target is the only one which profit from the more elegant logic, which seems counter-intuitive!
I added that in
src/compatto make it clear that this whole logic is an ugly compat-oriented work-around.