Two questions about this:

1. It appears that we check for pendingUpload?.thumbHash in two places: here, and on line 152 of multimedia.react.js. Are both checks necessary?
2. In what scenarios do we want to show the thumbHash for a pending upload? I would guess that the pending upload will be rendering a local object URL, which should already be preloaded. But I may be missing something.

Can you add a comment to the CSS as well, to make sure that if somebody changes the CSS they also change this number?

Can you explain a little bit why we can't handle this with something like object-fit: scale-down? Ideally we could avoid the manual width calculation, but I'm guessing there's some reason we need it

Why do we need to wait for the video to be loaded before we show the thumbnail? It seems to me that we only need to wait for the thumbnail to be loaded. What if we await preloadImage in the effect above, and call setVideoLoaded(true) afterwards?

Besides the UX benefit of showing the thumbnail earlier, this also addresses an unlikely race here, where if the video loads before the thumbnail we might end up rendering the thumbnail before it's ready.

Might be good to add a . here so it's searchable

Thanks for explaining – that makes sense, the CSS can't work if the image isn't loaded, since preserving the aspect ratio in CSS requires knowing the dimensions, and CSS is getting the dimensions from the loaded image

We want to display thumbhash (blurry placeholderImage) while the video is loaded, right?

Here's the order of display I think we should do:

1. While the thumbnail is still loading, show the thumbhash
2. Once the thumbnail is loaded, show the thumbnail. Assuming that playing at this point is not possible (certainly for encrypted media), we may also want to do something to hide the play button if possible
3. Once the video is loaded, continue showing the thumbnail. If we're hiding the play button in step 2, at this point we can start to show it

What do you think of this approach? I think it could be achieved by the suggestion in my previous comment:

What if we await preloadImage in the effect above, and call setVideoLoaded(true) afterwards?

This would cause that non-blurry thumbnailURI is displayed while the actual video is still loading (except that unlikely race)

I think this is exactly what we want – for the non-blurry thumbnail to be displayed while the actual video is still loading. I figure that the thumbhash is there to display while we load the thumbnail.

In that case, the thumbhash for non-encrypted media is not needed at all because the browser generates thumbnails directly already and it's doing it pretty fast.

Showing a browser-generated thumbnail still requires a secondary download step, whereas the thumbhash is always delivered alongside the content metadata. I haven't measured, but I suspect there is a discernable difference in scenarios where the content isn't cached locally.

In practice, decrypting thumbnails would also be so quick that the blurry thumbhash would only blink for a very short time before being replaced by an actual thumbnail (btw thumbhash also needs to be decrypted)

The encrypted thumbnail still requires an additional download step, no? Whereas the encrypted thumbhash is available as soon as the client is aware of the message.