Eliminate YouTube thumbnail black bars

Feature
1

YouTube embeds were improved a while ago by removing the black bars if they were present.

However these persist in Thumbnails of many videos. Can this be addressed too?

3 Likes
2

The particualr change about the back bars came down to using the maxresdefault image instead of the hqdefault. Not all videos have a high res thumbnail though, so in those cases, we fallback to the opengraph image, which is equivalent to hqdefault.

That image size has a different aspect ratio and includes black bars. But in both cases, we have the aspect ratio fixed to 16:9, so the black bars should not be visible when displaying the player.

Hereā€™s an example of one video that does not have a high res image and itā€™s using this one for the thumbnail.

Can you share some examples where this is happening?

3 Likes
3

Sure, thanks for your interest.

Hereā€™s a couple of videos that now look great in the embed, but show black bars when thumbnailed (and in preview):

og:image is:


as you rightly point out ā€¦ has black bars.

And

og:image is:


as you rightly point out ā€¦ has black bars ā€¦

NB Here is a ā€œgood caseā€:

og:image in this case is much bigger:

1280Ɨ720 71.5 KB

Iā€™m currently using my Topic List Previews Sidecar plugin to regenerate the thumbnails whilst clipping them using the plugins bespoke overrides:

ā€¦ but an automated way of doing this in core would be great as this is super annoying to have to keep doing semi-manually.

The challenge is identifying which images can be cropped?

Is it just a case of forcing 16:9 if you discover the youtube image is 4x3 or below a certain res (which means it must have black bars?).

I guess that might mean optimize image being passed a flag to tell it itā€™s dealing with youtube?

Seems strange to me that YouTube doesnā€™t standardise to 16:9 thumbnails?! Perhaps Iā€™m missing something ā€¦

Thanks for enlightening me on the size difference!

4

I think I understand what you mean now, but processing images on core does not really fit with our use case for them. We donā€™t store the thumbnails for these embeds, we fetch them directly from YouTube when we need them.

That being said, identifying which images should be cropped shouldnā€™t be that difficult. You can look at the URL for this:

https://img.youtube.com/vi/dsVAzSG6SbM/hqdefault.jpg

maxresdefault

  • Itā€™s always 16:9.
  • Itā€™s the highest resolution.
  • Not always available.

hqdefault

  • Itā€™s always 4:3.
  • If the original video is 16:9, it adds black bars.

mqdefault

  • Itā€™s always 16:9.
  • Itā€™s even lower resolution than hqdefault.

While a tad weird, they are predictable. My guess is that the 4:3 format is a legacy size they still use for the sake of compatibility.

For displaying 16:9 images, itā€™s as simple as fixing the aspect ratio. If you need other aspect ratios, I think you should be good passing a flag and compensating the scale with CSS.

Itā€™s true that the composer preview can be improved, but this could be done with a similar approach as described above.

The only edge case I can see with this approach is with vertical videos with low-res thumbnails. In that case, the black bars are not shown. :man_shrugging:

2 Likes
5

But core does create and store irs own derived thumbnails at various resolutions as part of the cooking post process?

This is where the black bars are retained.

Bingo!

But in any case thatā€™s super helpful information which I may be able to use to improve my plugin. Thanks a lot!

Thatā€™s a lot more straightforward than asking GPT-4 Vision if there are black bars or using image magick to detect them.

1 Like
6

Thanks to your insight Iā€™ve updated Topic List Previews with a much simpler solution which doesnā€™t have to be toggled as it will only crop if the image is a youtube legacy 4:3 thumbnail.

Perhaps this is general enough to be useful to core?

2 Likes