-
Notifications
You must be signed in to change notification settings - Fork 798
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
"begin" option doesn't affect when the video starts #129
Comments
I tested this with a longer video. And for some odd reason, when I try the I'm going to guess that this is some YouTube limitation where it won't let you request the download if the time is too close to the start of the video, or the video is too short. |
I tested what you're saying here and saw similar results -- longer videos didn't ignore the "begin" option. Maybe this should be noted in the docs, just as a warning? |
I also was having some issues with the begin option not working correctly, but then I saw this issue was closed. However, I found something interesting. In the original video that @joek13 uses in the example, if you use the begin option at 6s, the video starts at the beginning. But with this similar video of identical length (https://www.youtube.com/watch?v=0tjUqKNf7gU), using the begin option at 6s works exactly as intended. The only difference between the two videos as far as I could tell was the quality, the former being 360p and the latter being 1080p. I did some further testing and found that the begin option consistently did not work with any videos 480p quality and below, even taking into consideration the "five second rule" thing. So I think the length of the video doesn't actually matter if it's longer than 5s, but the quality does in terms of whether the begin options works or not. Is there anything obvious that I might be missing to cause this to not work, or is this an actual new bug? |
That's really weird. I wish things were more consistent with YouTube. |
Any update on this ? I am using filter 'audioonly' and I couldn't find a video wich works with begin parameter. |
As above states, it looks like it won't work with any video 480p or below. I also tried using it with a super long video that's in 1080p, and it also wouldn't work with There's not much that can be done, except.... post-processing with something like ffmpeg. But even so, the whole file including the non-wanted starting section would have to be downloaded. |
Yes that's what I was trying to avoid ... Couldn't it be possible to use range option to download from a start point and use ffmpeg convert it ? I already use ffmpeg to convert to 16bit PCM so ... I tried to feed the stream to ffmpeg but it keep failing because it cannot recognize input format I guess. But I don't see how to specify it.. Any clue ? Otherwise with ffmpeg we can specify seekInput but that implies downloading the file from the beginning. |
The It's also difficult to guess the byte range based on a given time. |
That's what I want: give ffmpeg a hint on the format .. but I can't figure out any option of ffmpeg that does that. The other solution here is to download metadata and then only starts at the given range. Writing them to the stream should hint ffmpeg. I'll try investigate that ..
If we know the format we should be able to calculate the byte position of a given time. |
Okay downloading the beginning and then jump at a given time works (if we have the offset corresponding to the given time). For example, for itag The header length depends on the itag so I guess the simpler will be to map header lengths into format metas. But you were right, I find it very hard to calculate the offset of a given time .. HTML5 media element does that, and chromium uses ffmpeg (https://www.chromium.org/developers/design-documents/video) ... Maybe you have an idea on how to get this offset ? For now I am using EDIT: I found a way to predict time -> range, is that okay if I create a PR ? |
As the title says, when invoking ytdl, the begin option doesn't actually affect where the video starts to download.
An example:
The resulting downloaded video starts at the very beginning, regardless of the value of "begin."
The text was updated successfully, but these errors were encountered: