[Webkit-unassigned] [Bug 115354] Disable HTTP request "Accept-Encoding:" header field on gstreamer source element to avoid receiving the wrong size when retrieving data

[bugzilla-daemon at webkit.org]

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





--- Comment #10 from Andre Moreira Magalhaes <andrunko at gmail.com>  2013-04-29 08:47:31 PST ---
(In reply to comment #9)
> (In reply to comment #8)
> > (In reply to comment #7)
> > > (In reply to comment #6)
> > > > Could this be the cause of bug 90732 ?
> > > 
> > > hmm, could be, but most likely you need the patch from bug 115353. What happens here is that libsoup downloads the compressed data and extracts it using SoupContentDecoder, but returns the size of the specified Content-Length instead, thus the size of the uncompressed data differs from the actual reported size.
> > 
> > I don't think this is the right fix. By doing that you're increasing the http transfers potentially by a lot since the server won't compress data. The problem is that you cannot assume that you could know the actual size of the data after receiving the http headers. It is not true for compressed data as you said but it isn't also true for "Transfer-Encoding: chunked" or for responses without encoding (ended when the connection closes).
> > 
> > So my advice would be to try to reorganize the gstreamer code in order not to depend on the size of the data, not sure if that's possible tough.
> 
> hmm, the webkit source element uses the content length to compute the duration of the stream. If the size is reported as 0, the stream will be considered a live stream, failing to seek and other small "issues".
> 
> I am not sure what would happen if using "Transfer-Encoding: chunked" (not even sure if that is set by libsoup when requesting). Right now IIRC ResourceHandleClient::didReceiveResponse() is called only once and we get the size from response.expectedContentLength() and set the duration based on it. ResourceHandleClient::didReceiveData() is called on every data chunk downloaded though, but we don't use the size reported there as we want to know the duration in advance, not during playback (when the data is actually downloaded).
> 
> In other words, it could be that "Transfer-Encoding: chunked" would lead to some issue, but I am not sure and we tested these patches in a series of scenarios using DASH/MSS/HLS adaptive and other non-adaptive streams and didn't find any issue.

Additionally, I agree that the best approach would be to get the proper size but still use compressed data to avoid increasing network traffic. That would probably require some patch on libsoup itself, but at least the patch above only disables compression for playback, which is currently "broken" (wrong duration) when the server returns compressed data.

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