[Webkit-unassigned] [Bug 209719] [GStreamer] Video playback fails in web.whatsapp.com

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=209719

Fernando Jiménez Moreno <fjimenez at igalia.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jaffathecake at gmail.com,
                   |                            |youennf at gmail.com

--- Comment #8 from Fernando Jiménez Moreno <fjimenez at igalia.com> ---
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20210223/03e60e63/attachment.htm>