System:
Operating System: Fedora 36 (with Gnome on Wayland)
CPU: AMD Ryzen 7 3700X
GPU: AMD Radeon RX 5700 XT
Gnome Web version: 42.2
WebKitGTK version: 2.38.0
Scrubbing a video, either by using the arrow keys to jump forward and backward, or by using the timeline, will cause the video to freeze entirely. This has been a long-standing issue that has affected WebKitGTK for as long as I can remember going as far back as 2018 when I first started testing it. It is not 100% easily reproducible, and seems to happen somewhat sporadically. I recommend signing into your YouTube account on Gnome Web and then setting aside some time to watch your favorite YouTube content. As you watch, occasionally jump back a few seconds, then maybe adjust the timeline with the cursor. This is bound to inevitably cause this issue to present itself. Again, it cannot be reproduced reliably, but will 100% happen if you are trying to interact with videos in any meaningful way. It happens every once in a while, and there is no guarantee it will happen at all the first try.
The procedure to reproduce generally goes like this, I am watching a video on YouTube, Odysee, or some other social media site such as Reddit. I may bounce back a few seconds by using the arrow keys. I may use "J" and "L" to bounce back and forward even faster. I may then press play and encounter a buffering error or a frozen webpage. I also may bounce through the timeline using these keys, followed by a timeline scroll with my mouse that completely crashes or freezes the video playback or webpage. I also may encounter it by clicking around the timeline to different sections of the video until it crashes or freezes. It is not an uncommon bug, but it is not usually so prevalent that it makes the browser unusable. However, sometimes it is and will render video streaming impossible.
Please try with:
export GST_DEBUG="3,webkit*:6" GST_DEBUG_FILE="$HOME/gst.log" GST_DEBUG_NO_COLOR=1 WEBKIT_FORCE_SANDBOX=0
Try to reproduce the bug immediately after starting the browser, doing as little as possible so that the log is as short as possible. Then attach the gst.log.
Created attachment 463369[details]
gst log of youtube playing, delaying beginning of playback, freezing when video is rewound, reloading the video
Here is a log of a YouTube video. It's hard to replicate bugs, since they're not necessarily consistent.
The video played here is: https://www.youtube.com/watch?v=be4sgH2T41I
What I did was:
- play the video (it delayed at the start, with the throbber spinning for several seconds).
- use the arrow keys to move forward (it seemed to handle this fine)
- use arrow keys to move backwards (it seemed to handle this fine, but often does not)
- click backwards (video froze, throbber spun, eventually the video reloaded to thumbnail screen at the time I had rewound the video to)
- I think I repeated the rewinding bug
Hope this helps
Debian testing
Web 43.0
WebkitGtk 2.38.1
Created attachment 463370[details]
Odysee playback issues
Here is a log with Odysee. The player functioned alright at first, then rewinding made it repeat audio. Then I changed playback speed, and rewound, and the video froze, audio played in short segments (seemingly jumping forward between each short segment) while the video was frozen, then the audio stopped playing.
The logs shows underrun warnings in the audio sink... Do you use Pipewire?
native PulseAudio? What is your GStreamer version?
I already commented in https://bugs.webkit.org/show_bug.cgi?id=245850 (why is there 2 bug reports?) that I can't reproduce this issue in Ephy TP. Can you?
I think OP created multiple bug reports because the first bug (#245850) contained "multiple bugs".
I am running pipewire, as I believe it is Debian's default configuration
pipewire 0.3.59-1+b1
gstreamer 1.20.3
I haven't repeated the Odysee issue using the TP flatpak, but the process leaking is causing memory issues for me, so I'll have to try it when I can dedicate my machine to just this task.
Created attachment 465672[details]
Odysee playback bugging out
At 30 sec you can see the video begin to do very jittery playback, the seek bar shows rapid progression. What you can't hear is the audio playing for a short while at this point, and then stopping.
At 56 sec you see the beginning of the video freeze, which does not recover. Clicking to a new point on the seek bar might load a new frame, but playback never resumes, despite the video being buffered.
(In reply to erusan from comment #9)
> YouTube seems fixed with Web 44, WebKitGTK 2.40.0, GStreamer 1.22.0 (so long
> as user is logged out?).
>
Please file another bug, YT should work wether you're logged or not.
> Odysee playback remains buggy.
We need logs and pipeline dumps, see the instructions in https://bugs.webkit.org/show_bug.cgi?id=245852#c1
Created attachment 469492[details]
See 11 sec, 55 sec, 1 min 41 sec for freezes
Player freezes at 11 seconds, recoverable eventually by clicking a new location in the video. Player freezes again at 55 seconds, recovery is by player eventually resetting itself.
It does still happen, but is more difficult to trigger. More often, the player will freeze temporarily, then reload the thumbnail image and re-enable the play button, and playback can then be resumed.
Other behavior still includes video fast-forwarding at a rapid pace, or audio continuing while video freezes, audio sometimes from a very different location in video.
Debian testing
WebKitGTK 2.42.4
GStreamer 1.22.8
Created attachment 469523[details]
Log from last video attachment
For some reason, trying to capture the bug makes it harder to encounter. Suggested nomenclature: Schrödinger's bug
At any rate, here is the log from the last video recording, wherein @00:31ish the video bugs out, the player eventually crashes.
Used the command:
GST_DEBUG="3,webkit*:6" GST_DEBUG_FILE="$HOME/gst.log" GST_DEBUG_NO_COLOR=1 WEBKIT_DISABLE_SANDBOX_THIS_IS_DANGEROUS=1 epiphany-browser
Created attachment 469619[details]
dot files from bugged fullscreen mode
Using flatpak (hopefully a more useful data dump), I got a frozen screen when leaving fullscreen using F key on a YouTube video (audio continued as normal), then going fullscreen again presented a black screen, then leaving fullscreen again presented a white screen.
terminal output using flatpak run --filesystem=home --env="WEBKIT_DISABLE_SANDBOX_THIS_IS_DANGEROUS=1" \
--env="GST_DEBUG=3,webkit*:6" --env="GST_DEBUG_FILE=$HOME/gst.log" \
--env="GST_DEBUG_DUMP_DOT_DIR=$HOME/dots" org.gnome.Epiphany -p "https://www.youtube.com/watch?v=S9gaug59DwA":
Failed to get GBM buffer from swap chain: no buffers available
gst.log file was empty
It seems I'm having a very hard time reproducing bugs via the flatpak, but a very easy time reproducing bugs via the native .deb packages. I'm having a hard time compiling with debug symbols on Debian, and the flatpak won't be helpful if I can't get it to glitch.
Created attachment 469621[details]
A dump of Odysee and YouTube both failing immediately
This appears to have the same "garbage data" in the middle of the log, which I'm not sure how to fix. Both YouTube and Odysee nearly immediately failed to play videos.
Also this:
0:00:28.469481213 68407 0x7f4960001e60 WARN basesink gstbasesink.c:3143:gst_base_sink_is_too_late:<webkit-dmabuf-video-appsink> warning: A lot of buffers are being dropped.
0:00:28.469530803 68407 0x7f4960001e60 WARN basesink gstbasesink.c:3143:gst_base_sink_is_too_late:<webkit-dmabuf-video-appsink> warning: There may be a timestamping problem, or this computer is too slow.
What is your hardware setup? GPU / CPU? Having the webkit://gpu output would be useful.
Can you check with gstva?
gst-inspect-1.0 va
then for each reported element, uprank it with this env var. For instance:
GST_PLUGIN_FEATURE_RANK=vah264dec:max,vavp9dec:max
Created attachment 469637[details]
odysee freezing, rumble freezing video while audio plays, then freezing completely
Log produced running epiphany with:
GST_DEBUG="3,webkit*:6" GST_DEBUG_FILE="$HOME/gst.log" GST_DEBUG_NO_COLOR=1 WEBKIT_DISABLE_SANDBOX_THIS_IS_DANGEROUS=1 GST_PLUGIN_FEATURE_RANK=vah264dec:max,vavp9dec:max,vah264lpenc:max,vah265dec:max,vajpegdec:max,vampeg2dec:max,vavp8dec:max epiphany-browser
(In reply to erusan from comment #29)
> Created attachment 469637[details]
> odysee freezing, rumble freezing video while audio plays, then freezing
> completely
>
> Log produced running epiphany with:
>
> GST_DEBUG="3,webkit*:6" GST_DEBUG_FILE="$HOME/gst.log" GST_DEBUG_NO_COLOR=1
> WEBKIT_DISABLE_SANDBOX_THIS_IS_DANGEROUS=1
> GST_PLUGIN_FEATURE_RANK=vah264dec:max,vavp9dec:max,vah264lpenc:max,vah265dec:
> max,vajpegdec:max,vampeg2dec:max,vavp8dec:max epiphany-browser
Again garbaged
If I run epiphany from the command line, crashing videos sometimes occur alongside the message:
Failed to get GBM buffer from swap chain: no buffers available
Not sure if this is helpful
Created attachment 470425[details]
Phub, Rumble, YouTube all glitching
gst-inspect-1.0 va outputs:
Plugin Details:
Name va
Description VA-API codecs plugin
Filename /lib/x86_64-linux-gnu/gstreamer-1.0/libgstva.so
Version 1.22.10
License LGPL
Source module gst-plugins-bad
Documentation https://gstreamer.freedesktop.org/documentation/va/
Source release date 2024-02-13
Binary package GStreamer Bad Plugins (Debian)
Origin URL https://tracker.debian.org/pkg/gst-plugins-bad1.0
vah264dec: VA-API H.264 Decoder
vah264lpenc: VA-API H.264 Low Power Encoder
vah265dec: VA-API H.265 Decoder
vajpegdec: VA-API JPEG Decoder
vampeg2dec: VA-API Mpeg2 Decoder
vavp8dec: VA-API VP8 Decoder
vavp9dec: VA-API VP9 Decoder
The attached log is produced using the same command as erusan, output has a bunch of zeroes and slashes in it...is that the garbage making these logs useless?
GST_DEBUG="3,webkit*:6" GST_DEBUG_FILE="$HOME/gst.log" GST_DEBUG_NO_COLOR=1 WEBKIT_DISABLE_SANDBOX_THIS_IS_DANGEROUS=1 GST_PLUGIN_FEATURE_RANK=vah264dec:max,vah264lpenc:max,vah265dec:max,vajpegdec:max,vampeg2dec:max,vavp8dec:max,vavp9dec:max epiphany-browser
Behavior was:
Opening private phub window, audio is distorted.
Seeking around in rumble video, eventually the player froze, then clicking on it made it resume the audio (but no video played).
Seeking around in a YouTube video made the video eventually fastword to the end at lightning speed.
Will try this on a different machine to see if processor is involved (although initial reporter was using AMD).
On another machine (see below), the same issues occur.
One difference is that "gst-inspect-1.0 av" yields "No such element or plugin 'av'".
However, gstreamer1.0-libav is installed (by default).
Installing gstreamer1.0-vaapi does not change anything.
This is a live Debian testing image on:
Dell XPS 13 9350
Intel Core i3-6100U x 4
4 GiB RAM
Intel HD Graphics 520 (SKL GT2)
Ooops, late night bug reporting leads to dyslexic fingers. Ignore the previous comment -- gst-inspect-1.0 returns
vah264dec: VA-API H.264 Decoder
vah264lpenc: VA-API H.264 Low Power Encoder
vah265dec: VA-API H.265 Decoder
vajpegdec: VA-API JPEG Decoder
vampeg2dec: VA-API Mpeg2 Decoder
vavp8dec: VA-API VP8 Decoder
on the other machine (same as this machine, just no VP9).
(In reply to gumbercules12 from comment #32)
> The attached log is produced using the same command as erusan, output has a
> bunch of zeroes and slashes in it...is that the garbage making these logs
> useless?
No, those are terminal control codes to add color to the logs. Phil uses some special command to view the logs and likes the colors. Unfortunately for everybody else it's confusing and makes the logs very hard to read.
(In reply to Michael Catanzaro from comment #36)
> (In reply to gumbercules12 from comment #32)
> > The attached log is produced using the same command as erusan, output has a
> > bunch of zeroes and slashes in it...is that the garbage making these logs
> > useless?
>
> No, those are terminal control codes to add color to the logs. Phil uses
> some special command to view the logs and likes the colors. Unfortunately
> for everybody else it's confusing and makes the logs very hard to read.
No Michael... that's not terminal control codes. This log was produced with GST_DEBUG_NO_COLOR=1
Created attachment 470523[details]
rumble freezing at very end
Are these files more useful than the previous dumps? Using the MiniBrowser per https://docs.webkit.org/Ports/WebKitGTK%20and%20WPE%20WebKit/Multimedia.html#minibrowser
Installing gstreamer1.0-fdkaac as per bug #271133 seems to have made things more stable, although without lots of testing, it's hard to say. I also use epiphany for browsing rather than MiniBrowser, obviously, so I'm not sure if that impacts anything. At any rate, I was able to trigger a freeze eventually.
(In reply to gumbercules12 from comment #39)
> Created attachment 470523[details]
> rumble freezing at very end
>
> Are these files more useful than the previous dumps? Using the MiniBrowser
> per
> https://docs.webkit.org/Ports/WebKitGTK%20and%20WPE%20WebKit/Multimedia.
> html#minibrowser
>
> Installing gstreamer1.0-fdkaac as per bug #271133 seems to have made things
> more stable, although without lots of testing, it's hard to say. I also use
> epiphany for browsing rather than MiniBrowser, obviously, so I'm not sure if
> that impacts anything. At any rate, I was able to trigger a freeze
> eventually.
Was the MiniBrowser UI still usable or not?
That log looks ok... If the WebProcess deadlocked we'd need to be able to inspect it with gdb to find further details...
Created attachment 470577[details]
odysee dots and gst after freezing, audio sporadic, video lightning speeding to end
The MiniBrowser UI is functioning normally when these bugs happen, and the rest of the website is functional as well.
2022-11-02 14:55 PDT, erusan
2022-11-02 15:00 PDT, erusan
2023-03-29 20:53 PDT, erusan
2024-01-21 21:03 PST, erusan
2024-01-23 20:35 PST, erusan
2024-01-23 20:37 PST, erusan
2024-01-30 11:33 PST, erusan
2024-01-30 14:04 PST, erusan
2024-01-31 12:15 PST, erusan
2024-01-31 13:31 PST, erusan
2024-03-18 16:30 PDT, gumbercules12
2024-03-23 14:39 PDT, gumbercules12
2024-03-24 16:59 PDT, gumbercules12