adaptivedemux: Can't handle HTTP compressed subtitle segments
Submitted by Chris Bass
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.