-
-
Notifications
You must be signed in to change notification settings - Fork 267
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bug(YouTube - Video speed): Do not apply non 1.0x default playback speed when watching live streams #1262
Comments
+1, but the original YouTube does it best: it lets you use higher playback speeds until there is nothing to catch up, then it reverts back to 1x speed. The remember playback speed patch should check for this behavior and allow automatically returning the speed to 1x in this case (live streams and premiere videos). |
@philklc Your approach is better. |
Can this patch also have the ability to disable the custom playback speed for videos that are songs? Maybe with a prompt at the start for the video like asking if you'd like to play the video at 1x if it detects it as a song. If you go into the description of a music video, it shows information about it. You can use that to figure out if it's a song, I guess. |
@HunterAPI there's an existing request for such functionality #1458 |
@oSumAtrIX this request is different from the other issue I mentioned. |
They should be combined, essentially the same feature: "Disable for specific video categories". |
There's a YouTube feature where you tap and hold the video and it changes the playback speed to 2x with a label in the middle saying "Playing at 2x speed" until you let go. There should also be an option to set a custom speed for the "fast forward". |
No, this ticket is not about disabling the custom speed for the live video. It's about disabling the custom speed while watching live. This is not a video category, but a playback state. (Also, this bug is driving me crazy, because it requires me to constantly change the speed when switching between videos.) |
The category is livestream. |
@oSumAtrIX @LisoUseInAIKyrios For livestream, you can use videocpn instead of videoidhook to check if a video is livestream or not. |
Please give detailed information, cryptic messages like this are difficult to understand. |
By default, Revanced use videoidhook to check, when new video open, it called Playback Speed Patch to notify that new video loaded. But it mean livestream video will be applied default playback speed too. To solve this problem, you should use videocpn (check the commit below) because only normal video be called when use videocpn |
No. Read again. Just because a video is "livestream" doesn't mean that we don't want to use the default speed. We still want to use the default speed even for livestream videos. However, we want to use normal playback speed when we are watching live. You can watch a livestream live or not live. Do you see the difference between a "livestream video" and "watching live"? E.g., I open a livestream and jump to the beginning of it. The speed should be the default one. Once I catch up to live then it will transition to playing at normal speed. Then I pause for a couple of minutes, and when I resume it should again be playing at default speed, again until it catches up to live, and then it would again play at normal speed. Basically, whenever that red "live" dot is lit it should be playing at normal speed, and otherwise at the default speed. |
@m-sundman This is exactly the issue described in ReVanced/revanced-patches-template#1262
And the solution you describe is described in ReVanced/revanced-patches-template#1262
|
What @m-sundman is describing is another solution to the same issue. Lets clarify the terms a bit.
Using "remember playback speed" on livestreams does not automatically make it buffer. Suppose the situation is like this: a livestream started 2 hrs ago, and i now watch it, with playback speed defaulted to 2x by the patch. Now there are 5 seconds left (youtube will consider a short enough buffer to be "watching live") and i play at 2x, so i will catch-up in 2.5 seconds. Then because the buffer is too short, it wait for a new segment, and i consumes the new segment in 1/2 of the time, the cycle repeats, hence the buffer. So the solution (1) is not to apply the 2x speed and leave it at the 5 seconds. But the downside is i have to manaully change the speed back to 2x if i wanna watch the livestream from 2hrs ago to catch up from behind (not watching live). Hence the solution (2) sundman proposed: Don't apply the 2x speed automatically if clicked on a livestream, check if i am watching it live first. If so, don't apply the 2x speed. When I go back to watch the 2hrs that i missed, it should apply the 2x speed as it won't have any buffering issues. Essentially, if timestamp of the livestream decreased, playback speed should be applied (2x), until buffer nearly runs out (i.e. Watching live), then the patch should kick in once again to make the playback speed be 1x to avoid the buffer. Solution 2 is obviously more complicated, but it has a higher degree of automation, and i agree that it is better (https://github.com/ReVanced/revanced-patches-template/issues/1262). |
Yes, the proposed solution is the same as I'm describing. He's literally saying that it should NOT force 1x just because it's a livestream, but only when actually watching live (i.e., at the very end of the livestream while that's being appended to).
Is it that much more complicated, tho? I mean, the player obviously knows when it's live, and when it's playing the past of the livestream, because of that little red dot that lights up whenever it's playing live. So why not just force 1x speed whenever that little dot turns red, and then go back to the chosen speed when the dot turns grey again? No complications needed, really. |
It is complicated to implement is what he is referring to. |
I do mean it is more complicated to implement. For solution 1 only a simple check has to be implemented. For solution 2 a new logic flow has to be created. The following is some pseudocode i imagined. Solution 1
Solution 2
|
This comment was marked as resolved.
This comment was marked as resolved.
Your solution 2 is not that much more complicated than your solution 1 (which might actually be a bit wrong, since that "# do nothing" should actually be "setPlaybackSpeed(1.0)" (well, depending on the implementation)). It's very insignificantly more complicated. Also, I'm pretty sure that's how youtube normally operates, is it not? At least it's how vanced used to work. I always use higher speed, and it always used to switch to 1x when I caught up to live. Only fairly recently have I encountered this problem where it tries to use the higher speed despite being live, and it's really, really annoying. |
@m-sundman I don't think you can asses the implementation difficulty at all, otherwise I suggest to open a PR in case you want to |
Read again...
|
I already know, the comment was marked as hidden for that reason before you commented. |
I can perfectly well assess the pseudocode in @SodaWithoutSparkles comment https://github.com/ReVanced/revanced-patches-template/issues/1262 and as for assessing the real code I never attempted it, but if you'd read what I write, as I've asked repeatedly, you'd notice that I asked if it really is that much more complicated, considering it's youtube's default behavior (AFAIK), and seems to have existing signal/listener connection points where it might be easy to integrate. |
The pseudocode does not reflect the implementation difficulty. I am not trying to sound hostile if that looks like I do. |
https://github.com/ReVanced/revanced-patches/blob/main/src/main/kotlin/app/revanced/patches/youtube/video/speed/remember/patch/RememberPlaybackSpeedPatch.kt |
Yeah, also the corresponding integrations. |
This comment was marked as spam.
This comment was marked as spam.
I am using the revanced extended version by @inotia00. This bug does not appear in that. During live videos we can change the playback speed to 2x or more and it automatically switches to 1x. Sadly he has archived the repository on Jan 27. https://github.com/inotia00/revanced-patches/tree/revanced-extended/src/main/kotlin/app/revanced/patches/youtube/video |
It is a silly request. This doesn't stop the world or anything. Takes 1 second to switch the speed back. |
It's annoying though |
Type
Error at runtime
Bug description
Using remember playback rate when watching livestreams will cause the livestream to buffer
Steps to reproduce
Relevant log output
Screenshots or videos
No response
Solution
When clicking to the livestream, reset to 1x speed, but do not force 1x the entire time, as people may want to catch on from behind with higher playback rate
Additional context
No response
Acknowledgements
The text was updated successfully, but these errors were encountered: