Bug 183259

Summary: [GStreamer] Cannot play particular videos
Product: WebKit Reporter: Michael Catanzaro <mcatanzaro>
Component: MediaAssignee: Nobody <webkit-unassigned>
Status: RESOLVED WORKSFORME    
Severity: Normal CC: alicem, bugs-noreply, calvaris, cgarcia, fjimenez, jsteiner, mcatanzaro, philn, pnormand
Priority: P2    
Version: Other   
Hardware: PC   
OS: Windows 10   
See Also: https://bugs.webkit.org/show_bug.cgi?id=221622

Description Michael Catanzaro 2018-03-01 13:59:50 PST
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.
Comment 1 Philippe Normand 2018-03-02 01:44:25 PST
Add it to an html file in a <video> element and it plays.
Comment 2 Michael Catanzaro 2018-03-02 08:09:48 PST
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.
Comment 3 Michael Catanzaro 2018-03-25 18:13:30 PDT
Carlos, any chance you know how this is supposed to work?
Comment 4 Carlos Garcia Campos 2018-03-25 23:36:26 PDT
I giess we are doing something different in case of MediaDocument
Comment 5 Philippe Normand 2018-07-06 07:06:04 PDT
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.
Comment 6 Philippe Normand 2018-07-10 02:50:23 PDT
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
Comment 7 Michael Catanzaro 2019-01-28 07:32:26 PST
Another example video that fails to play:

https://matrix.org/_matrix/media/v1/download/matrix.org/vatFhMWBkNvNZhJWOdQCkeaQ
Comment 8 Michael Catanzaro 2019-12-12 12:44:08 PST
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.
Comment 9 Xabier Rodríguez Calvar 2019-12-13 01:38:08 PST
(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!
Comment 10 Philippe Normand 2019-12-13 03:33:38 PST
As I said in comment 5 this might not be a pure-controls bug. loop5.webm is detected as an audio file...
Comment 11 Michael Catanzaro 2021-02-03 12:07:55 PST
(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?
Comment 12 Philippe Normand 2021-02-04 04:38:44 PST
(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?
Comment 13 Philippe Normand 2021-02-04 05:28:37 PST
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)
Comment 14 Michael Catanzaro 2021-02-04 05:49:40 PST
(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
Comment 15 Xabier Rodríguez Calvar 2021-02-09 02:09:57 PST
(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.
Comment 16 Xabier Rodríguez Calvar 2021-02-09 11:44:01 PST
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.
Comment 17 Michael Catanzaro 2021-02-09 12:00:19 PST
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.
Comment 18 Fernando Jiménez Moreno 2021-02-09 22:00:13 PST
(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
Comment 19 Michael Catanzaro 2021-02-10 06:05:09 PST
Maybe you could finish that thought in bug #221622. :)
Comment 20 Michael Catanzaro 2022-02-10 12:11:18 PST
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 [details]). The symptoms are identical, so I assume it is the same bug.
Comment 21 Michael Catanzaro 2023-05-26 08:27:43 PDT
(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.
Comment 22 Jakub Steiner 2023-05-29 01:04:50 PDT
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/
Comment 23 Philippe Normand 2023-05-29 02:03:44 PDT
(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.
Comment 24 Philippe Normand 2023-06-28 09:01:24 PDT
(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+
Comment 25 Michael Catanzaro 2023-06-28 09:15:17 PDT
(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.
Comment 26 Michael Catanzaro 2023-06-28 09:27:51 PDT
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/