You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Thumbnail - small image preview, in our case, thumbnails are used in Video Tiles to show image associated with a given video
Poster - bigger image that's acting as a placeholder for the video player when the media is not available or the playback has ended
The problem
Currently in Atlas we use both thumbnails and poster - thumbnails are displayed in grid and general content discovery and posters are used in the video player - they're visible briefly when the playback hasn't started yet and also when next video is suggested on the video player ending overlay. Even though thumbnails and poster are used in different contexts, we currently use a single image file for both of them. The problem is that the video poster needs a decent image resolution (it will be displayed in the video player), but the thumbnail should be as small as possible to decrease the bandwidth usage. For the single image we used 1080p previously, currently we use 720p. However, it still is too much for the thumbnail and forces users to load excessive data.
Possible solutions
I see two ways we can go about fixing this problem:
1. Add support for a separate poster image
We could add support for a separate poster asset. This way when the user publishes a video and crops the image, we would generate two files instead - low and high resolution and upload them both to the storage network. Then those 2 files could be used depending on the context. This would require on-chain content directory changes. Because the files have to be pre-generated, this would also increase the size of the storage network because now 2 files are stored instead of one.
2. Drop poster support entirely
Instead, we could say that we only use thumbnails in the platform and get rid of posters altogether as their usage seems to be pretty minimal. I've investigated and that's the approach that YouTube uses - they have only thumbnails. This could allow us to upload only low resolution image, which would lower the storage size and the bandwidth needed to load the app. Some changes would be needed to the video player component but those seem to be not so complicated.
Summary
I suggest we go with the second solution I proposed and I suggest we do this sooner than later - the amount of changes necessary doesn't seem to be too high and we decrease the storage and bandwidth usage going forward. Please share your thoughts.
The text was updated successfully, but these errors were encountered:
Thank you for such a detailed problem description, Klaudiusz!
While YouTube indeed does not seem to be using the term "Poster", their "Thumbnails" actually act as posters, which you can see eg. when casting a video to your TV (a reminder that casting is also planned for Atlas video player).
On YouTube Help Center, it's actually mentioned that a minimum width for a YouTube video thumbnail is 640px. And it looks like more than one image file is generated from the thumbnail uploaded by the user: example 1, example 2.
And so, while it's obvious to me why would one lean towards the second solution you mentioned, upon closer YouTube inspection I'm afraid we might be forced into the first one, which I would vote for.
Right, I did investigation but don't have any device I could cast to and missed that. If I'm not wrong though, casting is the only place where this poster is actually used on YouTube? Also, the fact that YouTube uses a poster when casting doesn't mean we have to do the same thing. I think we could very well display something else when casting? Maybe a generic illustration or something? I still think the introduced platform complexity may not be worth it.
Of course, I understand. Sure, there are other possibilities for tackling the casting use case in the context of the poster image in the video player. If we're all open to slightly changing the player component designs because of this, then I'm open to the second solution you proposed! :)
Definitions
Thumbnail
- small image preview, in our case, thumbnails are used in Video Tiles to show image associated with a given videoPoster
- bigger image that's acting as a placeholder for the video player when the media is not available or the playback has endedThe problem
Currently in Atlas we use both thumbnails and poster - thumbnails are displayed in grid and general content discovery and posters are used in the video player - they're visible briefly when the playback hasn't started yet and also when next video is suggested on the video player ending overlay. Even though thumbnails and poster are used in different contexts, we currently use a single image file for both of them. The problem is that the video poster needs a decent image resolution (it will be displayed in the video player), but the thumbnail should be as small as possible to decrease the bandwidth usage. For the single image we used 1080p previously, currently we use 720p. However, it still is too much for the thumbnail and forces users to load excessive data.
Possible solutions
I see two ways we can go about fixing this problem:
1. Add support for a separate poster image
We could add support for a separate poster asset. This way when the user publishes a video and crops the image, we would generate two files instead - low and high resolution and upload them both to the storage network. Then those 2 files could be used depending on the context. This would require on-chain content directory changes. Because the files have to be pre-generated, this would also increase the size of the storage network because now 2 files are stored instead of one.
2. Drop poster support entirely
Instead, we could say that we only use thumbnails in the platform and get rid of posters altogether as their usage seems to be pretty minimal. I've investigated and that's the approach that YouTube uses - they have only thumbnails. This could allow us to upload only low resolution image, which would lower the storage size and the bandwidth needed to load the app. Some changes would be needed to the video player component but those seem to be not so complicated.
Summary
I suggest we go with the second solution I proposed and I suggest we do this sooner than later - the amount of changes necessary doesn't seem to be too high and we decrease the storage and bandwidth usage going forward. Please share your thoughts.
The text was updated successfully, but these errors were encountered: