feat: option to pin video player at top while scrolling (closes #4484)

[XYW16]

What

Adds an opt-in option to keep the video player pinned at the top on the
video detail screen while scrolling through Comments/Related (portrait).

• New setting: Settings → Player/Audio → “Pin video player at top” (default: OFF)
• When ON (portrait): player is anchored at the top; the content area below fills the remaining height
• Landscape/fullscreen: unchanged (fullscreen still covers the screen)

Why

Better multitasking and UX parity with YouTube: users can keep watching while
reading comments or browsing recommendations. Avoids scrolling back to the top.

• Closes Option to pin video player while scrolling (YouTube-style) #12629
• Closes Scroll comments/related streams under video #4484

How

• VideoDetailFragment:
  • Listen to pinned_video_player_key in onSharedPreferenceChanged
  • setupPinnedPlayerMode() toggles between pinned overlay and original layout
  • Attach playerUi to pinned_player_placeholder when pinned
  • copyDataToPinnedLayout() updates pinned-title/uploader text
• fragment_video_detail.xml (pinned overlay):
  • Move TabLayout + ViewPager out of NestedScrollView
  • ViewPager uses layout_weight=1 to fill remaining height
• Strings & settings entry added (strings.xml, video_audio_settings.xml)

Testing (manual)

• OFF: scrolling hides the player as before
• ON: player stays visible at top; Comments↔Related switching keeps playback
• Rotation: portrait pinned; landscape/fullscreen behavior unchanged
• No conflict with back gestures; error/no-network views still work

Env: [Device/Android version/NewPipe devDebug build]

Screenshots / Demo

(attach OFF vs ON screenshots or a short GIF/MP4)

d1fa70a7878ed24172108b80d9855a0b.mp4

[Stypox]

Hi, thank you for your pull request!

As explained in the README, the dev branch is not currently accepting new feature pull requests. In particular, the player is very fragile, so making changes to it is especially problematic. We are working on the refactor branch for an improved NewPipe experience, including a new player, and will take care of improving how the player pinning behaves, but at the moment we are not ready to merge in NewPlayer yet. So unfortunately I believe that right now there is no place where you could make this PR to.

If you want to do more work related to the layout of the VideoDetailFragment, you could start migrating some of its components to Jetpack Compose on the refactor branch. If you are interested, let me know and I'll give more details. Also look here.

Btw, is your contribution part of the anual ANU comp2120 OSS assignement. Just so we know :-)

[Stypox]

Oh, also, I would not make this a setting, but rather make this permanent. We can't keep thousands of options, and the default behavior of scrolling under the video makes sense.

Another thing, why did you make a different title and subscription layout? Those should stay the same and scroll together with comments under the video.

[XYW16]

Thanks for the quick review and the clarification!

Understood — if dev isn’t accepting new feature PRs and the player is being refactored on refactor, I’m happy to close this PR and switch focus.

I’m interested in helping on the refactor branch, especially migrating parts of VideoDetailFragment to Jetpack Compose. Could you please point me to:

the current entry points/files on refactor that you’d like to see migrated first (e.g., which sections of the detail screen are good starters),

any preferred Compose patterns (e.g., theming, state hoisting, navigation), and

constraints around the new player (what to avoid touching, how to integrate a pinned header once NewPlayer is ready)?

Re your question: yes, this is part of the annual ANU COMP6120 OSS assignment 😊. I’ll mark this PR as closed (or convert to draft) and start a fresh branch targeting refactor once I have your pointers.

Thanks again!

[XYW16]

Oh, also, I would not make this a setting, but rather make this permanent. We can't keep thousands of options, and the default behavior of scrolling under the video makes sense.

Another thing, why did you make a different title and subscription layout? Those should stay the same and scroll together with comments under the video.

And Because on a normal YouTube, the title and subscription buttons stay fixed when you scroll.

[Stypox]

@XYW16 here you are:

• you could replace the whole header of the VideoDetailFragment with a rewritten component in Jetpack Compose which implements the same things in the same places
  
• work on the refactor branch, where VideoDetailFragment was migrated to Kotlin
• create a separate file called something like VideoDetailHeader to put the Compose code in
• use a ComposeView in the current video detail fragment, and set its content to the newly written compose code defined in VideoDetailHeader
• you might need to add state flows and such to make sure the Compose state is always up to date with the VDF state (e.g. to change the view accordingly when a video finishes loading, etc.)
• don't create a view model for now, unfortunately I think that for as long as VideoDetailFragment is still an XML Fragment it can't be done. A view model will be created alongside fully converting VideoDetailFragment to Compose
• you can also look at other rewrite PRs to get an idea: https://github.com/TeamNewPipe/NewPipe/pulls?q=sort%3Aupdated-desc+is%3Apr+label%3Arewrite+

Also, for the next PR please don't have LLMs write all of the code and the PR body. You can absolutely use LLMs to help find the right place where to make a change, and to suggest code snippets here and there, but you should check everything yourself, consider alternatives, and choose the one that fits better. In practice, let the LLM do the boilerplate, but don't delegate architecture decision-making to the LLM, as it's not good at it. Thanks in advance! :-)