Newpipe: [Feature Request] YouTube's fast forward/rewind behavior

[vkay94]

Describe the feature you want

It's a replacement of the current fast forward/rewind functionality. For a demonstration watch this video (https://streamable.com/e/qhuca0) or see the images below.

Is your feature request related to a problem? Please describe it

No.

Additional context

When you try the debug (app-debug-seek-20200915-02.zip) then you should keep this in mind:

The current dev branch has problems with seeking for many videos. You can verify it by seeking the seekbar and check if there is a delay (visually). I recommend these two videos for testing: https://www.youtube.com/watch?v=xTJcASRxbfI and https://www.youtube.com/watch?v=pXRviuL6vMY
They haven't got that great delay and therefore the UI should response better (less jerky) than on most over videos with this build.

How will you/everyone benefit from this feature?

I think it feels more natural when

• 3 fast taps results in 20 seconds seek instead of 10 seconds + normal click (showControls will be called)
• 4 fast taps results in 30 seconds instead of 20 seconds

I'm looking forward to your opinions ;)

[MD77MD]

this is real great.. i would have a small suggestion... it would be really great if the player controls do not show up after seeking but continue normal playback... that is unless the video is paused in first place (like what's in your video preview).

if this is already the case... please add a video
for ripples in both playing and paused playback

[vkay94]

It behaves that way, specifically the controls don't appear when it's playing:

@Override
public void onAnimationEnd() {
    animateView(ytOverlay, false, 300);
    if (!isPlaying()) {
        showControls(300);
    }
}

The fine-tuning (especially with the new gestures introduced with the unified player) comes when the head devs would accept it.

Here's the demonstration (this time it's the fullscreen view + both seekBy calls are removed for now, so the video will not seek in the preview - reason descriped above):
https://streamable.com/b623hq (first part = paused, second = playing)

[opusforlife2]

To my knowledge, this is the first concrete example we have of a contribution being discussed as an issue before a potential PR, after the change was made to the contribution guidelines, so thanks for that! ;)

[MD77MD]

It behaves that way, specifically the controls don't appear when it's playing:

it looks great now👏

@opusforlife2 you forget to share your opinion of the PR with us ... yes please 😊

[opusforlife2]

Personally, I don't like the ripples and was glad to be rid of them back when I uninstalled Youtube. I don't think this gesture needs a special animation.

But I like the skip duration increasing with each tap like Youtube. That is better than repeatedly double tapping for sure.

[vkay94]

it looks great now👏

Thanks

@opusforlife2
I think it's naturally to wait for feedback before doing optimizations and keep it as simple as possible to react to changes (agile development). It'd be time inefficient when putting much effort and then it gets discarded immediately (e.g. I disabled checkStyles completely otherwise it wouldn't build because it's not very "clean" xD)

The ripple animation is a one liner due to my previous codebase, the "each following tap increase" is fully separated from the animation (=> I made changes in PlayerGestureListener) so can be adjusted easily.

I'd like to wait for more feedback, but thanks for your opinions so far :D

[MD77MD]

@opusforlife2
I actually agree with you, however, we need feedback to indicate that the seek action was performed and player will start loading/playing soon... I have two ideas we can discuss:

1. limited ripple to one at the end
2. we can replace ripples by emphasizing seek duration using a bigger font/animation (which i prefer).

@vkay94 if its not too much to ask... could you adjust for both ideas and share video with us to vote on them

[vkay94]

@MD77MD
The first idea isn't feasible with my approach because you can't determine whether the one touch, you've done now, has been the last.
In my implementation there is a time frame between each tap. When e.g. 500 ms has passed after the last tap then cancel the mode, otherwise detect it as a followed one and wait 500 ms again.

For the second idea: That would be very easy to do but what do you exactly mean by "animation"? Just keeping the arc shape, text and triangles?

[opusforlife2]

For me just the text and triangles are enough.

[vkay94]

@opusforlife2
Like this (well ... I hope, there's definitely another background color required to emphasize it I guess)? https://streamable.com/zrj4jb

PS: I like the discussion with you two, exchanging is everything ;)

[opusforlife2]

Like this (well ... I hope, there's definitely another background color required to emphasize it I guess)? https://streamable.com/zrj4jb

Looks perfect to me. :D

[Stypox]

Like this (well ... I hope, there's definitely another background color required to emphasize it I guess)? https://streamable.com/zrj4jb

This looks good to me, it feels more polished and natural than the current approach. I agree that the ripple effect is too intrusive, but something similar could replace it. Maybe an animation to hide arrows+text at the end, by e.g. moving them to the right/left and fading at the same time, would do.

I am in favuor of this, thank you! @avently @B0pol @wb9688 what's your opinion?

[opusforlife2]

by e.g. moving them to the right/left and fading at the same time, would do.

_Just_ fading out is another option.

[vkay94]

Maybe an animation to hide arrows+text at the end, by e.g. moving them to the right/left and fading at the same time, would do.

That could be implemented based on the NewPipe's AnimationUtils (thi but with translationX instead) - or just fading what @opusforlife2 has mentioned.

As I hear out from the previous comments this behavior change itself (described in _How will you/everyone benefit from this feature?_) is appreciated,, only the visual and some transition fine-tuning is in question, am I right? If that's the case, I have some idea for the future ;).

For this moment I'd switch to the master branch codebase to make an fluid preview app with working seek since official v0.19.8 hasn't the seek glitch of the dev branch (you can check it yourself by installing the unified-player-builds and drag the seekbar during playback).

[wb9688]

@vkay94: Yup, the feature is OK, just the ripple UI isn't.

Also please don't use the master branch, but the dev branch. There are a lot of changes to the player in dev, so basing it on master would be a waste of time.

[vkay94]

@wb9688 : Alright, I'm using the feedback from you all - I didn't know the ripples are hated that much (btw the transparency can be adjusted :')) - (thanks for that 👍 ). I start doing some additions to share a first debug app (I hope it is okay without a pull request).
In fact you're right about the master branch, it isn't that worthy simply for a fluid demo.

[MD77MD]

For the second idea: That would be very easy to do but what do you exactly mean by "animation"? Just keeping the arc shape, text and triangles?

I meant text and triangles... just didnt know what to call them 😁

Like this (well ... I hope, there's definitely another background color required to emphasize it I guess)? https://streamable.com/zrj4jb

looks great to me 👏

[avently]

I think it feels more natural when

Agree.

I prefer this: ripple animation + arc shape + triangles + text. Yeah, for some reason other guys think the opposite way :)
I use RutubeList app a little bit and it has this ripple effect. Very first time I saw this in that app I disliked it. But now I like it.

So maybe in your PR, @vkay94, you could upload both versions (with and without ripple effect) and everyone can use both and to choose afterwards.
I also prefer with ripple effect because when you're watching a video with white space under your text you'll not see a text but with ripple effect you'll see a ripple:) And it's looks cooler.

[vkay94]

@avently, so us two are the only ones who like them from those who gave their opinions so far :')

I also prefer with ripple effect because when you're watching a video with white space under your text you'll not see a text but with ripple effect you'll see a ripple:) And it's looks cooler.

Yeah, that's one of the reasons I did work on such a feature back then. With white text the dark background has to be darker to emphasize it better. Not everyone likes that. Currently the background value is #64000000 what's pretty transparent.

So maybe in your PR, @vkay94, you could upload both versions (with and without ripple effect) and everyone can use both and to choose afterwards.

You can test those variants here in the meanwhile to get a first feeling. For those who don't like the ripple: just set both color transparencies to 0%.

I've got something in mind to suit both. 0.20.0 / 0.20.1 won't be released that soon, I guess, so there's no hurry, right? ;)

[MD77MD]

see @avently ... its ok to like or ask for something you only want while the others dont... it not a crime to have a different taste.😊

@vkay94
wouldn't having transparent ripples add unnecessary work for animation

[avently]

@vkay94 I tested both variants via your app and I like with ripple more than without.
Also I suggest to increase the time between every tap, so it if you tap multiple times you'll get something like:
10, 20, 30, 50, 70, 100, 150, 200 seconds.

[opusforlife2]

You can test those variants here in the meanwhile to get a first feeling.

@vkay94 In your demo apk, if I set both Tap circle alpha and Background circle alpha to 0%, double tapping darkens the whole video for the duration of the animation. I like this much better than the ripple. Wouldn't this also solve the white text on white background problem?

[vkay94]

@MD77MD: For NewPipe I handle it in another way, so it won't be drawn if the ripples are disabled, so there won't be additional work regarding this.

@avently: This can be accomplished but such behavior has no priority since only a few people would use it probably. I keep it in mind ;)

@opusforlife2: The slightly dark background is by default and needed anyway. NewPipe's dark shadow is slightly more transparent than in my app. You'll see it in the debug-app preview.

Speaking of debug apk: app-debug-seek-suffix-fix_20200912.zip

Quick overview:

In general it's fully functional regarding the double tapping feature. Within the player, near the Quality-Button, I've added a "Seek"-Button where you can play with some values. It's only for test purposes.

• Seconds: Amount of seconds to skip per tap (linear - not 10. 20, 50, 200 :'))
• Controls hide delay: In case of "video playing + controls visible" this time in milliseconds sets the duration how long the controls are visible alongside with the seek overlay. You'll understand it immediately when you try it.
• Text size: In this version it's not functional but it sets the text size.
• Slide: explained in the app ;)

I'll update the opening post later with these changes and updated preview video.
I recommend the following video for testing: https://www.youtube.com/watch?v=pXRviuL6vMY In this video I didn't notice the great delay while seeking the seekbar, in other there is. Pretty strange.

[avently]

Right now i'm unable to install the apk you provided because it ends with .debug but I already have a debug version with different certificate signing. So you need to create your branch based on dev and gradle will append the apk with different suffix based on your branch name. This way anyone will be able to install the apk

[vkay94]

So you need to create your branch based on dev and gradle will append the apk with different suffix based on your branch name.

Oh, sorry, I didn't know that (I only use one debug version at a time). Here's the fix: app-debug-seek-suffix-fix_20200912.zip

[B0pol]

To my knowledge, this is the first concrete example we have of a contribution being discussed as an issue before a potential PR, after the change was made to the contribution guidelines, so thanks for that! ;)

no, look at #2882

am in favuor of this, thank you! @ avently @ B0pol @ wb9688 what's your opinion?

I don't really like the first video (OP) because it looks like exactly YouTube. But I agree it should be improved, not knowing how many seconds you moved is annoying.

But the latest apk looks great! Btw I haven't seen the difference between slide and slide disabled.

[vkay94]

Btw I haven't seen the difference between slide and slide disabled.

It's subtle but if it's enabled the triangles+text-view slides to the right/left depending on rewind or forward, otherwise it just fades out. It's based on a recommendation from @Stypox :

Maybe an animation to hide arrows+text at the end, by e.g. moving them to the right/left and fading at the same time, would do.

I though I give it a try ;)

