Rewrite the player (and all its components)

[AudricV]

Checklist

• I made sure that there are no existing issues - open or closed - which I could contribute my information to.
• I'm aware that this is a request for NewPipe itself and that requests for adding a new service need to be made at NewPipeExtractor.
• I have taken the time to fill in all the required details. I understand that the feature request will be dismissed otherwise.
• This issue contains only one feature request.
• I have read and understood the contribution guidelines.

Feature description

The player codebase is pretty hard to understand, is very old, and uses several deprecated methods (which may have been already removed in the latest ExoPlayer versions)/old ways to do some things in ExoPlayer.

The current implementation also does not really allow the implementation of the Android Picture and Picture API (or it is really hard to do), required for Android 12+ devices to prevent untrusted touches outside the popup window, as an activity or a fragment is required to enter the PiP mode. The player seems to be added manually with a view within the VideoDetailFragment (that's probably not a good idea at all to enter this fragment into PiP mode).

We currently have some player bugs for which we don't really have a way to detect them and/or fix them, like the playback position reset when switching at least manually player type (that we fixed with a workaround).

We may split the player into two parts such as a part in a fragment and the ExoPlayer part in a separate class and file.

Why do you want this feature?

I want this "feature" mainly to fix weird player bugs, update to new ExoPlayer APIs, fix popup mode on Android 12+ devices but also to improve code readability and maintenability and make comments about the player code such as the player is a hot pile of 💩 or the code is a spaghetti monster of doom gone.

[SC1040-TS2]

This is also necessary now more than ever due to the way both the player and NewPipe's Extractor are currently failing to reliably parse and play WebM videos. Particularly WebM VP9 videos are causing Extractor errors.

[Stypox]

Something I was thinking about the other day is the following. We should differentiate between the player logic and the UI.

• I'd create a PlayerLogic class that handles the exoplayer, for example by handling "next", "pause", "seek", ... actions, player errors, playback listeners, playback parameters, initializing and taking care of the queue, choosing whether to play only audio or not, and possibly other things.
• Then I'd create multiple PlayerUI classes that take care of the different types of UI we have. The PlayerLogic can interact with multiple UIs at once, thanks to listeners, intents or the UIs calling methods on the PlayerLogic instance (when applicable). The UIs I was thinking of are:
  • NotificationPlayerUI handles creating and maintaining the notification, and reacts to notification actions by sending them to the PlayerLogic
  • MainPlayerUI handles the main player inside the video detail fragment, and provides the PlayerLogic with a surface on which to draw videos
  • PopupPlayerUI handles the popup player fragment in the PiP, also provides a surface like ^
  • QueuePlayerUI shows the play queue (be it for the background or popup player)
  • VideoDetailFragmentPlayerUI (maybe with a better name) handles the bottom mini player and shows the progress of background/popup players in the video detail fragment if needed

[karyogamy]

* I'd create a `PlayerLogic` class that handles the exoplayer, for example by handling "next", "pause", "seek", ... actions, player > errors, playback listeners, playback parameters, initializing and taking care of the queue, choosing whether to play only audio or > not, and possibly other things.

Separating the player logic is definitely a good start. Now that the player feature set is mature enough, is it possible to design a model that captures the full player state so it can reliable reconstruct, for example, after a crash?

Following from that, what about the size of the player state. Do we want to keep an entire play queue in memory with thousands of items? Or continue passing that via intent? Should the player state be persistent in database and constantly updated perhaps?

And if the player can be reliably reconstructed, would it make sense to drop some complex features, such as the on-the-fly video quality selector?

[opusforlife2]

Is it possible to refactor the player in small chunks instead of one huge PR? I'm thinking if it is possible, the effort could be spread out over several releases (since it's not a user-facing change), so that no one dev is burdened by a huge TODO.

[karyogamy]

Stumbled upon this blogpost from ExoPlayer, which will be merged into AndroidX Media3 in the future. Maybe the player rewrite should target Media3 instead of building from scratch again, since it has an interesting set of dependencies, including ui and cast.

[AudricV]

Note that the cast extension cannot be included in NewPipe as it uses Play Services components.

[Stypox]

I am closing this because the main point has been solved by #8170. There are obviosly more things to do, but they are rather small ones, so I'd track them in #8616.

[AudricV]

Indeed, but doesn't a partial rewrite is still needed for the Android Picture in Picture implementation in the app?

[Stypox]

Yes, definitely. I added that to the TODO list in #8616