Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upGitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
External downloader argument ignored - fragment downloader used for mp4 stream #10925
Comments
|
|
Please follow the guide below
xinto all the boxes [ ] relevant to your issue (like that [x])Make sure you are using the latest version: run
youtube-dl --versionand 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=ZQJwjSjZJ0Ishould download two simple partial streams for subsequent joining by ffmpeg (I think it's trying the equivalent of
-f 290+140for the given video). Those partial stream downloads are not passed to theexternal 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-FragNNNnaming 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.