[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.

[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 :)