bug(YouTube - Video speed): Do not apply non 1.0x default playback speed when watching live streams

[SodaWithoutSparkles]

Type

Error at runtime

Bug description

Using remember playback rate when watching livestreams will cause the livestream to buffer

Steps to reproduce

1. Watch any video that is not a livestream
2. Set the playback rate to something ridiculous (5x)
3. Exit that video
4. Watch a livestream such as this
5. Buffering will happen in less than 2 minutes even if you have good connection
6. Repeat from step 1 but choose something normal like 2x, observe that the issue still happens but slower
7. the latency row in stats for nerds will give more information

Relevant log output

Not relevant: this is a logic issue

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

• I have searched the existing issues and this is a new and no duplicate or related to another open issue.
• I have written a short but informative title.
• I filled out all of the requested information in this issue properly.

[philklc]

+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).

[SodaWithoutSparkles]

@philklc Your approach is better.

[HunterAPI]

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.

[LisoUseInAIKyrios]

@HunterAPI there's an existing request for such functionality #1458

[LisoUseInAIKyrios]

@oSumAtrIX this request is different from the other issue I mentioned.

[oSumAtrIX]

They should be combined, essentially the same feature: "Disable for specific video categories".

[HunterAPI]

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

[m-sundman]

They should be combined, essentially the same feature: "Disable for specific video categories".

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

[oSumAtrIX]

The category is livestream.

[YT-Advanced]

@oSumAtrIX @LisoUseInAIKyrios For livestream, you can use videocpn instead of videoidhook to check if a video is livestream or not.

[oSumAtrIX]

Please give detailed information, cryptic messages like this are difficult to understand.

[YT-Advanced]

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

inotia00/revanced-patches@78e86a1

[m-sundman]

The category is livestream.

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.

[oSumAtrIX]

@m-sundman This is exactly the issue described in ReVanced/revanced-patches-template#1262

Using remember playback rate when watching livestreams will cause the livestream to buffer

And the solution you describe is described in ReVanced/revanced-patches-template#1262

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

[SodaWithoutSparkles]

What @m-sundman is describing is another solution to the same issue.

Lets clarify the terms a bit.

• Normal video: videos that are uploaded
• livestreams: videos that have their length extended every second
• watching live: watching livestreams very close to real-time
• not watching live: watching livestreams but not close to real-time
• stream recaps: videos that youtube autonatically generate from completed livestreams, functions as normal video

---

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

[m-sundman]

And the solution you describe is described in ReVanced/revanced-patches-template#1262

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

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

Solution 2 is obviously more complicated, but it has a higher degree of automation, and i agree that it is better

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.

[oSumAtrIX]

It is complicated to implement is what he is referring to.

[SodaWithoutSparkles]

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

...

if(isLiveStream(video)):
  # do nothing
  return

...

Solution 2

...

func handleNotLive():
  setPlaybackSpeed(default)
  return
func handleLive()
  setPlaybackSpeed(1.0)
  return
addListener(timestampDecrease, handleNotLive)
addListener(videoAtLive, handleLive)

...

[m-sundman]

I do mean it is more complicated to implement.

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.

[oSumAtrIX]

@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

[SodaWithoutSparkles]

You contradict yourself though because you say you do not mean the implementation is more complicated while showing that the implementation is more complicated.

Read again...

I do mean it is more complicated to implement.

[oSumAtrIX]

I already know, the comment was marked as hidden for that reason before you commented.

[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

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.
And why are you being so hostile anyway?

[oSumAtrIX]

The pseudocode does not reflect the implementation difficulty. I am not trying to sound hostile if that looks like I do.

[m-sundman]

https://github.com/ReVanced/revanced-patches/blob/main/src/main/kotlin/app/revanced/patches/youtube/video/speed/remember/patch/RememberPlaybackSpeedPatch.kt
Is this the file in question?
At least at first glance it's not apparent to me exactly how it works.

[oSumAtrIX]

Yeah, also the corresponding integrations.

[Shubham8050]

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