Bug 209405 – [GStreamer] WebM seek issues

• Status: RESOLVED
• Resolution: INVALID
• Component: WebKitGTK

[Lionir]

Epiphany 3.36.0-29-g6569bad51
WebKitGTK 2.28.0

Here is a video showcasing the issue with the appropriate timestamp : https://youtu.be/0UqJGq0zcBk?t=6

The TL;DW is clicking the player controls on https://blogs.gnome.org/mcatanzaro/2019/03/27/epiphany-3-32-and-webkitgtk-2-24/ turns them purple and that trying to seek the file infinitely buffers.

[Philippe Normand]

The purple issue doesn't happen in ToT. However the webm seek problem does. Yet another issue with webkitwebsrc, it seems.

[Philippe Normand]

Looks like the source element doesn't provide enough data fast enough:

0:00:08.695903246    51      0x1a2a0f0 LOG        webkitmediaplayer MediaPlayerPrivateGStreamer.cpp:2066:handleMessage:<media-player-1> Message error received from element matroskademux1
0:00:08.695936024    51      0x1a2a0f0 ERROR      webkitmediaplayer MediaPlayerPrivateGStreamer.cpp:2072:handleMessage: Error 9: Could not demultiplex stream. (url=https://blogs.gnome.org/mcatanzaro/files/2019/03/font-variations.webm?_=2)
0:00:08.724308828    51 0x7f3ac40310a0 WARN            videodecoder gstvideodecoder.c:4136:_gst_video_decoder_error:<vp9dec1> error: Failed to decode frame
0:00:08.725645437    51 0x7f3ac40310a0 WARN            videodecoder gstvideodecoder.c:4138:_gst_video_decoder_error:<vp9dec1> error: corrupt frame

[Alicia Boya García]

This is a server problem:

Look at this request:

0:00:05.341560710 235213      0x11e2360 DEBUG           webkitwebsrc WebKitWebSourceGStreamer.cpp:1004:responseReceived:<source> R2: Received response: 200
0:00:05.341659511 235213      0x11e2360 DEBUG           webkitwebsrc WebKitWebSourceGStreamer.cpp:1029:responseReceived:<source> R2: Request headers going downstream: request-headers, Referer=(string)https://blogs.gnome.org/mcatanzaro/2019/03/27/epiphany-3-32-and-webkitgtk-2-24/, Range=(string)"bytes\=196264-", Connection=(string)close, Icy-Metadata=(string)1;
0:00:05.341717935 235213      0x11e2360 DEBUG           webkitwebsrc WebKitWebSourceGStreamer.cpp:1042:responseReceived:<source> R2: Response headers going downstream: response-headers, Date=(string)"Thu\,\ 14\ May\ 2020\ 08:21:52\ GMT", Content-Length=(guint64)4849870, Last-Modified=(string)"Tue\,\ 26\ Mar\ 2019\ 18:30:47\ GMT", ETag=(string)"\"c861923144653bacd7020e0ffed21f16\"", Expires=(string)"Sat\,\ 15\ Jul\ 2023\ 18:08:32\ GMT", Connection=(string)close, Content-Type=(string)video/webm, Server=(string)"Apache/2.4.27\ \(Red\ Hat\)\ OpenSSL/1.0.2k-fips\ PHP/7.1.30", X-Powered-By=(string)PHP/7.1.30;
0:00:05.341755870 235213      0x11e2360 WARN            webkitwebsrc WebKitWebSourceGStreamer.cpp:1060:responseReceived:<source> error: R2: Received unexpected 200 HTTP status code for range request

Note how the second request is a range request, but the server replies with HTTP 200 (no support for range requests). Range requests are generally needed for media playback. Safari won't even bother if they are not supported.

WebKitGTK and WPE are a bit more lenient, and allow also cases where they are not supported to support use cases like shoutcast, or as a fallback that is viable for small videos. Whether a source URL is seekable is inferred throught the following rules, applied to the first response:

1) If there is no Content-Size, the source is not seekable.
2) If there is an Accept-Ranges header and its value is "none", the source is not seekable.
3) Otherwise, the source is assumed to be seekable.

These rules are derived from the fact that most static file servers will emit Content-Size and support seeks, whereas often server scripts and shoutcast streams will not.

CONSOLE MEDIA LOG "HTMLMediaElement::mediaEngineWasUpdated(FFA43C223A4A34CF) "
0:00:04.100774772 235213      0x11e2360 DEBUG           webkitwebsrc WebKitWebSourceGStreamer.cpp:1004:responseReceived:<source> R1: Received response: 200
0:00:04.100895667 235213      0x11e2360 DEBUG           webkitwebsrc WebKitWebSourceGStreamer.cpp:1029:responseReceived:<source> R1: Request headers going downstream: request-headers, Referer=(string)https://blogs.gnome.org/mcatanzaro/2019/03/27/epiphany-3-32-and-webkitgtk-2-24/, Connection=(string)close, Icy-Metadata=(string)1;
0:00:04.100965100 235213      0x11e2360 DEBUG           webkitwebsrc WebKitWebSourceGStreamer.cpp:1042:responseReceived:<source> R1: Response headers going downstream: response-headers, Date=(string)"Thu\,\ 14\ May\ 2020\ 08:21:51\ GMT", Content-Length=(guint64)4849870, Last-Modified=(string)"Tue\,\ 26\ Mar\ 2019\ 18:30:47\ GMT", ETag=(string)"\"c861923144653bacd7020e0ffed21f16\"", Expires=(string)"Sat\,\ 15\ Jul\ 2023\ 18:08:31\ GMT", Connection=(string)close, Content-Type=(string)video/webm, Server=(string)"Apache/2.4.27\ \(Red\ Hat\)\ OpenSSL/1.0.2k-fips\ PHP/7.1.30", X-Powered-By=(string)PHP/7.1.30;
0:00:04.101006103 235213      0x11e2360 DEBUG           webkitwebsrc WebKitWebSourceGStreamer.cpp:1071:responseReceived:<source> R1: Size: 4849870, isSeekable: true

You need to either support range requests in your server (preferable for better cross browser support, and since otherwise the whole video will have to be downloaded every time), or advertise that you *don't* support them by emitting Accept-Ranges: none.