Add YouTube Most Replayed visualization to the player seekbar

[Ecomont]

Checklist

• I made sure that there are no existing issues - open or closed - which I could contribute my information to.
• I have read the FAQ and my problem isn't listed.
• 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.
• I have read and understood the AI policy. The content of this request is not generated by AI.

Feature description

I have implemented a feature to show the YouTube "Most Replayed" graph (heatmap) directly over the video player's seek bar.

I already wrote the code for both the Extractor and the App:

Extractor side: I added a new StreamHeatmapEntry model. The logic hooks into YoutubeStreamExtractor to parse the MARKER_TYPE_HEATMAP and heatMarkerRenderer objects directly from the YouTube player response JSON (extracting startMillis, durationMillis, and intensityScoreNormalized). The initial inspiration for extracting this data came from the youtube-heatmap-clipper repository, but instead of complex SVG math, I adapted it to purely parse the native JSON response.

App side: I migrated FocusAwareSeekBar and VideoPlayerUi to Kotlin. In the seek bar, I overrode the onDraw method to map the StreamHeatmapEntry list into a smooth cubic Bezier path (quadTo), drawing a semi-transparent layer over the track that accurately represents the retention peaks of the video.

I am opening this issue to discuss if the maintainers are interested in this feature before I open the formal Pull Requests.

Why do you want this feature?

Finding the most interesting or viral parts of long videos (like podcasts, tutorials, or streams) is currently difficult without skipping blindly.
YouTube already provides this UX on their official clients ("Most Replayed"). Bringing this to NewPipe significantly improves navigation for long-form content, letting users instantly see where the highest retention points are. Since the data is already in the initial JSON response, it doesn't require extra network requests.

Additional information

The code is currently working in my forks. You can check the exact implementation details here:

• NewPipeExtractor changes: https://github.com/Ecomont/NewPipeExtractor/compare/dev...Ecomont:NewPipeExtractor:feature/youtube-heatmap-extraction?expand=1
• NewPipe app changes:https://github.com/TeamNewPipe/NewPipe/compare/refactor...Ecomont:NewPipe:feature/youtube-heatmap-extraction?expand=1

If the core idea is accepted, I can open the Pull Requests right away. Let me know if there are any UI/UX or architectural adjustments you'd like me to make beforehand!

[absurdlylongusername]

I do think this feature should be in the app, for the sole reason that it's a UX feature that is already in the stock YT app.

Given that, I think discussion is more about how it looks rather than if we should have it.

That being said, in my opinion this feature isn't that big of a UX hit, compared to chapters in the seekbar which I think is a lot more useful (which you already opened a PR for, tyvm)

So I'm not really in any rush to see this merged ASAP, as ideally I'd want work to be more focused on the refactor.

Me personally, I'm fine for you to just open the PR, but should wait to hear feedback from other team members too before doing so.

Also if you could provide screen recordings of your solution in action, that would be great, seeing as you've basically already implemented it.

[Ecomont]

I do think this feature should be in the app, for the sole reason that it's a UX feature that is already in the stock YT app.

Given that, I think discussion is more about how it looks rather than if we should have it.

That being said, in my opinion this feature isn't that big of a UX hit, compared to chapters in the seekbar which I think is a lot more useful (which you already opened a PR for, tyvm)

So I'm not really in any rush to see this merged ASAP, as ideally I'd want work to be more focused on the refactor.

Me personally, I'm fine for you to just open the PR, but should wait to hear feedback from other team members too before doing so.

Also if you could provide screen recordings of your solution in action, that would be great, seeing as you've basically already implemented it.

I already added a screenshot of a random video to show how it looks in the description of the issue, let me know if you need anything else