GNOME Bugzilla – Bug 795605
adaptivedemux: Can't handle HTTP compressed subtitle segments
Last modified: 2018-11-03 14:22:14 UTC
The DVB DASH profile requires conformant clients to support gzip HTTP compression. This is generally enabled for TTML subtitle segments, which will compress down nicely. Currently, however, if a server serves subtitle segments with gzip content-coding, souphttpsrc will not decompress the response body and the ISOBMFF parsing code within dashdemux will block trying to find an mdat box, causing the whole pipeline to stall. The attached patch sets the "compress" option on adaptivedemux's internal souphttpsrcs to true, which fixes the problem. A consequence of the fix is that every segment request will have an "Accept-Encoding: gzip, deflate" header in it. But, according to the HTTP RFC, servers are always allowed to return uncompressed data to such a request. The default behaviour of browsers seems to be to add this header to every request they make.
Created attachment 371459 [details] [review] Allow compressed HTTP responses
The problem with adding compression by default is that the Content-Length is the compressed one usually, or not? So you don't really know how many uncompressed bytes you'll have to expect
You're right, it is the compressed length. But what's the problem with not knowing the number of uncompressed bytes to expect?
Duration estimation and seeking
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/697.