-
Notifications
You must be signed in to change notification settings - Fork 111
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
Nature of Code track video preview images #1645
Comments
Non-challenge videos rarely have distinct thumbnails on the site, probably because they are never displayed on the site and only when sharing links? We could fix this pretty easily by downloading the YouTube video thumbnails to the codebase. They have a predictable URL structure on their CDN: ex: https://i.ytimg.com/vi/Rob0pbE7kks/maxresdefault.jpg EDIT: BTW there are webp versions on the YT CDN too. The site expects jpg or png for the video images, which is why I went with jpg. The extension and root directory are different: |
Actually, since #1310, the image should fall back to the track's cover image, if the video itself doesn't gave a thumbnail. For example: Video from ml5 track, doesn't have any thumbnail image associated with it, falls back to ml5 track's cover image. However, there is an issue with this specific video (Vector Math, and a few others from NOC), these videos actually have a thumbnail defined (probably an artifact from the design/testing phase), which is in fact the last fallback placeholder image for all videos, which is in this case being used for the preview cc @fturmel |
Ah nice to know they'll fall back to the track image properly. I also noticed these placeholder thumbnails were manually copied and not the actual fallback, a bit strange. So, I guess we have some options for the preferred behavior:
|
I do wonder, if adding all these images in the repo, even though they are nowhere used on the site, only for link preview purposes is worth it ... Could we directly set the YouTube's thumbnail url as the og:image during build time, or is that a bad idea? |
That did cross my mind, but the high res thumbnail is not always available so we have to check for 404s and downgrade accordingly to find the best available match. See https://stackoverflow.com/questions/18029550/fetch-youtube-highest-thumbnail-resolution EDIT: You still raise a valid point, and the option 1 in my previous comment would be a way around this. The cost comes mostly in repo storage and hashes to compute during build, which I think will not be very significant in the end. The images will not get recompressed or uploaded again. The initial build and deploy for these new assets was completed in 4min 16sec https://app.netlify.com/sites/codingtrain/deploys/66885b6b5b425e00088505ef |
Thanks for the work on this! I'm fine either way, this isn't really a high priority for the reason @fturmel states that they aren't ever displayed on the site. But this has revealed some helpful info for what is my priority right now over here! nature-of-code/noc-book-2#985 |
I have created #1648 as an alternative to #1646, corresponding to "Option 1" as discussed above. Unrelated, here is a demo of using directly the ytogimg3.mp4 |
@dipamsen Nice! It would be a great approach if the maxres image was more predictably available. Here's an example of a 720p video without the maxres, we have to fallback to a lower resolution image: |
Thanks for all of this! I prefer having the specific YT thumbnail for the shared image but I don't mind having a low-res one or if it's not available just using the track thumbnail. In this case would it make sense to just Another pro is that I am slowly updating all YT thumbnails in which case I wouldn't have to remember to re-run the import script whenever a thumb changes. The con, however, is that it's nice to have a back-up / reference of all of my YT thumbnails here in this repo. Not sure why I am having so much trouble deciding on this! Any votes? |
I have some additional info:
const thumbnailResolutions = [
'maxresdefault', // 1280x720 - may not be available for 720p videos
'sddefault', // 640x480
'hqdefault', // 480x360
'mqdefault', // 320x180
'default' // 120x90
];
|
Is using a custom proxy server which returns the highest available version of the image, viable? Here's one I just created:
|
Yes, that's definitely a possible approach. Netlify Edge Functions are just white-labeled Deno Deploy IIRC so the demo is on point. I think it's also possible to cache the response on the CDN with the proper response headers to reduce the amount of function invocations. Could we even just turn this into a redirect service instead? HEAD requests to the YT CDN to determine the highest res available, then respond with a 301 or 302 + YT CDN URL directly instead of eating the bandwidth cost? Some considerations:
|
Thanks for all of this discussion! I think we should (a) delete the non-challenge video images currently in the repo (which will cause the fallback to be the track image and (b) use video thumbs when available either via the YT CDN or @dipamsen's proxy server or whatever you both recommend! I think I should go ahead and merge #1648 and then we can proceed from there? What do you all think? |
Works for me! I just closed #1646. |
Sorry to not have followed this closely, is this all set now? |
This is a small thing but I'm adding links from natureofcode.com to here (see: nature-of-code/noc-book-2#985) and noticed that the NOC videos are just using the default site image and it would be nice to update them at some point!
The text was updated successfully, but these errors were encountered: