Bug 245851

Summary: [GStreamer][MSE] High resolution video playback broken on Odysee.com due to unimplemented changeType operation
Product: WebKit Reporter: tri.voxel
Component: MediaAssignee: Xabier Rodríguez Calvar <calvaris>
Status: RESOLVED FIXED    
Severity: Critical CC: aboya, bugs-noreply, calvaris, mcatanzaro, philn, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: Other   
Hardware: PC   
OS: Linux   
Attachments:
Description Flags
log from gnome web console none

Description tri.voxel 2022-09-29 15:36:32 PDT 
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'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 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.

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 1080p on WebKit, much the same as Odysee, but worked fine in Firefox. It seems the video playback system needs a lot of work.
Comment 1 Michael Catanzaro 2022-09-29 15:40:27 PDT 
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.
Comment 2 tri.voxel 2022-09-29 15:46:01 PDT 
My apologies, this command did not output any file.
Comment 3 tri.voxel 2022-09-29 15:56:05 PDT 
Created attachment 462719 [details]
log from gnome web console

Was able to recover a log from the Gnome Web console feature
Comment 4 Philippe Normand 2022-10-03 01:29:50 PDT 
NotSupportedError: The operation is not supported.
changeType

That's a known missing feature of our MSE backend...
Comment 5 Xabier Rodríguez Calvar 2022-10-04 01:15:07 PDT 
(In reply to Philippe Normand from comment #4)
> NotSupportedError: The operation is not supported.
> changeType
> 
> That's a known missing feature of our MSE backend...

I think there is a way, IIRC, to avoid having changeType exposed in the IDL:

    [EnabledBySetting=SourceBufferChangeTypeEnabled] undefined changeType(DOMString type);

I guess we have to disable this.
Comment 6 Xabier Rodríguez Calvar 2022-10-04 01:16:35 PDT 
If we disable it in the IDL, it won't be exposed and apps will be able to check if it's undefined and act accordingly. If they don't check it, the app will fail but it would be their fault then.
Comment 7 Xabier Rodríguez Calvar 2022-10-06 07:36:03 PDT 
Pull request: https://github.com/WebKit/WebKit/pull/5085
Comment 8 EWS 2022-10-10 07:55:19 PDT 
Committed 255345@main (90f34d7eabdf): <https://commits.webkit.org/255345@main>

Reviewed commits have been landed. Closing PR #5085 and removing active labels.
Comment 9 Radar WebKit Bug Importer 2022-10-10 07:56:20 PDT 
<rdar://problem/100978642>