[opusforlife2]

@vkay94

With white text the dark background has to be darker to emphasize it better.

Well, first thing I noticed is that with whatever value you've chosen for the shadow, a white video background doesn't matter. The shadow is dark enough that the text can be seen. I tested https://www.youtube.com/watch?v=J3pF2jkQ4vc, and I didn't feel the need for a ripple effect.

---

The video darkens in two stages, with a stutter in between. Is this the delay you were talking about? In the current unified apk, the fast-forward/rewind icon fades out with a similar stutter when you double tap.

---

The fade out animation looks better without Slide to me.

---

I set Controls hide delay to the minimum, and it seems to hide controls at the same time as the seek animation fades out, so that looks great to me. I don't see a reason for a delay.

---

When controls are being shown, double tapping to seek makes the play/pause button fade out and then back in. This is also the behaviour in the current unified apk, but if it is possible to change it, then I think it would look better without any fading.

---

When video controls aren't being shown, double tapping darkens the video to the same extent as when video controls are shown. But when video controls _are_ being shown, double tapping makes it _even darker_. This double darkening is not needed, I think. If player controls are being shown, there is no need for additional darkening when double tapping to seek.

---

When you double tap to seek, before the animation ends, you can single tap to add another 10s (or whatever value you set), which is wanted behaviour. But this single tap can also be done on the opposite side. This feels a bit weird. It allows me to double tap to seek, then alternately single tap on either side to juggle between two timestamps indefinitely.

Maybe the player should ignore a single tap on the opposite side of the screen until the animation fades out? So when you're forwarding using single taps on the right, single tapping on the left would do nothing. You would have to double tap on the left to initiate a rewind.

[opusforlife2]

@B0pol I'm talking about the period after gkeegan's PR changed the guidelines. Otherwise if we look back, then the fast actions UI/UX discussion is another example.

[avently]

Ok, a sliding animation was cool but then I imagined that such animation will be forever and it will be annoying. So, better without it.

When you double tapped, wait less than a second, and animation is not stopped yet, double press again, you will not see a seconds overlay. So in a period of time when first animation is not ended you can't see a new overlay. That's bad.

You can get user selected value for seconds step from settings (video and audio, at the bottom of the page)

I prefer to see a ripple effect INSTEAD of dark background. I thing the dark background should be avoided because it's too intrusive.

[opusforlife2]

if I set both Tap circle alpha and Background circle alpha to 0%

@vkay94 Actually, if I leave Background circle alpha at its default value of 12%, it doesn't look bad at all. Could you show an example with just the arc shape but no ripple?

Edit: And without the darkening of the video as well?

[vkay94]

First of all, thanks for the feedback 👍

Well, first thing I noticed is that with whatever value you've chosen for the shadow, a white video background doesn't matter. The shadow is dark enough that the text can be seen.

Total white background is an edge case + it's a "constant" color. When the video is more "dynamic" then it's a little bit harder I think, for example this: https://www.youtube.com/watch?v=xTJcASRxbfI (I'd be nice if you could give a small feedback on this video, too)

The video darkens in two stages, with a stutter in between. Is this the delay you were talking about? In the current unified apk, the fast-forward/rewind icon fades out with a similar stutter when you double tap.

Yes. The fade-in of the seek-view takes 500ms in the code (now), the fade-out of the controls also 500ms. Depending on the value it "waits", for 0ms it's simultanious, as you've stated already.

When controls are being shown, double tapping to seek makes the play/pause button fade out and then back in. This is also the behaviour in the current unified apk, but if it is possible to change it, then I think it would look better without any fading.

I'm not totally sure (I didn't look it up), but most likely it's due to the player state handling (idle, playing and buffering). This is somewhere else in the core code.

The fade out animation looks better without Slide to me.

Ok, a sliding animation was cool but then I imagined that such animation will be forever and it will be annoying. So, better without it.

Understood, honestly it's easier without it, but I wanted to try it once. Please don't blame me :D

I think. If player controls are being shown, there is no need for additional darkening when double tapping to seek.

I know what you mean and it's better practice to make it "constant". But currently hideControls hides the controls (icons, text, ...) and the shadow together (in XML they are separated). If the other devs agree to separate them (maybe with boolean hideShadow-parameter), I'll definitely look into it.

When you double tap to seek, before the animation ends, you can single tap to add another 10s (or whatever value you set), which is wanted behaviour. But this single tap can also be done on the opposite side. This feels a bit weird. It allows me to double tap to seek, then alternately single tap on either side to juggle between two timestamps indefinitely.

This is 1:1 YouTube behavior, I just kept it, but yeah, I can look into it. What do the other think about it?

When you double tapped, wait less than a second, and animation is not stopped yet, double press again, you will not see a seconds overlay. So in a period of time when first animation is not ended you can't see a new overlay. That's bad.

I didn't notice that, it's indeed not good practice, thanks for the report ;)

I prefer to see a ripple effect INSTEAD of dark background. I thing the dark background should be avoided because it's too intrusive.

Actually, if I leave Background circle alpha at its default value of 12%, it doesn't look bad at all. Could you show an example with just the arc shape but no ripple?

Edit: And without the darkening of the video as well?

This preview version contains only the non-ripple-effect, I'll add it a little bit later. Sorry. Regarding the dark background removal: as described above, when the shadow and controls are separated this can be done easily.

[avently]

@vkay94

Regarding the dark background removal: as described above, when the shadow and controls are separated this can be done easily.

I'm talking about single shadow, not double shadow as @opusforlife2 said about. So right now even when controls are hidden whenever I try to seek with double tap I see the shadow. This shadow is added by you and it's unrelated to controls, isn't it?
So I think would be better to replace it with ripple effect.

[opusforlife2]

I'm talking about single shadow, not double shadow as @opusforlife2 said about

@avently In the sentence he quoted, I'm talking about the single shadow as well. I want to try the arc shape just by itself, no shadow.

(I'd be nice if you could give a small feedback on this video, too)

@vkay94 I don't see a problem with this video either, but this is probably something that we should get additionally tested by people whose vision is impaired. Actually, one default value that we _know_ works well is the one Youtube uses. Google must have done accessibility research and testing. We can just piggy back on that. 🤭

Yes. The fade-in of the seek-view takes 500ms in the code (now), the fade-out of the controls also 500ms. Depending on the value it "waits", for 0ms it's simultanious, as you've stated already.

Your point is about the Controls hide delay, but you replied to the wrong statement. 🤭

The video darkens in two stages, with a stutter in between. Is this the delay you were talking about? In the current unified apk, the fast-forward/rewind icon fades out with a similar stutter when you double tap.

Does this video darkening stutter happen for you?

[vkay94]

@avently

I'm talking about single shadow, not double shadow as @opusforlife2 said about. So right now even when controls are hidden whenever I try to seek with double tap I see the shadow. [...] So I think would be better to replace it with ripple effect.

Am I understanding it that way that you don't want a shadow at all while double tapping? So background arc and scaling circle only?

This shadow is added by you and it's unrelated to controls, isn't it?

Yes, in the latest shared apk there are two shadows (intended by me because I started with exact YouTube behavior and it has two, too).

@opusforlife2

@vkay94 I don't see a problem with this video either, but this is probably something that we should get additionally tested by people whose vision is impaired. Actually, one default value that we know works well is the one Youtube uses. Google must have done accessibility research and testing. We can just piggy back on that. 🤭

When I decompiled the YouTube apk back then the shadow was #70000000 or #77000000 I guess. NewPipe's shadow value is #64000000, so YouTube is slightly darker/less transparent.

Does this video darkening stutter happen for you?

Yes, but there are some reasons:

• it's debug version: not optimized by Proguard e.g. not Log.d stripped
• as previously stated there is some seek delay in the current dev branch (at least for me ...) on some videos. On others it's not that present. In the unified player versions there's much stuff doing in the background. It's pretty hard to fix and I'm not the right person for that ...

Additionally:
Here's a updated version: app-debug-seek-20200913-01.zip

Changes:

• Removed double shadow by moving playerControls's background to a view.
• Removed slide effect
• Optional: Added checkbox for arc shape background (@opusforlife2)
• Optional: Added checkbox for tap scaling animation (@avently) (works only in combination with arc shape)

Notes:
Multiple fading animations are hard to handle to make it looking great (controls and shadow). When the video is playing all animations should work fine whether the controls are visible or not. When the video is paused there might be some race condition due to buffering (there is somewhere an showControls / hideControls triggered on buffering)

[opusforlife2]

Am I understanding it that way that you don't want a shadow at all while double tapping? So background arc and scaling circle only?

Me too. No shadow at all. Just a background arc.

so YouTube is slightly darker/less transparent.

Should we keep the same value as Youtube, then?

Edit:

• Somehow, the play/pause button disappearing and reappearing is fixed in this build.
• Double shadow is gone when seeking while controls are showing, and it looks much better.
• Tried both arc shape and scaling animation. Arc shape looks nice by itself. I suspect it would look even better without the shadow. Scaling animation, on the other hand, is distracting.

[opusforlife2]

Your latest apk was open. Display eventually turned off. When I opened the phone later, got a crash:

Exception

• __User Action:__ ui error
• __Request:__ App crash, UI failure
• __Content Country:__ IN
• __Content Language:__ en-IN
• __App Language:__ en_IN
• __Service:__ none
• __Version:__ 0.19.8
• __OS:__ Linux Android 9 - 28
  
  Crash log

android.app.RemoteServiceException: Context.startForegroundService() did not then call Service.startForeground(): ServiceRecord{e0d9dd2 u0 org.schabi.newpipe.debug.seek/org.schabi.newpipe.player.MainPlayer}
    at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1745)
    at android.os.Handler.dispatchMessage(Handler.java:106)
    at android.os.Looper.loop(Looper.java:193)
    at android.app.ActivityThread.main(ActivityThread.java:6718)
    at java.lang.reflect.Method.invoke(Native Method)
    at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:491)
    at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:858)

---

[avently]

@opusforlife2 didn't know you are from India

[opusforlife2]

@avently What was your guess?

[avently]

@opusforlife2 from Europe, maybe France. Without reason to think so actually.

[opusforlife2]

Makes sense. Mostly everyone else is from West Europe.

[Stypox]

@opusforlife2 that seems unrelated from this features, it's more something having to do with notification that should have been fixed by # 3178

[avently]

Based on the latest apk:

• show arc shape enabled is good
• dark background is still visible for some reason, I thought you'll remove it, better to remove
• show scaling tap circle disabled is ok
• the overlay is showing too long time. So when the video is already playing after seek I still see the overlay. Delay should be shorter s little bit
• arc shape has different curve angle based on the player height which is not good because in landscape NON-fullscreen and fullscreen the shape is different. So maybe would be better to have identical curve on any heights
• there is still a problem related to not showing the overlay when you double tap the player while the overlay is in hiding process.

[vkay94]

Thanks for the feedback ;)

[...] Scaling animation, on the other hand, is distracting.

show scaling tap circle disabled is ok

So I'll remove the scaling animation and keep the arc shape only as an option. I wanted to make it sure for you @avently ;)

dark background is still visible for some reason, I thought you'll remove it, better to remove

It is still intended in this version. I removed the double shadow but kept the single one. I asked for a clarification in the post above and shared the new version at the same time to show you the single shadow, arc shape and scale animation. I'll add an option to disable the shadow while seeking in the next version.

the overlay is showing too long time. So when the video is already playing after seek I still see the overlay. Delay should be shorter s little bit

arc shape has different curve angle based on the player height which is not good because in landscape NON-fullscreen and fullscreen the shape is different. So maybe would be better to have identical curve on any heights

Regarding the angle: I'm aware of that from the beginning but in the moment it's fine-tuning. It can be adjusted via resources or code. I haven't thought about a formula yet depending on the video height.
Regarding the timings: that's also fine-tuning. I have set them a little bit higher for the preview, but yeah, I can set it a little bit shorter in the next version for demonstration (or I'll add an slider like I did for the controls hide delay).

there is still a problem related to not showing the overlay when you double tap the player while the overlay is in hiding process.

I know and I didn't looked into it yet. I write everything what is changed/fixed/added into the changelist.

[MD77MD]

what do you guys think if the (text, triangle..) were show in the middle close to what's used now... I mean it's easier to see and wouldn't be blocked by our fingers tapping... think about it

i even think it would work better with ripples because its a bit away, not in the middle of the ripples, so less destructive

[vkay94]

@MD77MD For me, I wouldn't handle it that way because I can imagine it and it wouldn't look well from an opinion of an UI/UX developer :)

