[youtube] maxresdefault doesn't exist sometimes
#340
Labels
Comments
|
It's easy enough to check for 404s, but its also not really necessary. yt-dlp automatically downloads the next thumbnail if one isnt found but anyway, the second best thumbnail is actually https://i.ytimg.com/vi/pS4ca4GB-_c/sddefault.jpg and https://i.ytimg.com/vi_webp/pS4ca4GB-_c/sddefault.webp (which yt-dlp doesn't find), not |
|
Just noting down the thumbnail URLs I know All of these also have webp versions like |
Ah, I was receiving the following error messages instead: It looks like this issue happens specifically when the
Interesting, I don't remember having seen |
|
the thumbnail shown in embed is normally the highest resolution one. So I opened |
pukkandan
added
bug
pukkandan
added
site-enhancement
|
live videos |
|
The only way I've found to fully fix this is to hardcode the URLs. But I'm not sure I should fix it this way because of how many additional requests it takes to figure out which of the URLs are working PS: Dont mind the ordering, it can be fixed The testing can be implemented lazily. So if only one thumbnail URL is requested, not all has to be tested. But the issue is when writing infojson, all URLs must be resolved even if the user has no actual interest in the thumbnails Another way to handle this to test the URLs only if the user requests so with This doesnt affect actual downloading of the thumbnail except for a warning: The issue then becomes that the URLs in |
|
I suspect that most users are interested only in finding the highest quality thumbnail, with the smaller sizes being less relevant. Perhaps it'd be okay to only include details on the best available thumbnail in the infojson by default, omitting the others completely unless additional flags are provided? It's probably also fine to treat failed thumbnail requests as expected behaviour, by not printing errors/warnings about them (unless in verbose mode). |
pukkandan
added a commit
that referenced
this issue
Jul 19, 2021
* Also fix bug where `_test_url` was being ignored Ref: https://stackoverflow.com/a/20542029 Related: #340
5 tasks
|
I don't know why I didn't think of this before. I can just put the best "known" thumbnail as Then If anyone wants to get the best thumbnail URL and don't mind the slowdown, they can use |
pukkandan
added a commit
that referenced
this issue
Oct 24, 2021
Lesmiscore
added a commit
to ytdl-patched/ytdl-patched
that referenced
this issue
Oct 25, 2021
* 'master' of https://github.com/yt-dlp/yt-dlp: [instagram] Fix bug in ab2ffab (#1403) Approximate filesize from bitrate Closes #1400 [youtube] Populate `thumbnail` with the best "known" thumbnail Closes #402, Related: yt-dlp/yt-dlp#340 (comment) Separate `--check-all-formats` from `--check-formats`
nixxo
pushed a commit
to nixxo/yt-dlp
that referenced
this issue
Nov 22, 2021
* The thumbnail URLs are hard-coded and their actual existence is tested lazily * Added option `--no-check-formats` to not test them Closes yt-dlp#340, Related: yt-dlp#402, yt-dlp#337, ytdl-org/youtube-dl#29049
nixxo
pushed a commit
to nixxo/yt-dlp
that referenced
this issue
Nov 22, 2021
* Also fix bug where `_test_url` was being ignored Ref: https://stackoverflow.com/a/20542029 Related: yt-dlp#340
9 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Originally posted by @Zirro here
I've received several 404's for
maxresdefaultURLs with this change, so unfortunately it doesn't seem to be true for every video. The best approach would probably be to initially requestmaxresdefaultand look at the response code. If it's 404, try withhqdefaultinstead.It could also be worth using a similar approach to check for the existence of a
.webp-version of the thumbnail at the/vi_webp/-path before falling back to the.jpgˋ-version, though the difference in quality doesn't seem to be very significant here.Here's one where there is no
maxresdefaultsize at all: https://www.youtube.com/watch?v=pS4ca4GB-_chttps://i.ytimg.com/vi/pS4ca4GB-_c/maxresdefault.jpg (404)
https://i.ytimg.com/vi_webp/pS4ca4GB-_c/maxresdefault.webp (404)
Here's one where both JPEG and WebP-files are accessible at separate URLs: https://www.youtube.com/watch?v=goSEyGNfiPM
https://i.ytimg.com/vi/goSEyGNfiPM/maxresdefault.jpg (200)
https://i.ytimg.com/vi_webp/goSEyGNfiPM/maxresdefault.webp (200)
Here's one where only the JPEG-file is available: https://www.youtube.com/watch?v=xp-b4Ce4Mf4
https://i.ytimg.com/vi/xp-b4Ce4Mf4/maxresdefault.jpg (200)
https://i.ytimg.com/vi_webp/xp-b4Ce4Mf4/maxresdefault.webp (404)
I'm not sure if there are cases where only the WebP exists, though. Besides that it's mainly a question of whether checking for the
.webpfirst should be done for the theoretical quality improvement, with the.jpgstaying as fallback when there is no WebP available.The text was updated successfully, but these errors were encountered: