Allow selecting image quality among multiple images

[Stypox]

What is it?

• Feature (user facing)

Description of the changes in your PR

• This PR adapts to Multiple images support NewPipeExtractor#889, which introduces breaking changes regarding images. Instead of providing just one URL per image (e.g. getThumbnailUrl()), the extractor now provides a List<Image> (e.g. getThumbnails()), and each image has width, height and resolutionLevel attributes that allow determining an image's quality.
• This PR introduces a preference that allows users to either disable images completely, or to choose a level amongst "low", "medium" and "high". This setting replaces the "Load thumbnails" switch.
• The strategy that determines which image is chosen based on the user preference is here, along with documentation.
• In the database only one image URL is still stored, instead of the whole List<Image>. The saved URL is the preferred one at the time of saving. This keeps it simple, avoids needing to do database migrations (not really a big deal, but still) and saves storage. Otherwise we would probably double the database size just to store a whole lot of images that will never be all used anyway. The only downside is that upon changing preferred resolution level in settings, only newly fetched List<Image>s will have the correct level, while videos in history/feed will not. I don't think it's such a big deal, also because when opening a (remote) video (or playlist), the thumbnail(s) would get updated to the newly set preferred resolution level.
• The description tab in the video detail fragment now shows all available thumbnails, highlighting the one being chosen and allowing to tap on them to open in browser.

Before/After Screenshots/Screen Record

Before preference	Before list

Preference	Low (list)	Medium (list)	High (video details)	Description

TODO

• Add description to PR
• Allow user to choose thumbnail quality
• Refine preferred image choosing method
• Decide whether it's fine to save only one thumbnail in the database - Yes, it's fine.
• How should PlaylistRemoteEntity.isIdenticalTo behave? - it's fine if the thumbnail is updated in the database if the current preference has changed (since that implies choosePreferredImage returns a different url than the one saved in the database, and hence isIdenticalTo returns false)
• The description fragment should show all thumbnail URLs (and maybe highlight the preferred one being chosen)
• Add comments to the code, and possibly rename some variables
• Add tests for ImageStrategy
• Update extractor commit after channel tabs PR is merged

Fixes the following issue(s)

• Fixes Add option to reduce thumbnail resolution #3121
• Closes Image class and DB #3190 because we chose a different approach
• Closes Enhancement : high res displaying for the "clicked" item's image only (track/video details page) #1782
• Closes HD channel art fetch for Channel overview page #7656
• Also implements the ability to close add button to directly download thumbnail in best possible resolution. #10055, by sending the highest resolution image URL to an external app such as a browser

Relies on the following changes

TeamNewPipe/NewPipeExtractor#889

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.

At the moment the highest quality thumbnails will load everywhere, and that's the only noticeable difference with normal NewPipe, until a quality setting is added.

Due diligence

• I read the contribution guidelines.

[Stypox]

That's unrelated to this PR and is fixed in the channel tabs PR. I don't know why suddenly that issue started arising, as the code there didn't change... Probably a kotlin update

[Isira-Seneviratne]

This looks good to me overall, I checked on an Android 5.0 emulator and the image loading seems to be working well. I've suggested a few small changes.

[ghost]

Hi, I'm here to just make some quick note on your work, it's almost perfect, the image quality has increased a lot compared to before, however it's not sharp enough when you compare it to the highest image quality you get when you click on the thumbnail url in the description.
I hope you'll take a look into it, and thank you for your time.

[AudricV]

however it's sharp enough when you compare it to the highest image quality you get when you click on the thumbnail url in the description.

There is nothing we can really do I am afraid.

The extractor returns the thumbnails that YouTube returns on its desktop website for search results. It is not planned to build custom thumbnails ourselves on YouTube outside of RSS feeds and mixes, on which only one thumbnail or no thumbnail is available, as YouTube provides thumbnails without black borders and these thumbnails require signatures and parameters we are not able to generate.

Also, not every thumbnail resolution is available on all videos (look at the extractor PR for more details).

Using different thumbnails would create a different behavior compared to YouTube official clients in more places than RSS feeds and mixes, and I think we like to avoid that as much as we can.

[ghost]

Alright, I can't complain anymore, you already did your best to provide us with such a great app.

Thank you again.

[Stypox]

• Rebased
• Even though the images extractor PR has been merged, the current NewPipe is incompatible with it because of the channel tab changes, so the NPE commit used at the moment is this one
• Added a test for ImageStrategy and fixed a boolean condition that should have been the opposite (image.getHeight() == HEIGHT_UNKNOWN && image.getWidth() == WIDTH_UNKNOWN instead of the previous != || !=)
• Applied Isira-Seneviratne's suggestions

[TobiGr]

LGTM, just some small things

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
1 Security Hotspot
0 Code Smells

0.0% Coverage
0.0% Duplication