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.
This behavior was present before 0.24.0 and the player UI separation and
avoided crashes for which their exception contained
"Context.startForegroundService() did not then call Service.startForeground()".
Some player nullability checks have been also added, and the player service is
now stopped when it has been started from a media button and there is nothing
to play.
As the player can be null in some cases, we have to make sure that the player
is not null, by using Optionals on the player itself instead of its methods
returning Optionals.
If the player is null, the play queue audio track menu will now be hidden.
The previous "main" tab is now just a normal tab returned in getTabs().
Various part of the code that used to handle channels as ListInfo now either take the first (playable, i.e. with streams) tab (e.g. the ChannelTabPlayQueue), or take all of them combined (e.g. the feed).
- don't check for isAudioOnly == !videoEnabled, as this prevents enabling again
video and text tracks renderers in some cases;
- when reloading play queue manager if that's needed, disable or enable video
and text tracks renderers, as they may need to be enabled again in some cases
like starting a video in main player, opening play queue, switching to
background player on it and switching back to main player;
- disable or enable video renderers also for streams with AUDIO_STREAM
StreamType, as doing so doesn't raise any issue and simplifies code;
- reword and move some comments to make them easier to understand.
NewPipe Extractor now extracts all YouTube Itags and therefore only those which can be handled by the player need to be retrieved from the list of all available streams.
As some devices not present in ExoPlayer's list may not implement
MediaCodec.setOutputSurface(Surface) properly, this workaround could be useful
on these devices.
It forces ExoPlayer to fall back on releasing and re-instantiating video codec
instances, which is always used on Android 5 and lower due to addition of this
method in Android 6.
To do so, a CustomMediaCodecVideoRenderer, based on ExoPlayer's
MediaVideoCodecRenderer which always return true for the
codecNeedsSetOutputSurfaceWorkaround method has been added, which is used in
CustomRenderersFactory, a class based on DefaultRenderersFactory which always
returns our CustomMediaCodecVideoRenderer as the video renderers.
CustomRenderersFactory replaces DefaultRenderersFactory in the player, in the
case this setting is enabled.
Media tunneling may be not supported by more devices than the ones we
whitelisted before.
As a matter of fact, the list of devices on which media tunneling is disabled
could be not maintainable in the future, especially if the list of devices
grows more and more.
A preferable solution is to allow users to configure this setting themselves,
allowing them to not wait for their device(s) to be whitelisted in a future
NewPipe update.
This solution has been applied in this commit and works on every build type.
The corresponding preference in the debug settings has been of course removed
and the code used to prevent media tunneling activation on specific devices has
been removed.
This option could help to avoid decoder initialization issues, which falls back
to lower-priority decoders if decoder initialization fails. This may result in
poor playback performance than when using primary decoders.
It is disabled by default, but can be enabled in ExoPlayer settings.