Bug 289194 – [GStreamer][MSE] YouTube is broken, only first 18 seconds of videos are playable

• Component: Media
• Status: RESOLVED FIXED

[Michael Catanzaro]

Currently YouTube videos are all broken in both Ephy Tech Preview and my jhbuild devel environment. Only the first approximately 18-20 seconds of the video is works; once the playback reaches this point, the video stops loading and displays a spinner forever. It looks like a network issue.

I saw a suspicious-looking bug report https://gitlab.gnome.org/GNOME/libsoup/-/issues/412 but that bug report is definitely not related because it points to a libsoup commit that is not to blame for this issue. The change does not appear to be a regression in WebKit or libsoup; I've tested many recent versions of both and they are all broken. Users are also reporting that stable version 2.46 is broken.

I think either something has changed on YouTube's end, or alternatively, perhaps something broke in GStreamer 1.24? I haven't tested older versions of GStreamer; we should probably test GStreamer 1.24.10 to see if that older version is good.

[Philippe Normand]

Created attachment 474472 [details]
screenshot

[Philippe Normand]

See buffer health to 0 in the screenshot. Sounds like another MSE (or even YT-server side) issue...

[Alicia Boya García]

I can reproduce the issue.

[Alicia Boya García]

Playback is stalling YouTube is not appending more media than those initial ~20 seconds:

$ cat ~/gst-log-* |gst-log-filter -c 'webkit*:TRACE' |grep append-pipeline-audio-webm-6 |grep -i "append: trackId" |tail -n1
0:00:46.991301553 882863 0x55ebf6bfa050 TRACE   webkitmseappendpipeline AppendPipeline.cpp:384:appsinkNewSample:<append-pipeline-audio-webm-6> append: trackId=1 PTS={19974500/1000000 = 19.9745} DTS={19974500/1000000 = 19.9745} DUR={20000/1000000 = 0.02} presentationSize=0x0

$ cat ~/gst-log-* |gst-log-filter -c 'webkit*:TRACE' |grep append-pipeline-video-webm-7 |grep -i "append: trackId" |tail -n1
0:00:47.049317567 882863 0x55ebf6bfa050 TRACE   webkitmseappendpipeline AppendPipeline.cpp:384:appsinkNewSample:<append-pipeline-video-webm-7> append: trackId=100 PTS={21566000/1000000 = 21.566} DTS={21566000/1000000 = 21.566} DUR={33333/1000000 = 0.033333} presentationSize=640x360

$ cat ~/gst-log-* |gst-log-filter -c 'webkit*:TRACE' |grep playbackPosition | tail -n1
0:05:25.394204493 882863 0x55ebf6bfa050 TRACE      webkitmediaplayer MediaPlayerPrivateGStreamer.cpp:1576:playbackPosition:<MSE-media-player-11> Returning cached position: {20175974000/1000000000 = 20.175974}

Notice the playback position where the player ends up stuck with is exactly pts+dur of the last sample of the shortest track. WebKit is playing as far as it can.

Of course, the next question is, why is YouTube not appending more media?

The bug is also sorta flaky, it doesn't reproduce all the time.

[Enrique Ocaña]

It also happens when using the YouTube desktop version on (downstream, older) wpe-2.38 but, surprisingly, doesn't happen when using the YouTube TV version: https://www.youtube.com/tv?#/watch?v=T8wEW5WeMxg

(Note that it needed the Cobalt user agent to work in downstream wpe-2.38: 'Mozilla/5.0 (DirectFB; Linux x86_64) Cobalt/21.13031-qa (unlike Gecko) Starboard/1', but even though I used that same useragent in MiniBrowser desktop, I couldn't make YouTube TV to work there. It always redirects to the desktop website. In the past, YT TV also required the screen size to be 720p, 1080p or 4K and complained if that wasn't the case, but I've set MiniBrowser to full screen on a 4K display and it still didn't detect it as a set-top-box)

[Carlos Bentzen]

Also reproduced it here, stalling at 20s, but strangely though, only when I'm not signed in. If I log in to YouTube (Premium account - no ads), then it doesn't stall anymore.

[Enrique Ocaña]

Things work fine on Safari, both with the default user-agent, and with the same user-agent as WebKitGTK MiniBrowser.

[oxumare]

Also reproduced, either logged in (normal account) or not.
Tried also with ephemeral contex, same thing.
In the console appear continuos logs like:


[Error] Failed to load resource: the server responded with a status of 403 (Forbidden) (videoplayback, line 0)

[Alicia Boya García]

I just found the same 403 errors now while doing some more debugging.

YouTube servers are blocking WebKitGTK and that's why it fails. /videoplayback is the endpoint where YouTube downloads media data from.

YouTube has been observed in the recent past (Dec 2024) to block requests based on user-agent fingerprinting: https://github.com/yt-dlp/yt-dlp/issues/11868#issuecomment-2566480257

From the looks of it, WebKitGTK is currently an accidental casualty in YouTube's fight against ad-blockers and video download software.

[Enrique Ocaña]

As a short term workaround, the videos can be watched using a YouTube wrapper, such as https://invidious.io/
The lack of ads in those wrappers (and in paid accounts in the real YouTube website) appears to help to avoid the issue.

[Alicia Boya García]

The filtering is User-Agent string dependent. Seems that using a macOS Safari User-Agent string makes things work.

Currently we have a quirk enabled that makes WebKitGTK pretend to be Chrome due to this bug: https://bugs.webkit.org/show_bug.cgi?id=253877 Reverting it may be enough to fix the issue, we'll continue investigating.

[Alicia Boya García]

Pull request: https://github.com/WebKit/WebKit/pull/42081

[EWS]

Committed 291817@main (a760e1b2e1e0): <https://commits.webkit.org/291817@main>

Reviewed commits have been landed. Closing PR #42081 and removing active labels.

[Radar WebKit Bug Importer]

<rdar://problem/146519449>

[Michael Catanzaro]

I got a report from users that they are unable to scroll through comments in fullscreen mode with this quirk removed, so it was not actually safe to remove. However, that's obviously not nearly so bad a problem as being unable to watch videos, so I suppose this is OK. Would be good to test other quirks though. Safari on macOS is often a safe quirk; we should only use the Chromium quirk when Safari on macOS doesn't work for some reason.

[Alicia Boya García]

Feel free to test a macOS quirk and add it if it fixes the issue.

[Xabier Rodríguez Calvar]

And I guess that you should also open a new bug.

[Philippe Normand]

I'm afraid there's issues with any quirk we use... see also bug 257178.