-
Notifications
You must be signed in to change notification settings - Fork 9.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Range downloads design #8851
Comments
i will put my optinion about some of this points:
i think this is different from --no-playlist(the url contain information about video and playlist in the same) while in range url there is no ambiguity(the url clearly contain information about time):
or
or using what you've suggested:
|
Basically it's not about ambiguity but about what user expects. When you grab a video URL from somewhere you have no idea whether it contains time marks or not and may expect downloading of the full video. But yes it looks more reasonable to respect the time marks by default but a warning should definitely be printed. |
One argument I find for not making it the default is the following: you open a link like https://www.youtube.com/watch?v=BaW_jenozKc&t=2s on a browser and I decide to watch the video from the start, the URL is not modified (by their video player) and you copy the link from the location bar. If you pass it to youtube-dl now, wouldn't you expect it to download the whole video? This is not the case for different playlist or videos, as soon as you switch to a new one the URL is updated and when you copy it it refers to the video/playlist you are currently watching. An additional reason is that because it uses ffmpeg the download is not recoverable, since that departs from the normal behaviour of youtube-dl I think it would surprise most users. And since it's an important change I don't think we should base the decision just on the URL having some specific parameters. Personally I don't like too much that the parameters in the URL influence the file I get in the end, so I prefer if it isn't the default behaviour. But since I don't have know what most users would expect, my position is not too strong. |
than may be adding some option whould be better(for example: |
To clarify my view: actually I'm not opposed to using the parameters of the URL , I'm opposed to automatically cutting the video if they are present (I'm fine with mpv using them, but there you can seek to anywhere you want so it's not harmful). Since this is related to #622, your proposed --start-time and --end-time are quite useful anyway. So maybe |
- resume immediately - no need to concatenate segments and decrypt them on every resume - no need to save temp files for segments and for hls downloader: - no need to download keys for segments that already downloaded
as I played with: but Term returns What's wrong? |
After #8611 got merged there is an opportunity to implement #622.
The problems are:
--no-playlist
message analogy).best
is case of range download.--no-playlist
.As for me we the key question is whether this should be default or not. According to it we have the following possible outcomes:
--no-range-download
option (name is negotiable) to download the whole video.--range-download
to download only the rangeI'm not sure which one is better. We can also add and probably should add both options.
Any ontopic opinions and thoughts are welcome.
The text was updated successfully, but these errors were encountered: