Bug 209719 – [GStreamer] Video playback fails in web.whatsapp.com

• Component: Media
• Status: REOPENED

[Sergio Villar Senin]

Playing a video in Whatsapp Web doesn't work as expected. At the beginning everything goes fine, but after some seconds (depends on the video) it suddenly stops playing and gets shrinked in the vertical direction.

[Philippe Normand]

Please attach debug logs: GST_DEBUG="3,webkit*:6" GST_DEBUG_FILE=/tmp/gst.log

[Sergio Villar Senin]

Created attachment 394897 [details]
Gst log

Compressed log. The playback starts around 1'20" I think.

[Philippe Normand]

Seems to be an issue with webkitwebsrc, again :) Which version is this? ToT?

[Sergio Villar Senin]

(In reply to Philippe Normand from comment #3)
> Seems to be an issue with webkitwebsrc, again :) Which version is this? ToT?

Right, I'm seeing it with 2.28 (failed with previous versions I think as well) and I'm seeing it also with MB in ToT

[Alicia Boya García]

Fixed by the WebKitWebSrc rework.

*** This bug has been marked as a duplicate of bug 210284 ***

[Sergio Villar Senin]

This is still not working. I'm seeing the same issues, video plays some seconds and the after that it stops and get shrinked in the vertical direction.

[Philippe Normand]

Here in Ephy 40.alpha-100-g7aa7cb5c2+ (wkgtk 2.31.1) I cannot reproduce this.
Cannot repro in MiniBrowser ToT either.

There's an issue with video rotation metadata handling, but I'd say it's orthogonal (no pun intended) to this bug.


Can you upload debug logs please?

[Fernando Jiménez Moreno]

I have tested this with MB, Epiphany and Safari and in all cases video playback works if the video request goes to the network with no service worker interception.

For MB and Epiphany, the service worker is intercepting the non-range request that WK does to fetch video content and it is performing its own range request for the first ~1.5MB of video, adding the `Range` header to the intercepted request headers (they seem to be ignored though) and responding with a 206. This SW initiated range request is successfully fetching the first chunk of media and video playback starts as expected, but since there are no following requests, playback stops. The Fetch spec defines that a network error should be triggered if a partial response is provided to a privileged API that did not make a range request (Step 20 of https://fetch.spec.whatwg.org/#main-fetch from https://github.com/whatwg/fetch/commit/b166b6515d3166707dcaa76fb0fa3b8467cf03d0), so IIUC we should not even be playing the first chunk of video and throw that errro, but that's another issue. I need to check why we are not triggering the network error.

For Safari the situation is slightly different. Safari performs range requests by default to fetch the video content. It makes an initial 0-1 byte range request to check if the server supports it, expecting a 206 response containing the requested 2 bytes. Following with more range requests. In this case, I've only observed a single follow-up range request for WhatsApp videos. And what I see is that the service worker (which has a decryption step) generates a response with a `Content-Range` and a `Content-Length` smaller than the one requested. Video playback does not work in Safari at all if service worker intercepts the media request.

So long story short, this looks to me like a bug in WhatsApp's service worker code and I suggest closing this bug.

That being said, apart from the main playback issue, there are a few orthogonal issues, as previously reported:

- Sometimes the video is shrinked vertically when video playback stops in Epiphany. I have not observed this behaviour with MB or Safari.
- Sometimes the video is rotated 90° when video playback stops (or is restarted) in MB. I have not observed this behaviour with Epiphany or Safari. This may be related to the previous one and it may be an incorrect handling of the rotation metadata as philn suggested. I filed bug 222306 to track this issue.
- Sometimes the 'Cannot play video' overlay is shown on top of the video. When this happens, the video can still be played in MB. I filed bug 222307 for this.