• When changing the triangles direction (switching from forward to rewind vise versa) it would distract if it's in the same place
• The combination of the ripple animation and seek status would result in two focus points ("Where should the user look at? The ripples or current seeking seconds?" (If there are near each other it's okay => YouTube handles it that way so they have thought about it ;) )) - same goes for arc shape + text: the shape would "cut" it.

In the end it's my opinion and I'm not at any position to determine - just my thoughts :)

[opusforlife2]

You can see it interferes with the play/pause button animation all the time. I think having separate positions is better.

[vkay94]

Small update from me: app-debug-seek-20200915-02.zip

Changed:

• Removed: Checkbox for ripple animation
• Added: Checkbox for enabling/disabling shadow during double tap seeking
• Fixed: Not re-appearing of the view during hiding/fade-out process (@avently )
• Changed: Reduced durations of hidings/showings a little bit
• Improved general alpha animations (e.g. more fluid alpha animation when fast hiding/showing controls) *

I recommend to try it on these videos: https://www.youtube.com/watch?v=xTJcASRxbfI and https://www.youtube.com/watch?v=pXRviuL6vMY

*@Stypox I assume you're responsible for the UI stuff, am I right? (You've been the first member who answered :')). I did changes to AnimationUtils#animateView to make it smoother. Could you check something for me and give me your opinion? Please open any video and press really fast and often on the arrow icon to the right. The secondary controls shouldn't expand completely sometimes. What do you think about this combination of slide and alpha?

[opusforlife2]

A couple of regressions from the previous build:

First is that when the video is paused, player controls are showing with the accompanying shadow and you double tap, the darkness disappears and then returns after the seek animation is finished. The previous build worked perfectly in this case.

When the video is playing with controls showing, the darkness abruptly goes away and the screen becomes bright instantly instead of gradually, which is uncomfortable to look at.

Changed: Reduced durations of hidings/showings a little bit

Now the animation is jerky. The arc shape, text and triangles just appear on screen instead of fading in. Not just that, the animation often lags behind the skip. You're already watching 10 seconds ahead and the arc shape suddenly appears. The fade in/fade out durations in the previous build were better. The current values are making it look like Newpipe is responding late to user input.

The above stuff is much more noticeable on a 60 Hz video. Try this: https://www.youtube.com/watch?v=6notqS434xg

Apart from that,

Added: Checkbox for enabling/disabling shadow during double tap seeking

Definitely looks better without the shadow. The arc shape is enough on its own.

Fixed: Not re-appearing of the view during hiding/fade-out process

It's difficult to test this because the durations are too short.

[vkay94]

First is that when the video is paused, player controls are showing with the accompanying shadow and you double tap, the darkness disappears and then returns after the seek animation is finished. The previous build worked perfectly in this case.

Okay, I can set it that way (keep shadow when paused) (I like the shadow anyway, I wanted to give you the opportunity to test this case, thanks for the feedback).

When the video is playing with controls showing, the darkness abruptly goes away and the screen becomes bright instantly instead of gradually, which is uncomfortable to look at.

I reduced them in this build on request of avently for testing:

the overlay is showing too long time. So when the video is already playing after seek I still see the overlay. Delay should be shorter s little bit

The above stuff is much more noticeable on a 60 Hz video. Try this: https://www.youtube.com/watch?v=6notqS434xg

Nah, that's a hard video. Could you confirm something for me? As I've told often, many videos have a noticeable seek delay in the dev branch. Can you install the latest unified player test apk and test this video? Just press somewhere on the seekbar and check if there is a delay. If yes, it does many work on the main thread => jerky.

It's difficult to test this because the durations are too short.

I increased the fade animation and it was fixed on my temporarily build :)

[opusforlife2]

Nah, that's a hard video. Could you confirm something for me? As I've told often, many videos have a noticeable seek delay in the dev branch. Can you install the latest unified player test apk and test this video? Just press somewhere on the seekbar and check if there is a delay. If yes, it does many work on the main thread => jerky.

Actually, for me, seeking to a non-preloaded part takes 3-4 seconds, whether it is this video, another 60 Hz video, or even a 30 Hz video.

When seeking to a preloaded part, the delay is roughly the same for me between 60 and 30 Hz videos.

[vkay94]

Same applies to me except of very few videos. That's why I recommended the two videos I've shared because they haven't this heavy delay (for me), neither on my debug build nor on the unified player test apk. I really can't tell why.

[opusforlife2]

Let's test again after avently's performance PR is merged.

[vkay94]

Update: app-debug-seek-20200924_01.zip

Added:

• Stop animation when video start/end is reached (no endless animation)
• [Needs color adjustments] Added Checkbox to switch between light grey and dark arc shape color. This setting will be applied if the video is currently playing and background shadow is disabled.

Changed:

• Trigger seek-Callback on Action_Down (previously Action_Up like YouTube). It may feel a little bit "faster" because the animation won't wait until you lift your finger.
• Switch from forward to rewind (vice versa) requires double tap, so no "fast switching" possible.
• Call seekBy-method only during fade-out animation instead of each tap (UI becomes less jerky). During the animation the playback stops - similar to dragging the seekBar. This could be rolled back when the notification and player improvements are merged and the general UI performance is satisfying with the changes.
• If the video is stopped, in every case the shadow stays and the arc background (if enabled) is light grey (with higher transparency).

Improved

• Arc shape is now dynamically adjusted to video height.

Fixed:

• Controls don't appear suddenly during double tapping (hopefully)

Note: I disabled all notification updates for now due to performance issues for videos with high resolution thumbnail (wait for notification/performance PRs).

[opusforlife2]

Stop animation when video start/end is reached (no endless animation)

I didn't see this issue with the previous build. How did it occur?

Switch from forward to rewind (vice versa) requires double tap, so no "fast switching" possible.

Works as expected! Thanks!

If the video is stopped, in every case the shadow stays and the arc background (if enabled) is light grey (with higher transparency).

Looks better now. 👍

Trigger seek-Callback on Action_Down (previously Action_Up like YouTube). It may feel a little bit "faster" because the animation won't wait until you lift your finger.

It does indeed feel more fluid. Good thinking.

Added Checkbox to switch between light grey and dark arc shape color.

Dark is better! But now we have dark for when video is playing and light for when video is paused. Shouldn't both be dark for consistency?

Call seekBy-method only during fade-out animation instead of each tap (UI becomes less jerky). During the animation the playback stops - similar to dragging the seekBar.

