Bug 245851

Summary: [GStreamer][MSE] High resolution video playback broken on Odysee.com due to unimplemented changeType operation
Product: WebKit Reporter: Caden Mitchell <caden>
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

Caden Mitchell
Reported 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.
Attachments
log from gnome web console (1.57 KB, text/plain)
2022-09-29 15:56 PDT, Caden Mitchell 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
Michael Catanzaro
Comment 1 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.
Caden Mitchell
Comment 2 2022-09-29 15:46:01 PDT
My apologies, this command did not output any file.
Caden Mitchell
Comment 3 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
Philippe Normand
Comment 4 2022-10-03 01:29:50 PDT
NotSupportedError: The operation is not supported. changeType That's a known missing feature of our MSE backend...
Xabier Rodríguez Calvar
Comment 5 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.
Xabier Rodríguez Calvar
Comment 6 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.
Xabier Rodríguez Calvar
Comment 7 2022-10-06 07:36:03 PDT
Pull request: https://github.com/WebKit/WebKit/pull/5085
EWS
Comment 8 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.
Radar WebKit Bug Importer
Comment 9 2022-10-10 07:56:20 PDT
<rdar://problem/100978642>
Note You need to log in before you can comment on or make changes to this bug.