[Feature Request] Allow use of an external downloader for getting video info/subtitles/thumbnails/etc.

[jcjordyn130]

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.03.18. If it's not, read this FAQ entry and update. Issues with outdated version will be rejected.

• I've verified and I assure that I'm running youtube-dl 2019.03.18

Before submitting an issue make sure you have:

• At least skimmed through the README, most notably the FAQ and BUGS sections
• Searched the bugtracker for similar issues including closed ones
• 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)
• Feature request (request for a new functionality)
• Question
• Other

Description of your issue, suggested solution and other information

Explanation of your issue in arbitrary form goes here. Please make sure the description is worded well enough to be understood. Provide as much context and examples as possible.
If work on your issue requires account credentials please provide them or explain how one can obtain them.

Downloading all of the subtitles opens a connection, downloads the info, closes the connection, and repeats. On certain networks (mostly just high latency ones) this causes it to go slower than it otherwise would because it's opening all those connections. I propose that youtube-dl uses the --external-downloader command line argument if given to download videos instead of the internal downloader. This would allow the use of an external downloader that caches the connections to bypass a lot of the latency.

[dstftw]

Does any of the supported external downloaders even supports connection caching between executions? I doubt that. Also such TCP connection reuse may bring observable benefit only when there are lots sequential connections to the same host that is not usually the case for downloading non-media data. Times taking external downloader process to start also should be counted and may easily outperform any speedup of connection reuse. Needless to say this will unnecessarily complicate code.
So the bottom line is: this will barely have any positive effect.

[jcjordyn130]

The only case where this would be (really) useful is for getting all subtitle languages, on a platform like YouTube this can easily reach the hundreds (YouTube supports around 107 languages). On the network I'm on it takes 2 seconds per subtitle to download (high latency high bandwidth). it only takes 0.219s to start python3 and import urllib3. So if I download all subtitle languages it's 214 seconds of total download time vs 23.433 seconds of starting overhead. If you are just downloading a video or two this is barely anything, but on a big playlist or a whole channel it adds up. The two ways this can be implemented are modifying --external-downloader to accept arbitrary commands or modify the internal downloader to use urllib3.HTTPConnectionPool.

[rautamiekka]

Does any of the supported external downloaders even supports connection caching between executions? [...]

Not between executions, but during the same execution I know wget does.

[jcjordyn130]

Update: I found out that it was the DNS server being slow that caused the slowness in downloading.