[Webkit-unassigned] [Bug 85994] [GStreamer] Source element fails with .ogg files

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Jul 4 02:10:35 PDT 2013


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





--- Comment #22 from Andres Gomez Garcia <agomez at igalia.com>  2013-07-04 02:12:34 PST ---
As it is explained, the difference seems to be that the Google Frontend server from playmapscube doesn't provide a "206 Partial Content" response to a "Range" request if it has already answered with a "200 OK" response to a previous request for the content.

Igalia's Apache server actually behaves like that and is what WebKitWebSrc expects.

Not that Google's server behavior is wrong. WebKitWebSrc should be able to handle that.

Other than that, WebKitGtk behavior doesn't seem really optimal.

>From the log, we see that:
1. First, the internal ResourceHandle requests the resource, when it gets the headers and checks the one:
"Content-Type: audio/ogg"
Cancels the rest of the response message and passes the URL to the Mediaplayer, which uses the WebKitWebSrc to request the same resource.

This is, we re-start the communication, as if the previous would not have happened.

2. The WebKitWebSrc requests the resource. When it gets the "200 OK" response it starts buffering the received data but, at some point, it cancels the response message in order to request a "Range" as it seems it is a "seekable" resource.

3. The WebKitWebSrc requests the resource, but with a range from the byte in which it stopped to the end of the media.
Google frontend: answers with a "200 OK" and WebKitWebSrc doesn't know how to handle this.
Apache: answers with a "206 Partial Content" and sends the rest of the data.

4. For some reason, although receiving the rest of the content, the response message also gets cancelled.

5. The WebKitWebSrc requests the resource, but with a range from the first byte to the end of the media.

6. Now all the content is retrieved without interruption and the media starts playing.

---

It is clear that even in the working case the behavior is not really good.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list