Fix seekbar crashing on drag with faulty frameset #11596
Merged
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.
What is it?
Description of the changes in your PR
Youtubes api seems to have VERY rarely "broken" preview storyboards i.e. storyboards that are too small for the given amount of frames on the x axis and width of frames. In the linked issue only the width seems to be affected but i assume the same could happen to the height.
As an example for this video https://www.youtube.com/watch?v=sxl4DJXCDzA (jumpscare/loud sound warning) the api returns this storyboard https://i.ytimg.com/sb/sxl4DJXCDzA/storyboard3_L2/M0.jpg?sqp=-oaymwENSDfyq4qpAwVwAcABBqLzl_8DBgiPyu6jBg==&sigh=rs$AOn4CLD0HwvNS2nXMr9JYlzeuRbC1ubbtg which should have 5 160 pixel wide frames (which is 800 pixels). The image is only 795 pixels wide so it breaks at some point when trying to create a bitmap for the preview.
For this video https://www.youtube.com/watch?v=CH50zuS8DD0 the storyboard is correctly sized: https://i.ytimg.com/sb/CH50zuS8DD0/storyboard3_L2/M0.jpg?sqp=-oaymwENSDfyq4qpAwVwAcABBqLzl_8DBgikqp23Bg==&sigh=rs$AOn4CLBG_KgXP0R2Z1DI9hg-Ntn7xCnrXA.
Seems to be a youtube sided thing, i don't see any issues on the extractor side (but I could be wrong about that of course). The only "solution" i found was to catch these cases and "manually" and adjust the bounds of the preview, even though i am not super happy with that approach. There seems to be no pattern (same video length for example) behind this behaviour but this statement comes with a very small sample size so I might have missed something.
Fixes the following issue(s)
Relies on the following changes
For this PR only line 171-181 are relevant
APK testing
The APK can be found by going to the "Checks" tab below the title. On the left pane, click on "CI", scroll down to "artifacts" and click "app" to download the zip file which contains the debug APK of this PR. You can find more info and a video demonstration on this wiki page.
Due diligence