Instead of the `trackId`, which is only ever set for the `youtube`
backend, we use the audio stream language and tracktype. These are
`null` for youtube videos without language selector, leading to a
single audio stream being selected.
For media.ccc.de, the language on audio tracks is always set
correctly, meaning for a video with German and English tracks we get
two groups, which are then sorted according to the preferences of
users.
I verified that youtube still works by playing
https://www.youtube.com/watch?v=8bDRVP9xSfc
and selecting the different audio streams, going to background etc.
and also tried with a video without multiple audio tracks.
For media.ccc.de, it will select the right audio track as well.
Unfortunately, media.ccc.de returns videos with multiple audio track
muxed into the video itself, which is still buggy because the wrong
track is selected by default. This is gonna be fixed/worked around in
the next commit.
Instead of allowing to pass arbitrary out-of-bounds indexes to these
bean classes, ensure that the index is always valid for the list.
This is always true for our filter functions, except they all return
`-1` if the list was empty. We have to check/assert that beforehand.
This improves the logic somewhat, because fetching the stream always
returns something now.
Ideally, we wouldn’t be filtering stuff and then passing indices
around everywhere, but that’s the current state of things.
~~~
I took the liberty to remove the `.of`-wrappers, because they don’t
really add much compared to just calling the constructor here.
All functions that set videoIndex return `-1` if the list is empty, so
we don’t have to check manually for that case.
I’m somewhat more questioning why `StreamInfoTag.of` allows the index
to be out-of-bounds in the constructor, that should be an error.
I was trying to understand the logic here, and noticed the indirection
via a QualityResolver interfaces is pretty unnecessary. Just branching
directly makes the logic a lot easier to follow.
The `-999` sentinel value is a bit dumb, but java does not recognize
that videoIndex is always initialized.
Nice side-effect, the `Resolver` interface was completely unused and
can be dropped.
This change is in line with a recent change in how the play/pause button behaves in the player ui: if the buffering indicator is shown, it's still possible to toggle play/pause, to allow e.g. pausing videos before they even start.
This change was needed because on Android 13+ notification actions can't be null, and thus the buffering hourglass action wasn't shown.
Profpatsch
Stypox
TobiGr
TacoTheDank
Isira Seneviratne