Closed DoctorVanGogh closed 7 years ago
ZQJwjSjZJ0I
's bestvideo
and bestaudio
formats are served as dashsegments, i.e. the URLs you get with -g
are not URLs to the complete downloadable videos but base URLs to the locations where the segments are stored. For some reason this particular video serves the whole files via these base URLs but that is not the case in general (e.g. aclExbIzafg
). So it's legitimately ignores the external downloader and delegates to dashsegments downloader.
In case of H7Uyfqi_TE8
, bestvideo
and bestaudio
are non segmented dash and -g
returns URLs to complete downloadable files thus external downloader is respected in this case.
Please follow the guide below
x
into all the boxes [ ] relevant to your issue (like that [x])Make sure you are using the latest version: run
youtube-dl --version
and ensure your version is 2016.10.12. If it's not read this FAQ entry and update. Issues with outdated version will be rejected.Before submitting an issue make sure you have:
What is the purpose of your issue?
Error:
Youtube-dl seems to ignore the external-downloader argument and unnecessarily download certain streams using it's internal 'fragment' downloader.
Example
https://www.youtube.com/watch?v=ZQJwjSjZJ0I
Invoking a download with
youtube-dl --ffmpeg-location c:\ffmpeg\bin --external-downloader aria2c --external-downloader-args "-j 8 -s 8 -x 8 -k 5M" https://www.youtube.com/watch?v=ZQJwjSjZJ0I
should download two simple partial streams for subsequent joining by ffmpeg (I think it's trying the equivalent of-f 290+140
for the given video). Those partial stream downloads are not passed to the external downloader, but processed internally by the (m3u8?) fragment downloader. Notice the 'Total fragments: 418' line in the output:During download the target directory accumulates a lot of files in the
[Filename].[Format].ext.part-FragNNN
naming scheme.While this download works, it takes unnecessarily long - especially since the external downloader would have processed things way faster.
Workaround
The following workaround get's things downloaded faster:
Total ellapsed time using workaround: ~1min 30, about a third what plain youtube-dl invocation returns.
Counter-Example
Here's another stream, where youtube-dl exhibits exactly the expected behaviour and passes the actual downloads on to the external client:
Conclusion
I think the current youtube-dl behaviour for this example stream here is wrong. I have no idea if it's a stream or a youtube-dl issue. If an external downloader is passed then it should be used if at all possible.
I realize there are situations where this is not yet possible (m3u8 streams - see #6392), but things should work for this stream.