Jpeg fallback not used when webp is missing

[timkinali]

When the webp image is missing for a video, youtube serves their own fallback image in it's place. So, the webp-image is never really missing from the browsers point of view, which means that the JPG fallback is never used.

In my project this happens with quite a lot of videos. Any custom workarounds I could do to fix it? Perhaps there could be an option to disable webp?

Example, videoid FqpiXeG1eJg :

https://i.ytimg.com/vi_webp/FqpiXeG1eJg/hqdefault.webp // renders youtubes fallback image https://i.ytimg.com/vi/FqpiXeG1eJg/hqdefault.jpg // renders the correct image, but is never used

[justinribeiro]

Hummmm interesting, I haven't seen this case outside of the lag of video processing. I think I can determine this and flip it, let me take a swing at it.

[readtedium]

I’m seeing this on my end as well, FYI.

[wilbertcaba]

@justinribeiro have you found a fix for this issue? I'm running through the same problem as well.

[mrwweb]

I was curious if it's possible to nudge YouTube to generate the webp format for videos. No luck yet, but I did find someone asking about this on StackOverflow. Something to keep an eye on. For my own implementation of this, I'm currently considering rolling back to the JPEGs… :/

[mrwweb]

@justinribeiro I think I may have found a way to detect this. It's been bothering me for a while! It's a pretty common issue, but I haven't found a lot of solutions that don't involve proxying through a server to avoid the CORS issue or using the YouTube API, neither of which feels right here.

Quite note re: "I haven't seen this case outside of the lag of video processing." This is an issue on older videos, where it seems YouTube hasn't retroactively gone back and generated webp. Here's an example of a video where that's the case.

Things I've learned:

• The picture element spec is happy to show a 404 response that has valid image data. I was confused about the general behavior, but I guess what we see is what's intended
• Trying to fetch the webp thumbnail image gets blocked by CORS so that's not an option.
• The YouTube fallback image is 120px wide

It was that last point that was my "aha!" moment. I suspect you might change the implementation and style, but I am able to fall back to the JPG by doing the following at the end of initImagePlaceholder():

// the onload event on the img element detects when a `source` element in the parent `picture` element has loaded
this.domRefImg.fallback.onload = (e) => {

	// if the webp is 120px wide, then we know it's the fallback thumbnail and not one we want
	if ( e.target.naturalWidth === 120 ) {

		// this removes the first `source` of the parent `picture` element. That means it will recursively go through `source` elements in order until it finds one that isn't 120px wide
		e.target.parentElement.firstElementChild.remove();

	}
};

Since that test is only watching for the placeholder thumbnail and not an explicit format, I think it would also fix the poster resolution issues in #102 that seem very similar to this issue / #97

Finally, this does require waiting for the webp to load, so I could imagine adding a new posterformat (postertype?) attribute that defaults to webp but allows jpg as a means of omitting the webp source when authors know the webp image doesn't exist.

Curious what you think and hoping maybe this could be a path to a solution!

[timkinali]

@justinribeiro have you had a chance to look into this?

[f1shy-dev]

Maybe fetch the image seperately as blob, then check for 404 errors? However this would add extra code which might go against the whole point... "lite"