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.
Isira Seneviratne