[Webkit-unassigned] [Bug 189444] New: [GStreamer] webkitwebsrc fails to handle non seekable sources

[bugzilla-daemon at webkit.org]

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

            Bug ID: 189444
           Summary: [GStreamer] webkitwebsrc fails to handle non seekable
                    sources
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebKit Gtk
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: aboya at igalia.com
                CC: bugs-noreply at webkitgtk.org

Background: The HTTP response header Accept-Ranges specifies whether the server accepts Range (partial) requests. The valid values are "bytes" (ranges allowed) or "none" (ranges not allowed).

Accept-Ranges is not always used and what to assume in its absence AFAIK is not specified by the HTTP 1.1 RFC. (MDN seems to imply that "none" is the default, but I could not find a source to confirm that.)

In the case of webkitwebsrc, this is the condition to determine whether a given source is seekable:

priv->seekable = length > 0 && g_ascii_strcasecmp("none", response.httpHeaderField(HTTPHeaderName::AcceptRanges).utf8().data());

That is, the length of the response must be defined in the headers (i.e. it won't attempt to seek if the response is chunked) and Accept-Ranges must not be explicitly set to "none".

If the source is deemed to be seekable but when later webkitwebsrc receives a seek this turns out to be a wrong guess, the HTTP response will be consumed until the seek target position is reached. This is wasteful, but at least playback works this way.

So far so good. The problem is the other case, when priv->seekable is set to false. By the time that code is run, the pipeline has already been running to the point all elements potentially interested in seeks have already queried the seekability of the source and received a positive response. That is potentially problematic, but let's keep going.

Following that code, there is this other one:

    // notify size/duration
    if (length > 0) {
        if (!priv->haveSize || (static_cast<long long>(priv->size) != length)) {
            priv->haveSize = TRUE;
            priv->size = length;
            gst_app_src_set_size(priv->appsrc, length);
        }
    } else {
        gst_app_src_set_size(priv->appsrc, -1);
        if (!priv->seekable)
            gst_app_src_set_stream_type(priv->appsrc, GST_APP_STREAM_TYPE_STREAM);
    }

gst_app_src_set_size() makes sense there. Something stranger is that `gst_app_src_set_stream_type(priv->appsrc, GST_APP_STREAM_TYPE_STREAM)` is only called in the case where the file size is unknown. The only effect this call has at this point is that appsrc will automatically reject any seeks and will stop advertising support for seeks (not that it matters at this point, as mentioned before).

appsrc rejecting seeks will not make any difference in practice though, because webKitWebSrcSeek() will return FALSE immediately if !priv->seekable.

Seeks will still happen though. The next problem is that downloadbuffer does not handle failed seeks at all, effectively stalling forever. https://bugzilla.gnome.org/show_bug.cgi?id=797098

-- 
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/20180908/dd5774b0/attachment.html>