Bug 190844 - [Gtk] YouTube speed control doesn't work, seek unreliable
Summary: [Gtk] YouTube speed control doesn't work, seek unreliable
Status: RESOLVED DUPLICATE of bug 208454
Alias: None
Product: WebKit
Classification: Unclassified
Component: Media (show other bugs)
Version: Other
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-10-23 14:50 PDT by erusan
Modified: 2020-04-07 04:14 PDT (History)
3 users (show)

See Also:


Attachments
Player jumps to end of video when seek bar shows I clicked towards the middle of the video (807.41 KB, image/png)
2018-10-23 14:50 PDT, erusan
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description erusan 2018-10-23 14:50:58 PDT
Created attachment 352996 [details]
Player jumps to end of video when seek bar shows I clicked towards the middle of the video

Recently, YouTube videos have been wonky. The most predictable behavior is speed control -- it simply has no effect anymore, ever.

Other behavior that is hard to reproduce involves seeking. Sometimes a video jumps to the end, or clicking ahead in a video shows the end of the video instead. Some playback has been generally unreliable, including a video crashing or simply refusing to buffer or play.

Firefox does not exhibit this problem, nor do external players like mpv.

I've attached a screenshot showing the seek bar where I clicked backwards in a video and was taken to the end of the video, with the autoplay countdown spinner working as well (so it believes it is at the end of the video and YouTube is going to play the next), despite the seek bar showing that I clicked nowhere near the end.

Debian testing
Epiphany 3.30.1
Webkit 2.22.2
gstreamer 1.14.4-1
Comment 1 Alicia Boya García 2018-11-22 11:08:44 PST
Recently YouTube stopped supporting playback of WebM sources without MediaSource Extensions, so we had to enable it, which was previously a experimental feature. Even if it looks like the same YouTube, what is behind the scenes it's actually very different.

MSE is still a bit rough around the edges. For instance, speed control is not implemented yet: it should not be very complicated to add, so hopefully it will be added soon-ish.

There are still some bugs that can be hit when seeking or changing video quality and these are quite hard to investigate because of the many layers and variables that MSE introduces, so if you find one, it would be extremely helpful for developers if you were able to go back, repeat the action that triggered the bug and provide a detailed sequence of steps that reproduces it (e.g. open this video, seek to 1:20, then wait 5 seconds, then seek to 2:00 when it's still marked as unbuffered, then this will happen...). I know it's not always possible, but when it is, it's extremely helpful.

Also, make sure to run the latest WebKitGTK version, since we are actively releasing bugfixes and improvements. In particular, just the immediate next version to the one you are running has many MSE-related improvements and it's already packaged in Debian testing. https://webkitgtk.org/2018/10/29/webkitgtk2.22.3-released.html

It's also important to run updated GStreamer, since new WebKitGTK versions may require updated versions of GStreamer, but your distro should already handle that for you.
Comment 2 Philippe Normand 2020-04-07 04:14:14 PDT
Playback rate control should now work. No need to open a new bug about seek issues.

*** This bug has been marked as a duplicate of bug 208454 ***