Closed Twixes closed 4 years ago
Merging #43 into master will not change coverage by
%
. The diff coverage isn/a
.
@@ Coverage Diff @@
## master #43 +/- ##
=======================================
Coverage 90.94% 90.94%
=======================================
Files 14 14
Lines 917 917
=======================================
Hits 834 834
Misses 83 83
Continue to review full report at Codecov.
Legend - Click here to learn more
Ξ = absolute <relative> (impact)
,ΓΈ = not affected
,? = missing data
Powered by Codecov. Last update 2801505...e046c76. Read the comment docs.
thanks @Twixes ! I'll test this out later today. Could this approach be used to enable parallelized downloads on a single stream? π€
Possibly, although I don't think parallelization would be helpful, since it'd add additional overhead and the bottleneck is the client's internet connection anyway, not computing power.
@Twixes what did you do to test this? I tried comparing speeds here to the release branch on a couple of videos and had basically identical load times π€
This seems pretty significant. The difference persists across tries and URLs.
OK, it seems that it's not that consistent and enables uninterrupted download for some streams, but not all. I've yet to find out how it works exactly. π
@Twixes I'm going to merge this for now, but I think there's more investigation to do here... might be an issue with chunking within pytube, since your example show curl calls...
YouTube is throttling downloads without the
Range
header, which is used by browsers when streaming (for example with an implementation of the<video>
HTML tag ) but not on whole downloads. We can easily bypass this, however, by just addingRange: bytes=0-
to the request. The result is all the same bytes as before but in a much shorter time.