Yup. The stutter is gone. The animation is perfectly smooth now. Even in the previous build, if the video was buffering, the animation would be smooth. It was only when you were seeking and the video would immediately play after that the animation would stutter.

[avently]

I like the latest version. Arc radius is consistent in non/fullscreen mode, no delays, fast show/hide, overlay always appears when you end previous sequence of taps and start a new one. Darker is more universal: it's ok on dark and light videos, but white is not ok on light videos. So dark is preferred "theme".
It looks and works great

[vkay94]

Thanks for the feedback ;)

I didn't see this issue with the previous build. How did it occur?

Basically it happened every time because there was no check for the player position (UI/UX was/is my prior in this phase). For example if the video was at 00:25 und you had fast rewinded, the animation wouldn't stop at 30 seconds but keep going until you stop tapping.

Works as expected! Thanks!

Glad to hear that .D

Dark is better! But now we have dark for when video is playing and light for when video is paused. Shouldn't both be dark for consistency?

Darker is more universal: it's ok on dark and light videos, but white is not ok on light videos. So dark is preferred "theme".

I thought of this dark option at the very end while searching for a satisfying light (grey) color for light and dark videos (but there is none which fits both cases if shadow is disabled), so I relied on your reactions. Thanks for that 👍

Regarding themes: I've already planned predefined themes which could be selected/adjusted in preferences. I will implement such »picker« in the next version (due to your feedback I know which combinations would fit and which not).

[opusforlife2]

Glad to hear that .D

Oh no, you lost an eye. :O

[Stypox]

@vkay94 thank you for your efforts! The latest behaviour with the default settings feels really polished in my opinion. I think this is ready for review, so feel free to open a PR whenever you want ;-)
(The settings menu is not going to be there in the actual release, is it? Did I understand correctly?)

[vkay94]

@Stypox Thanks!

I think this is ready for review, so feel free to open a PR whenever you want ;-)

Nice to hear that :). I decided to wait until #3178 and #4288 are merged into dev, so I could put it on top of the changes because this feature request depends on them (I disabled the notification to make it even usable).

(The settings menu is not going to be there in the actual release, is it? Did I understand correctly?)

It isn't but I'm working on it this weekend. Here is the current status: https://streamable.com/e/owvdnr
I think this way it isn't too intrusive, is it?

[Stypox]

@vkay94

I decided to wait until #3178 and #4288 are merged into dev, so I could put it on top of the changes because this feature request depends on them

Yeah, good idea

I think this way it isn't too intrusive, is it?

It definitely isn't, though I am concerned about who would benefit from having these so-specific and niche settings. Isn't the default behaviour acceptable for anyone? Adding more settings is always a problem because things need to be tested in more configurations and users could enable them by accident and not find a way to restore them. So in NewPipe we usually add settings only when they do really provide a value, and in my humble opinion UI adjustments for really small things do not fit. @B0pol @opusforlife2 what do you think?

[opusforlife2]

Right now the Seek settings menu is fluctuating because new things are being tried every build. Once we settle on a set of good defaults, we can see if we need any settings at all, and if so, where to put them.

[vkay94]

@Stypox When I opened this issue and shared a first video everyone hated the ripple and arc shape - now the dark arc is good to go ^^
I agree with you that a solid default should be enough for NewPipe. We just have to find it (that's why there are so many configurations). For now, I'll stop on the setting.

To clarify: Arc shape is fine in any case?

I'll make three "themes" to choose from and add them to the next build:

• Current Default:

  • Playing: No shadow, dark arc
  • Paused: Shadow, light transparent arc

• Dark themed:

  • Playing: No shadow, dark arc
  • Paused: Shadow, dark transparent arc

• Light themed:

  • Playing: Shadow, light transparent arc
  • Paused: Shadow, light transparent arc

What do you think?

[vkay94]

Update: app-debug-seek_20200929_01.zip

Improved

• Localization: Use of NewPipe's seconds-string, so the text is now applied to app's selected language.
• Merge all commits to date including Notification and Performance improvements.

Changed

• Removed configurations in favor of predefined themes: Default, Dark, Light and No Arc

In all themes- except No Arc - an arc is visible. In case of Dark theme and paused the additional arc color is more transparent.
Background of this addition is thinking of an indicator as "arc shape + text".

Let me know which theme suits you most ;)

[opusforlife2]

This could be rolled back when the notification and player improvements are merged and the general UI performance is satisfying with the changes.

Did you roll this back? I think it's still there.

Let me know which theme suits you most ;)

DARK THEME FOR LIFE.

[Stypox]

The default theme is the one I prefer, since the arc is dark while playing (thus not disturbing), but is white while paused (otherwise it can barely be seen in combination with the darkened background)

[TobiGr]

I suggest to use the dark background, because otherwise one cannot read the white text on white background.

Btw. I do not suggest to put a theme chooser into the player itself. The player UI is already cluttered, overloaded and missing simplicity.

[vkay94]

Did you roll this back? I think it's still there.

