Bug 245850 – [GStreamer] Video playback is highly unreliable, slow, and buggy

• Status: RESOLVED
• Resolution: INVALID
• Component: Media

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

I used a popular WebKitGTK browser known as Gnome Web (formerly Epiphany) as my primary browser for several months. Besides some occasional performance hitches, it has been a good experience. That is, however, ignoring the glaring issue of video playback. I've noticed a number of issues with video playback including but not limited to using the H.264, VP9, and AV1 codecs.

A good example is YouTube. In YouTube, you have a choice of playback between AV1 and VP9 by going to https://www.youtube.com/account_playback and setting the "AV1 Setting" to "Always prefer AV1". This will make certain 4K video playback run at an unacceptable framerate, especially unacceptable when you consider my computer is a high spec gaming computer. Here is an example of an AV1 video that runs fine in VP9 mode at 4K, and poorly in AV1 mode in 4K: https://youtu.be/VnBYQrPacqg

Note: It seems that some but not all content on YouTube now supports the AV1 codec, but other videos will not. The codec of the video can be determined by right clicking the video and selecting "stats for nerds." As AV1 is likely to become the dominant streaming codec in the future, I am hopeful this performance is resolved.

Secondly, I've noticed a major issue when trying to stream video content from a site known as Odysee.com. This site is a competitor to YouTube, and is also a good example of playback issues. In Chrome and Firefox, a user can select a video quality in the lower right corner. The site typically defaults to 720p, but can be changed to 1080p. Selecting 1080p in Chrome and Firefox will cause the video to load as expected. Selecting this option in WebKitGTK will cause the video to buffer indefinitely, and may even cause the webpage to become completely unresponsive. Now, you may notice there are two "1080p" options on Odysee's videos. One says "1080p", the other says "original (1080p)". Selecting "original" can sometimes work, selecting "1080p" will break the playback. This is a bug I can only replicate on WebKitGTK.

There is also another glaring issue that I have encountered numerous times. 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.

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.

Additionally, some one-off video sites are just absolutely terrible from time to time. It likely depends on the codecs being used, but an example of this is https://videos.trom.tf . I don't use this site personally or know much about it, but I loaded a video through it once and it just refused to play in WebKit, but worked fine in Firefox. It seems the video playback system needs a lot of work.

[Michael Catanzaro]

Please, only one issue per bug report. Pick just one to focus on here and report separate issues for the others.

You are in the right place, though. ;)

Update: this bug only focuses on the following issue:

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

I used a popular WebKitGTK browser known as Gnome Web (formerly Epiphany) as my primary browser for several months. Besides some occasional performance hitches, it has been a good experience. That is, however, ignoring the glaring issue of video playback. I've noticed a number of issues with video playback including but not limited to using the H.264, VP9, and AV1 codecs.

A good example is YouTube. In YouTube, you have a choice of playback between AV1 and VP9 by going to https://www.youtube.com/account_playback and setting the "AV1 Setting" to "Always prefer AV1". This will make certain 4K video playback run at an unacceptable framerate, especially unacceptable when you consider my computer is a high spec gaming computer. Here is an example of an AV1 video that runs fine in VP9 mode at 4K, and poorly in AV1 mode in 4K: https://youtu.be/VnBYQrPacqg

Note: It seems that some but not all content on YouTube now supports the AV1 codec, but other videos will not. The codec of the video can be determined by right clicking the video and selecting "stats for nerds." As AV1 is likely to become the dominant streaming codec in the future, I am hopeful this performance is resolved.

[Michael Catanzaro]

Note to developers: gstreamer-plugins-rust is not used in any distro, and it's not used by GNOME upstream or Ephy Tech Preview either. The AV1 decoder from there might be the greatest thing ever, but doesn't matter if it's not used....

[Philippe Normand]

Does your GPU supports AV1 hw decoding?

AV1 decoding in software, in 4K, is not going to be very smooth I'm afraid. Not sure there's an actionable item for us here.

How's the 4K AV1 playback with gst-play-1.0 --videosink glimagesink ?

[Philippe Normand]

(In reply to Michael Catanzaro from comment #3)
> Note to developers: gstreamer-plugins-rust is not used in any distro, and
> it's not used by GNOME upstream or Ephy Tech Preview either. The AV1 decoder
> from there might be the greatest thing ever, but doesn't matter if it's not
> used....

FYI, the Rust AV1 decoder is not the only implementation. There is an AOM implementation in C too, in -bad. Might be worth a try...

Also nowadays if your Intel GPU supports AV1 decoding, I think a vaav1dec element is available at runtime, in gst git main anyway.

[Michael Catanzaro]

Hi, can you answer Phil's question please? Thanks.

I'm not sure what happened to the other reporter, but I too am having various playback issues on both YouTube and Odysee after some recent update.

Running Debian testing with WebkitGtk 2.38.1 and Web 43.0

My processor (Core i5-8300H) does not support hardwave AV1 decoding.

Issues including things like Odysee (at least when a speed besides 1x is selected) will play rapidly through the video stream, while the audio is not in sync with it, and the video still stop once the video portion ends. (This is not replicated every time.) Videos pausing after a short time, sometimes playable if I skip ahead, sometimes not playable at all after the pause.

YouTube videos delaying at start-up, moving backwards often causing the video to simply freeze, or to freeze and then reload the video after some time, and other such strange behavior.

[Philippe Normand]

Please provide logs.

GST_DEBUG="3,webkit*:6" GST_DEBUG_FILE=/tmp/gst.log GST_DEBUG_DUMP_DOT_DIR=/tmp <browser> "https://..."

Make sure the browser has write-access to wherever you want to store the log file.
Then compress gst.log and attach it here.

[Philippe Normand]

I can't reproduce this Odysee issue in Ephy Web Tech Preview.

Do the logs uploaded to https://bugs.webkit.org/show_bug.cgi?id=245852 work?

[Philippe Normand]

(In reply to erusan from comment #10)
> Do the logs uploaded to https://bugs.webkit.org/show_bug.cgi?id=245852 work?

No. :(

And let's close this bug, there's no actionable point here.