Opened 8 years ago
Last modified 17 months ago
#7158 open enhancement
Attempt HTTP compression
| Reported by: | DeHackEd | Owned by: | |
|---|---|---|---|
| Priority: | wish | Component: | avformat |
| Version: | git-master | Keywords: | http |
| Cc: | MasterQuestionable | Blocked By: | |
| Blocking: | Reproduced by developer: | no | |
| Analyzed by developer: | no |
Description
Some live streaming servres (such as Youtube live feeds) can generate multi-megabyte .m3u8 files when uncompressed and on long feeds. Accepting gzip'd playlist files can both save bandwidth and dramatically improve playback performance.
I've tested this by just using "Accept-Encoding: gzip" but I don't think that would be an acceptable solution.
Change History (5)
comment:1 by , 8 years ago
comment:2 by , 8 years ago
| Keywords: | http added |
|---|---|
| Priority: | normal → wish |
| Version: | unspecified → git-master |
comment:4 by , 2 years ago
| Cc: | added |
|---|---|
| Summary: | Send "Accept-Encoding: gzip" on .m3u8 HTTP requests → Attempt HTTP compression |
͏ Typical reasonable:
͏ Accept-Encoding: gzip, deflate, br
͏ Disregard, it needs the decompressor support.
comment:5 by , 17 months ago
| Status: | new → open |
|---|
Merge #9555 into this one
This thing is really terrible https://github.com/mpv-player/mpv/issues/14360
http_seekable=0 is needed because, without it, ffmpeg includes a Range: bytes=0- request header which causes the server to send a non-compressed reply.
Note:
See TracTickets
for help on using tickets.
I just came across this in my own testing.
I have a couple of live-event streams that can generate a 1mb big playlist.
It would benefit everyone if that m3u8 can be gzipped instead.