@opusforlife2 I hadn't changed it, my focus lied on merging and adjusting my changes according to them. Here is a build which has a checkBox to enable seek-callback on each tap: app-seek_20200929_02.zip

I've also included a signed/optimized version which runs perfectly smooth I guess (well, the debug does too), thanks to @avently and @Stypox ;)

DARK THEME FOR LIFE.

The default theme is the one I prefer

I suggest to use the dark background

I saw it coming xD I prefer the dark background too (=> Light or probably Shadow + dark transparent during playback :')),

Btw. I do not suggest to put a theme chooser into the player itself.

@TobiGr This dialog is just for debugging and giving the opportunity to test different combinations. In case of theming is wanted sometime I though about putting it into the settings (Video & Audio -> Skip duration) - the modified ListPreference should be still in there.

[opusforlife2]

Wait, what? The function you were talking about earlier wasn't seek-callback.

Call seekBy-method only during fade-out animation instead of each tap (UI becomes less jerky). During the animation the playback stops - similar to dragging the seekBar. This could be rolled back when the notification and player improvements are merged and the general UI performance is satisfying with the changes.

[vkay94]

@opusforlife2 Whoops, my bad - whenever I read performance I think about seek-callbacks xD

Here is a version where you can toggle whether the playback should stop or not:
app-release-signed-seek_20200930_01.zip

The performance on debug-level is not so good and there may occur the problem that the video already plays while the animation is still fully visible. avently has criticized it back then which is indeed not good. One solution would be to reduce the durations. Check it for yourself.

Sorry again for the misunderstanding.

[opusforlife2]

Looks perfect now! The stutter in the animation is gone, from my testing, so if others agree, you could go ahead and make it the default again. The pause in playback takes away from the buttery smoothness of the whole thing.

[vkay94]

@opusforlife2 Okay, I'll set it to the default (well, you and Stypox are the only ones who reacted :')). Out of curiosity I've checked YouTube and they keep playing, too. And it has its benefits: the video buffers instantly.

[vkay94]

Small update: app-seek_20201006_01.zip

Changed

• Added new predefined theme: Dark2. Basically it's the same as Light but with the dark transparent color for the arc shape (it's my favorite alongside the Light, give it a try ;)).
• Reduced the delay for the first seekBy-Call. **

** In other words: Instead of waiting for the complete animation (fade in to start of fade out) while stopping the playback, now the first seek-Call occurs after the fade-in.

The background of this is to ensure fluidity of the UI. Multiple seek-Calls have an impact which excels in a jerky fade-in animation - most noticeable when tapping on a white background video. To counteract this I've included a Runnable which delays until the fade-in animation is finished (400ms to be exact), then ongoing it checks periodically every 200ms if it should call the seek-Call or not until the animation is completed.

On high-end devices this wouldn't do any change, but on less performant devices it is better. But you won't notice this delay while seeking, it should be as fast as without a delay (but the small exceptions do the most work :))

Starting from here, despite of the choice of a default configuration, I start on inserting it into NewPipe's coding styles/code => enabling checkStyles - hooray, thousands of "Use a final for xyz".errors, luckily in Kotlin there is no such style check :D

[opusforlife2]

The delay after double tapping is back again. It was absent in the previous build, which was perfect. :/

[vkay94]

@opusforlife2 Is it so noticeable? (There might be also a delay because of the buffering, but it should be definitively faster than the first approach (waiting for the animation to fade out)).
Compared to the current official way it is, I admire that, but the scaling animation of the circle is an other one (not AnimationUtils#animateView which I have to use (I guess) since it's used for other views like the controls, too).

The reason has to lie in the combination of "animateView + seekBy" because
a) while debugging I disabled every UI update calls (Notifications, onProgressUpdate, ...) except them and
b) I don't encounter this UI jerky stuff on my other projects when using LayoutTransition/animateLayoutChanges

I might try to write a "special animation" for this, but don't expect any result in the next time. This requires more debugging and currently I need a break from this fine-tuning - that's why I tried myself on an other issue ;)

I'm sorry that it doesn't satisfy your expections :(

[opusforlife2]

Wait wait wait wait wait. To be clear, I'm referring to this,

Here is a version where you can toggle whether the playback should stop or not:

and not to any lag or jitter. There is none. I just miss the zero delay between the double tap and the video playing.

[vkay94]

Okay, that's totally a pain in the a**. It looks like I've messed something up somewhere after merging the performance changes from the upstream back then ...
So just ignore the previous comments. When it's fixed with the upstream I start to create the Pull Request.

[opusforlife2]

It's good I took a backup of the perfect build, then. :P

[vkay94]

Thanks for calling it a perfect build :D

Aside from the Video-PlayerType there is the Popup which should be handled, too, so some stuff needs to be adjusted.
For example scaling text/icon sizes - currently it's always the same which results in linebreaks for small windows. Or falling back to the current official circle scaling animation (visual) when the popup is very small (should be done easily and doesn't sound absurd, right?).

But firstly I want to make a solid version (PR draft) which I can easily revert to (= no huge upstream merges in between).

[avently]

XML changes were merged. Happy merging :)