Multiple video players on 1 entry

[logancgarcia]

For some video-based feeds, such as PeerTube feeds, there are multiple resolutions of the video attached in the media:group section of a given entry. For example, see this feed. By default, Miniflux attempts to iterate through each of these media elements and display them as videos above the entry content. On low RAM devices (e.g. my older Android phone), this causes my browser to crash. The only way to seemingly avoid this is to check the No media player (audio/video) option, which is unfortunate, since I then have to go down to the Attachments section and watch the video from there or click on the feed itself to go to the PeerTube instance.

When thinking about this issue, I think there are several ways to slice it:

Change Miniflux video player to allow user to select video resolution

From what I understand, the Miniflux video player is basically just an embed of the video that allows a browser to offer it's native video player, so this one might be way more of a stretch than is necessary. But with this method, a dropdown menu would need to be present somehow for the user to select the video resolution to play.

Allow selecting a max resolution in the feed settings

This one seems much more inline with Miniflux's minimalism, as the user can specify what the "maximum" allowable resolution would be in order for the video to show up, and only that one video would appear as a media player on top of the entry content. If the user defined, for example, "720p" as their max resolution, and the feed only offered a 480p and a 1080p version of the video, then the feed would display the 480p one. A default value of "Highest resolution" should probably be set when the feed is first added.

Display the media:embed value instead

For Media-RSS feeds, there is oftentimes a media:embed value, which is similar to how YouTube feeds work in Miniflux when using an embedded player on the top of the entry content. This would take precedence instead of displaying the media player content sourced from the attachments.

Allow more user control of attachments

This is a pretty vague solution, but in general, if Miniflux allowed the user to "remove" certain attachments (similar to how a user can use the remove function of the scraper to remove certain DOM elements), then they would be able to simply remove the attachments on a given feed so they won't be sourced by the Miniflux player.