Enable Accept-Encoding header for DASH/M3U8 playlist requests for Youtube Live streams

[jmf1988]

Please follow the guide below

• You will be asked some questions and requested to provide some information, please read them carefully and answer honestly
• Put an x into all the boxes [ ] relevant to your issue (like this: [x])
• Use the Preview tab to see what your issue will actually look like

---

Make sure you are using the latest version: run youtube-dl --version and ensure your version is 2019.02.08. If it's not, read this FAQ entry and update. Issues with outdated version will be rejected.

• [ x] I've verified and I assure that I'm running youtube-dl 2019.02.08

Before submitting an issue make sure you have:

• [x ] At least skimmed through the README, most notably the FAQ and BUGS sections
• [ x] Searched the bugtracker for similar issues including closed ones
• [ x] Checked that provided video/audio/playlist URLs (if any) are alive and playable in a browser

What is the purpose of your issue?

• Bug report (encountered problems with youtube-dl)
• Site support request (request for adding support for a new site)
• [x ] Feature request (request for a new functionality)
• Question
• Other

Description of your issue, suggested solution and other information

I noticied after many tests that for long live streams with backbuffer enabled each requests to download hls playlists and dash manifests uncompressed eat sometimes way more bandwidth that the actual segments on low/medium quality live streams because the list is too long, this hurt in latency and performance is just unreallistic for live media, and, because this can be avoided by adding the "Accept-Encoding: gzip" header on requests to the manifest/playlist only to any downloader or ffmpeg, I am requesting to reenable the header by default, at least only for m3u8 protocol. Thank you.

[dstftw]

Live HLS is handled by ffmpeg. Which headers it will send is out of control of youtube-dl.
https://trac.ffmpeg.org/ticket/7158

[jmf1988]

Live HLS is handled by ffmpeg. Which headers it will send is out of control of youtube-dl.
https://trac.ffmpeg.org/ticket/7158

Then why if I comment the line 1971 in youtube.py it pass the header to ffmpeg ?
The line above that says that was disabled for causing failures, which is too vague, does not say which failure and where.
I know is a bug of ffmpeg, but ffmpeg is not a youtube specific tool and if it can be fixed by just passing a header why not?