Bug 183259 – [GStreamer] Cannot play particular videos

• Component: Media
• Status: RESOLVED WORKSFORME

[Michael Catanzaro]

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.

[Philippe Normand]

Add it to an html file in a <video> element and it plays.

[Michael Catanzaro]

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.

[Michael Catanzaro]

Carlos, any chance you know how this is supposed to work?

[Carlos Garcia Campos]

I giess we are doing something different in case of MediaDocument

[Philippe Normand]

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.

[Philippe Normand]

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

[Michael Catanzaro]

Another example video that fails to play:

https://matrix.org/_matrix/media/v1/download/matrix.org/vatFhMWBkNvNZhJWOdQCkeaQ

[Michael Catanzaro]

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.

[Xabier Rodríguez Calvar]

(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!

[Philippe Normand]

As I said in comment 5 this might not be a pure-controls bug. loop5.webm is detected as an audio file...

[Michael Catanzaro]

(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?

[Philippe Normand]

(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?

[Philippe Normand]

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)

[Michael Catanzaro]

(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

[Xabier Rodríguez Calvar]

(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.

[Xabier Rodríguez Calvar]

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.

[Michael Catanzaro]

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.

[Fernando Jiménez Moreno]

(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

[Michael Catanzaro]

Maybe you could finish that thought in bug #221622. :)

[Michael Catanzaro]

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.

[Michael Catanzaro]

(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.

[Jakub Steiner]

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/

[Philippe Normand]

(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.

[Philippe Normand]

(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+

[Michael Catanzaro]

(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.

[Michael Catanzaro]

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/