183259 2018-03-01 13:59:50 -0800 [GStreamer] Cannot play particular videos 2023-06-28 09:27:51 -0700 1 1 1 Unclassified WebKit Media Other PC Windows 10 RESOLVED WORKSFORME https://bugs.webkit.org/show_bug.cgi?id=221622 P2 Normal --- 1 mcatanzaro webkit-unassigned alicem bugs-noreply calvaris cgarcia fjimenez jsteiner mcatanzaro philn pnormand oldest_to_newest 1403031 0 mcatanzaro 2018-03-01 13:59:50 -0800 I can't play this simple WebM video in Epiphany Tech Preview (WebKitGTK+ 2.19.91): https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/gtk/loop5.webm I think it's different from bug #182653 because that video starts to play and only seek is broken, whereas this video does not play at all. 1403180 1 pnormand 2018-03-02 01:44:25 -0800 Add it to an html file in a <video> element and it plays. 1403217 2 mcatanzaro 2018-03-02 08:09:48 -0800 Ummmm that should not be required, and was not required in the past. We are even showing media controls for it and everything. They're just broken. If we did not support directly playing media files, we would need to start a download instead of displaying broken media controls. But I'm pretty sure this used to work. I see it is also broken in 2.18.6, though. 1409221 3 mcatanzaro 2018-03-25 18:13:30 -0700 Carlos, any chance you know how this is supposed to work? 1409252 4 cgarcia 2018-03-25 23:36:26 -0700 I giess we are doing something different in case of MediaDocument 1439775 5 pnormand 2018-07-06 07:06:04 -0700 The problem seems to be that loop5.webm is thought to be audio/webm by the DOMImplementation and MediaDocument seems to handle only <video> elements, so an empty page is displayed, only controls are visible. 1440791 6 pnormand 2018-07-10 02:50:23 -0700 The HTTP response header has the wrong content-type set, so not sure what to do about this. One thing to consider, maybe don't set the type attr on the video element created by the MediaDocument. I tried that and got a bunch of XSS errors afterwards :S 1499016 7 mcatanzaro 2019-01-28 07:32:26 -0800 Another example video that fails to play: https://matrix.org/_matrix/media/v1/download/matrix.org/vatFhMWBkNvNZhJWOdQCkeaQ 1598101 8 mcatanzaro 2019-12-12 12:44:08 -0800 Lots of errors in the web inspector. Looks like some problems with the media controls JS: [Error] Failed to load resource: Plug-in handled load (loop5.webm, line 0) [Error] Blocked script execution in 'https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/gtk/loop5.webm' because the document's frame is sandboxed and the 'allow-scripts' permission is not set. [Error] Refused to load https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/gtk/loop5.webm because it appears in neither the media-src directive nor the default-src directive of the Content Security Policy. [Error] Blocked script execution in 'https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/gtk/loop5.webm' because the document's frame is sandboxed and the 'allow-scripts' permission is not set. (x26) [Error] Blocked script execution in 'https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/gtk/loop5.webm' because the document's frame is sandboxed and the 'allow-scripts' permission is not set. (x50) Just hovering over the play button causes the last error to occur, one error for each pixel I move the cursor. 1598288 9 calvaris 2019-12-13 01:38:08 -0800 (In reply to Michael Catanzaro from comment #8) > Lots of errors in the web inspector. Looks like some problems with the media > controls JS: Please file a different bug for this under [GTK] cause controls are just tangentially related to multimedia. Thx! 1598302 10 pnormand 2019-12-13 03:33:38 -0800 As I said in comment 5 this might not be a pure-controls bug. loop5.webm is detected as an audio file... 1725263 11 mcatanzaro 2021-02-03 12:07:55 -0800 (In reply to Michael Catanzaro from comment #7) > Another example video that fails to play: > > https://matrix.org/_matrix/media/v1/download/matrix.org/ > vatFhMWBkNvNZhJWOdQCkeaQ Hm, this happens with MP4 video as well: https://gnome.modular.im/_matrix/media/r0/download/gnome.org/62a43e4dd1f71c657be994f79a4a203db9c9e708/video_514ec09.mp4 Is it the same issue (in which case the bug should be renamed to not specify WebM), or a different issue with the same symptoms? 1725592 12 pnormand 2021-02-04 04:38:44 -0800 (In reply to Michael Catanzaro from comment #11) > (In reply to Michael Catanzaro from comment #7) > > Another example video that fails to play: > > > > https://matrix.org/_matrix/media/v1/download/matrix.org/ > > vatFhMWBkNvNZhJWOdQCkeaQ > > Hm, this happens with MP4 video as well: Do you have a H.264 decoder in your runtime? 1725605 13 pnormand 2021-02-04 05:28:37 -0800 ERROR webkitmediaplayer MediaPlayerPrivateGStreamer.cpp:1806:handleMessage: Error 9: R3: Received unexpected 200 HTTP status code for range request (url=https://gnome.modular.im/_matrix/media/r0/download/gnome.org/62a43e4dd1f71c657be994f79a4a203db9c9e708/video_514ec09.mp4) 1725609 14 mcatanzaro 2021-02-04 05:49:40 -0800 (In reply to Philippe Normand from comment #12) > Do you have a H.264 decoder in your runtime? Of course, you know we have OpenH264. https://www.w3schools.com/html/mov_bbb.mp4 plays fine. (In reply to Philippe Normand from comment #13) > ERROR webkitmediaplayer > MediaPlayerPrivateGStreamer.cpp:1806:handleMessage: Error 9: R3: Received > unexpected 200 HTTP status code for range request > (url=https://gnome.modular.im/_matrix/media/r0/download/gnome.org/ > 62a43e4dd1f71c657be994f79a4a203db9c9e708/video_514ec09.mp4) I wonder why 200 "success" is so unexpected. :P 1726982 15 calvaris 2021-02-09 02:09:57 -0800 (In reply to Michael Catanzaro from comment #14) > (In reply to Philippe Normand from comment #12) > > Do you have a H.264 decoder in your runtime? > > Of course, you know we have OpenH264. > https://www.w3schools.com/html/mov_bbb.mp4 plays fine. > > (In reply to Philippe Normand from comment #13) > > ERROR webkitmediaplayer > > MediaPlayerPrivateGStreamer.cpp:1806:handleMessage: Error 9: R3: Received > > unexpected 200 HTTP status code for range request > > (url=https://gnome.modular.im/_matrix/media/r0/download/gnome.org/ > > 62a43e4dd1f71c657be994f79a4a203db9c9e708/video_514ec09.mp4) > > I wonder why 200 "success" is so unexpected. :P AFAIK a working range request should answer 206, not 200. If we should accept 200 as a valid answer and be prepared to handle the whole download is a different issue. 1727150 16 calvaris 2021-02-09 11:44:01 -0800 Michael, can you please clarify de scope of this bug. It is completely unclear to me. 200 vs 206 seems to be a different issue, please file a new bug for it as the initial scope of this bug seems to be different. 1727165 17 mcatanzaro 2021-02-09 12:00:19 -0800 Yeah, I agree it looks like 200 vs. 206 is a totally different issue. I have created bug #221622 for this problem with https://gnome.modular.im/_matrix/media/r0/download/gnome.org/62a43e4dd1f71c657be994f79a4a203db9c9e708/video_514ec09.mp4. I would say this bug can be closed when https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/gtk/loop5.webm is fixed. I also posted a link to https://matrix.org/_matrix/media/v1/download/matrix.org/vatFhMWBkNvNZhJWOdQCkeaQ in one of the comments above. I assume that one is really the same as this issue. 1727428 18 fjimenez 2021-02-09 22:00:13 -0800 (In reply to Xabier Rodríguez Calvar from comment #15) > AFAIK a working range request should answer 206, not 200. > > If we should accept 200 as a valid answer and be prepared to handle the > whole download is a different issue. According to https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.35.2 a server may ignore the `Range` header and so return a 200 response with the full content. Doing some archeology, it seems that https://bugs.webkit.org/show_bug.cgi?id=85994 handled this scenario. But 1727515 19 mcatanzaro 2021-02-10 06:05:09 -0800 Maybe you could finish that thought in bug #221622. :) 1839865 20 mcatanzaro 2022-02-10 12:11:18 -0800 I'm renaming this bug "Cannot play particular WebM videos" -> "Cannot play particular videos" because it affects MP4 videos too. E.g. WebKit is unable to play MP4 videos attached to this Bugzilla instance (e.g. attachment #451573). The symptoms are identical, so I assume it is the same bug. 1958201 21 mcatanzaro 2023-05-26 08:27:43 -0700 (In reply to Philippe Normand from comment #5) > The problem seems to be that loop5.webm is thought to be audio/webm by the > DOMImplementation and MediaDocument seems to handle only <video> elements, > so an empty page is displayed, only controls are visible. This seems to be sort of fixed now? WebKit recognizes that it doesn't support the content type of https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/gtk/loop5.webm and the video gets downloaded instead. Well, that's not really the *desired* behavior, but at least it's not as broken as it was before. 1958579 22 jsteiner 2023-05-29 01:04:50 -0700 Author of said videos here. I'm having trouble playing back some of these webm/vp9 or mp4/h264 video produced with Blender/ffmpeg. The common trait is that they don't have sound. It's not that they don't play directly, but also embedded with <video>: https://teams.pages.gitlab.gnome.org/Design/web-experiments/static/tiling/ 1958585 23 philn 2023-05-29 02:03:44 -0700 (In reply to Jakub Steiner from comment #22) > Author of said videos here. I'm having trouble playing back some of these > webm/vp9 or mp4/h264 video produced with Blender/ffmpeg. The common trait is > that they don't have sound. > > It's not that they don't play directly, but also embedded with <video>: > > https://teams.pages.gitlab.gnome.org/Design/web-experiments/static/tiling/ This is bug 221622 it seems. 1964038 24 philn 2023-06-28 09:01:24 -0700 (In reply to Jakub Steiner from comment #22) > Author of said videos here. I'm having trouble playing back some of these > webm/vp9 or mp4/h264 video produced with Blender/ffmpeg. The common trait is > that they don't have sound. > > It's not that they don't play directly, but also embedded with <video>: > > https://teams.pages.gitlab.gnome.org/Design/web-experiments/static/tiling/ Plays fine here now in 44.0-128-g9791b24be+ 1964042 25 mcatanzaro 2023-06-28 09:15:17 -0700 (In reply to Philippe Normand from comment #24) > Plays fine here now in 44.0-128-g9791b24be+ It's broken for me with the exact same version. I have: WebKitGTK 2.41.5 GStreamer 1.22.4 $ flatpak remote-info --log gnome-nightly org.gnome.Platform//master ID: org.gnome.Platform Ref: runtime/org.gnome.Platform/x86_64/master Arch: x86_64 Branch: master Collection: org.gnome.Nightly Download: 345.8 MB Installed: 933.9 MB Commit: b7fab3a9bcf3de2dba4423e92b15767f23d4a190bd891bc5b02273635f44ee46 Parent: d3c3a428ebe93331f213d3ca80a7a708e41bcfbf7e720a0ffefc31b0ef3684c3 Subject: Export org.gnome.Platform Date: 2023-06-27 22:47:26 +0000 History: Let me try to get a GStreamer debug log. 1964046 26 mcatanzaro 2023-06-28 09:27:51 -0700 Looking at the GStreamer debug log, I think the problem on Jakub's website in bug #221622. I'll avoid attaching the debug log here because I'm pretty sure that's a different problem from the bug with https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/gtk/loop5.webm. In fact, it's impossible to reproduce the original bug here because WebKit no longer supports the content type and downloads rather than loads https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/gtk/loop5.webm, as I mentioned above in comment #20. The content type header for this file is audio/webm. That actually looks like a GitLab bug, because it should be a video, not audio. But anyway, I tested in Firefox and Firefox does not support audio/webm either. So the original bug with https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/gtk/loop5.webm is no longer valid. The next broken video mentioned in this bug is https://gnome.modular.im/_matrix/media/r0/download/gnome.org/62a43e4dd1f71c657be994f79a4a203db9c9e708/video_514ec09.mp4, which got split out into... bug #221622. Moving on. The remaining problem here is https://bugs.webkit.org/attachment.cgi?id=451573. This video plays fine in Firefox but not in Epiphany. I got yet another debug log for this and decided this video is also broken due to bug #221622, same problem as with Jakub's video. So I think there is nothing more to fix here, at least not for now. Closing. I strongly suspect we still have a bug that causes WebM video documents to not work, but we'll have to resolve bug #221622 first before we can make further progress, since that seems to be breaking a large number of videos. BTW, to get the debug log, I followed the instructions from https://trac.webkit.org/wiki/WebKitGTK/Debugging#Debuggingmultimediastuff, but they will be lost when trac disappears. It would be good to add instructions for GStreamer debugging to https://docs.webkit.org/