Range downloads design

[dstftw]

After #8611 got merged there is an opportunity to implement #622.

The problems are:

1. The main question we should decide is whether we want range downloading scenario by default.
2. We need to notify the user in some way about what actually happens, whether we are downloading a fragment rather that the whole video or not (something like --no-playlist message analogy).
3. For DASH there is a high probability of async in resulting muxed file due to approximate audio/video fragment boundaries. Most likely we'll need to fallback to best is case of range download.
4. We probably need an option to enable/disable range download similar to e.g. --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:

1. Download fragment by default when possible and output a warning message that is only fragment is being downloaded and suggest using a --no-range-download option (name is negotiable) to download the whole video.
2. Download whole video by default and output a warning message suggesting using --range-download to download only the range

I'm not sure which one is better. We can also add and probably should add both options.
Any ontopic opinions and thoughts are welcome.

[remitamine]

i will put my optinion about some of this points:

1. The main question we should decide is whether we want range downloading scenario by default.

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):
http://www.youtube.com/watch?v=BaW_jenozKc&t=1s&end=9
so it should be the default to respect the download url information.

1. For DASH there is a high probability of async in resulting muxed file due to approximate audio/video fragment boundaries. Most likely we'll need to fallback to best is case of range download.

• from man page of ffmpeg it said that:

When transcoding and -accurate_seek is enabled (the default), this extra segment between the seek point and position will be decoded and discarded. When doing stream copy or when -noaccurate_seek is used, it will be preserved.

or

• if we pass the info dict directly to the downloader and let ffmpeg download all files it shoud sync the files(need some tests).
  example:
  ffmpeg -t start -ss duration -i video_url -i audio_url -c copy out.ext

or using what you've suggested:

• Most likely we'll need to fallback to best is case of range download.

[dstftw]

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)

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.

[jaimeMF]

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.

[remitamine]

And since it's an important change I don't think we should base the decision just on the URL having some specific parameters.

than may be adding some option whould be better(for example: --start-time and --end-time or --duration) and ignore the params of the url, this will make it possible to support the feature in all extractors.

[jaimeMF]

than may be adding some option whould be better(for example: --start-time and --end-time or --duration) and ignore the params of the url, this will make it possible to support the feature in all extractors.

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 --range-download tries to use the url parameters, while --start-time and --end-time override it or are used if the URL has no parameters. I had though of something like --download-range auto to use the URL parameters and --download-range start-end (start or -end would also be allowed), but then you can't just override one of the parameters from the URL (not sure if that's feauture is that useful).