A tag for defining "banner" images in a podcast feed.

[redimongo]

UPDATE 10 JULY 2023
PODTOO SUPPORTS BANNERS.

DEMO @ https://podcasts.podtoo.com/yiGRCmme

We are adding a new feature to our podcast hosting platform called Banner. This allows podcasters to add a 16:9 banner to their podcasts, similar to the UI of Netflix.

The reason for this is because many podcast apps display only audio podcasts, making it difficult for video podcasts to stand out. By introducing banners, we aim to help promote podcasts in a more engaging way beyond just the logo.

We currently do this on our radio station website with the following tag:
UPDATE (23/09/2024) filetype has been changed to mimetype

• Aspect ratio has been coded for TV apps. However we can change that to CSS 16/9 if the community wants.

If using images

<podcast:banners>
    <banner aspect="16:9" src="https://example.com/16_9.png" mimetype="image/png">
   <banner aspect="4:1" src="https://example.com/4_1.png" mimetype="image/png">
</podcast:banners>

For video

<podcast:banners>
    <banner aspect="16:9" src="https://example.com/videiobanner.mp4" mimetype="image/mpeg" length="123456789">
   <banner aspect="9:16" src="https://example.com/9_16.mp4" mimetype="image/mpeg"  length="123456789">
   <banner aspect="4:1" src="https://example.com/4_1.mp4" mimetype="image/mpeg"  length="123456789">
</podcast:banners>

For best result recommend using mixture

<podcast:banners>
    <banner aspect="16:9" src="https://example.com/imageBanner.jpeg" mimetype="image/jpeg">
    <banner aspect="16:9" src="https://example.com/videiobanner.mp4" mimetype="image/mpeg" length="123456789">
   <banner aspect="9:16" src="https://example.com/9_16.mp4" mimetype="image/mpeg"  length="123456789">
   <banner aspect="4:1" src="https://example.com/4_1.mp4" mimetype="image/mpeg"  length="123456789">
</podcast:banners>

This feature will also allow podcast websites to add banners to their site, similar to what Buzzsprout currently offers. For example, the screenshot shows a podcast website that has a blue banner area that can be used to promote the podcast.

[brianoflondon]

This sounds like a good idea.

[redimongo]

This sounds like a good idea.

Thank you. For people wondering how this works.

Here one of the podcasts that use this banner in a website.

This is currently available in the JSON feed not the RSS feed.

https://drn1.com.au/shows/P-yETR

[keunes]

Great idea indeed. Would certainly help also make podcasts look nicer in apps. I'd certainly request support in AntennaPod for this!

[daveajones]

I changed the title here to sounds less like marketing/press release. It's a neat idea. I like it.

[redimongo]

Sorry was not trying to sound marketing/press release lol. Just wanted to show what we think is a good idea.

How do we get the idea, to be supported though? First time

[daveajones]

I'm moving this to the "Tag Proposals" category since that's really what it is. As far as getting support for the tag, you'll need to wait for feedback here. You can also link to it on social media or other places to get more eyeballs on it. I will bring it up in the board meeting Friday also.

[jamescridland]

I like this idea, but wonder if it fits in the already-existing podcast:images spec. Here that is:

<podcast:images
    srcset="https://example.com/images/ep1/pci_avatar-massive.jpg 1500w,
            https://example.com/images/ep1/pci_avatar-middle.jpg 600w,
            https://example.com/images/ep1/pci_avatar-small.jpg 300w,
            https://example.com/images/ep1/pci_avatar-tiny.jpg 150w"
/>

We have an aspect-ratio in CSS which looks like aspect-ratio:16/9 - all images in srcset need to have the same aspect ratio.

If we were to add an aspect-ratio to the podcast:images field, and make it acceptable to use it more than once, that would appear to allow us to offer banners and other sized images within the existing structure we have, and in different sizes. The change to the spec would be an optional aspect-ratio attribute (the default is 1/1 if it is not explicitly defined).

Perhaps an example is as below (the default 1/1 is shown here for completeness).

<podcast:images aspect-ratio="1/1" 
    srcset="https://example.com/images/ep1/pci_avatar-massive.jpg 1500w,
            https://example.com/images/ep1/pci_avatar-middle.jpg 600w,
            https://example.com/images/ep1/pci_avatar-small.jpg 300w,
            https://example.com/images/ep1/pci_avatar-tiny.jpg 150w"
/>
<podcast:images aspect-ratio="16/9"
    srcset="https://example.com/images/ep1/pci_banner-thumbnail.jpg 3000w,
            https://example.com/images/ep1/pci_banner-middle.jpg 1200w,
            https://example.com/images/ep1/pci_banner-small.jpg 600w,
            https://example.com/images/ep1/pci_banner-tiny.jpg 300w"
/>

We should also set expected values for the aspect-ratio. While it could be anything, we'll benefit if there are some examples that podcasters would be expected to use.

My recommendation here would be that we suggest 16/9 ("YouTube" and a typical Facebook share image), and 4/1 ("Twitter Banner"); and a strong recommendation that the 4/1 format has an "art safe zone" of the central 16/9 image and may be cropped outside that (again, much like how Twitter banners appear in real life).

Apple has specific sizes for promotional artwork that we may wish to consider here. Their "banner" is 4320 x 1080 pixels, which happily is a 4/1 aspect ratio. They do have other elements, though. Looking at Apple's elements, we might wish to consider NOT using aspect-ratio, but instead documenting specific names and purposes for elements. That said, Apple ask for PSD files, which I would suggest aren't appropriate here: but re-using the sizes/functions would be helpful.

[redimongo]

I agree with the aspect ratios. I used Netflix and Apple TV as the base to get the right aspect ratio.

As for using the podcast:image tag because banner/s support mp4 video it does not fit in with what that tag is designed for.

Also we need to tell the app clearly what an image is used for. Honestly a tag like banner can't be misleading or taken out of context.

This means that app developers will know if the podcast has banned it wants the banner to be shown in the banner placement.

The reason for still and video is think when you open Netflix it has cached the banners images and when you slide your remote it shown the still banner first and after you stop you get the video.

We achieve both of these by utilising the banner tag.

As a app developer looking to support this tag I personally would rather work on the KISS model (Keep it simple sexy).

I hope this explains it.

[keunes]

As for using the podcast:image tag because banner/s support mp4 video it does not fit in with what that tag is designed for.

Why not? The specs don't dictate what it should be used for, and an MP4 video is a 'moving image'.

Looking at Apple's elements, we might wish to consider NOT using aspect-ratio, but instead documenting specific names and purposes for elements.

I think specifying purposes would be a good idea indeed. Aspect ratio might not match exactly, but still be usable for its purpose.
Does it mean we shouldn't specify aspect-ratio though? (Maybe not in the tag, but we should in the specs, but maybe that's what you meant.)

In general, what image purposes can we come up with? I count up to 3:

• Cover image 1:1
• Banner image 16:9
• Social cover 4:1

[nathangathright]

Since the namespace already support a <podcast:images> element, maybe we should improve that tag rather than creating a whole new one. Ideally, this would allow us to handle multiple aspect ratios and resolutions and offer this tag at the show and episode levels.

That tag currently mimics the srcset HTML image attribute. Handling different aspect ratios in responsive images is called the art direction problem. To address this need, width and height attributes have been added to the HTML spec for the picture/source tags. Maybe the <podcast:images> tag should look more like that.

<podcast:images>
  <source width="1500" height="844" src="https://example.com/images/ep1/pci_landscape-massive.jpg"/>
  <source width="600" height="338" src="https://example.com/images/ep1/pci_landscape-middle.jpg"/>
  <source width="300" height="169" src="https://example.com/images/ep1/pci_landscape-small.jpg"/>
  <source width="150" height="84" src="https://example.com/images/ep1/pci_landscape-tiny.jpg"/>

  <source width="844" height="1500" src="https://example.com/images/ep1/pci_portrait-massive.jpg"/>
  <source width="338" height="600" src="https://example.com/images/ep1/pci_portrait-middle.jpg"/>
  <source width="169" height="300" src="https://example.com/images/ep1/pci_portrait-small.jpg"/>
  <source width="84" height="150" src="https://example.com/images/ep1/pci_portrait-tiny.jpg"/>

  <source width="1500" height="1500" src="https://example.com/images/ep1/pci_square-massive.jpg"/>
  <source width="600" height="600" src="https://example.com/images/ep1/pci_square-middle.jpg"/>
  <source width="300" height="300" src="https://example.com/images/ep1/pci_square-small.jpg"/>
  <source width="150" height="150" src="https://example.com/images/ep1/pci_square-tiny.jpg"/>
</podcast:images>

Clients could evaluate the available images to find the one that best fits their resolution and aspect ratio needs.

[redimongo]

Yes I get that we could do that, however it would not really incentivise the whole idea that we are going with.

Think of it more like a 30second advertisement not a trailer.

In Netflix for example you can see 4 or more sometime trailers.

As a developer who has not had a good experience watching video podcasts on Apple TV. We want to and will be supporting this <podcast:banner> going forward.

We would hope that the community here adopts it, as it will open up a world of possibilities. To promote your podcasts and also have more information in front of the end user.

Since technically nothing stops anyone from adding a tag to an xml and as long as it looks valid it still works.

It will be up to others if they support it or not.

Also

Link the video enclosure in an item with <itunes:episodeType> set to "trailer"
Link the video in an <podcast:alternateEnclosure> in a <podcast:trailer>.

These while useful would be used when a user clicks to learn more about the show.

• because sound would be on.

Something that by default browsers disable when playing video in background mode using auto play

[jamescridland]

Link the video in an podcast:alternateEnclosure in a podcast:trailer.

This seems a sensible and elegant solution.

Think of it more like a 30second advertisement not a trailer.

That is very much what the podcast:trailer is for (or, indeed, the Apple specification of the same).

[redimongo]

a lot of podcasters don't use the trailer as a trailer, and instead use it as a promo clip for the first episode. Ideally we would like to see it be updated more often.

nothing says that <podcast:banner> can't utilise the trailer but still be defined in side the banner element.

[theDanielJLewis]

Sidenote for clarification: a "trailer" can be used in three different ways:

1. Attach an episode number and it becomes a trailer for that episode number (season optional).
2. Attach a season and no episode number and it becomes a trailer for that whole season.
3. Do not attach a season or episode number and it becomes a trailer for the whole show.

[redimongo]

Sidenote for clarification: a "trailer" can be used in three different ways:

1. Attach an episode number and it becomes a trailer for that episode number (season optional).

2. Attach a season and no episode number and it becomes a trailer for that whole season.

3. Do not attach a season or episode number and it becomes a trailer for the whole show.

The issue is podcasters are not choosing the correct option. It's to complicated sometimes.

And still does not solve the issue of allowing more than one trailer.

[theDanielJLewis]

I really like this idea! I only think it should be something adding to <podcast:images> with an attribute that marks it as a banner or simply indicates the aspect ratio.

Then, Podcasting 2.0 apps could easily look at a single tag and have appropriate fallbacks if the desired aspect ratio isn't there. (And <podcast:images> should be assumed to be 1:1 unless otherwise indicated.)

[redimongo]

It's just a name; we can put any file in there.

podcast:assets might enable a wealth of different files if we wanted to reference them - and not limit them to images or videos.

No it's not just a name.

Highly recommend you watch this

https://youtu.be/baY3SaIhfl0

This is why developers dislike people who think everything can go in there.

We code things to go in there place. Not to be interpreted however one likes to take it.

[jamescridland]

Mate... the specification is what matters.

Pull your head in, and try and work with people here rather than just arrogantly disagreeing with every single comment that's been posted. We all want the best for this industry.

[redimongo]

Mate... the specification is what matters.

Pull your head in, and try and work with people here rather than just arrogantly disagreeing with every single comment that's been posted. We all want the best for this industry.

It's not about pulling one's head in, if people want honest conversations, feedback and constructive progression.

We are entitled to have our views. It's not about disagreeing with people.

I've already said the :image specification is for still images. We are talking about a tag that is designed for both images and video that is specifically designed for banners to be used on podcast players.

What I am shocked by is while everyone says great idea. Nearly everyone is saying use the image tag which is not designed for this and according to the :image documentation is not meant to be used in this way.

If we want specifications then we need to follow the ones that are already approved.

Unless the podcast index authors decide to change it then, they are to be used as they are written.

We can't have a community keep changing every tag whenever some new ideas comes along.

It's not good for the future if every 6 months tags are replaced/enhanced to suite a new need.

And to say someone has the heads up their you know what. Because they believe in the additional tag to be added even when others say oh but you can do this and that.

Yes you could do this or that. But we want developers to want to showcase your banners not just stick to the logo and trailer that you might of published.

At the moment there is no reason for a podcast player app to showcase your trailer when most of the podcasters don't use trailers at least not in video formate.

This banner at least sets a starting standard for any new podcast that they need to at least put a still 16:9 or a video 16:9 banner.

It's says to developers look I now can showcase podcasters in a new way. A better way. It's put the control back into podcasters hands on how they want their podcast showcased.

And I think after all that's what we all want.

Be open to accepting new tags don't try and change the ones already approved.

[jamescridland]

Unless the podcast index authors decide to change it

WE are the authors of the podcast namespace. That's us. You, me, everyone. It's up to us to change that tag to add new formats and sizes into it.

Nearly everyone is saying use the image tag

There's probably a reason for that.

[redimongo]

I wanted to bring an important topic to the table that I believe has been overlooked in our discussions regarding podcast tags: the need for a new tag called podcast:banner. This tag would revolutionize the way we promote our podcasts and engage with our audience. Allow me to share why I think it's crucial to include podcast:banner in our podcasting standards.

1. Clear Differentiation: While we have tags like podcast:image and <:trailer> that serve their purposes well, there is a significant gap when it comes to advertising banners or promotional artwork. podcast:banner would address this issue by providing a dedicated tag for podcast creators to showcase visually captivating promotional content.
2. Advertisements and Promotion: Imagine having the ability to create compelling banners or artwork that promote live events, special episodes, sponsorships, or other engaging content. By incorporating podcast:banner, we open up exciting new avenues for podcast creators to market their shows effectively.
3. Podcast Index Standard: Let's not forget about the Podcast Index Namespace 1.0 and its influence on our podcasting ecosystem. By introducing podcast:banner, we remain aligned with the established standard while expanding the range of media assets available to creators.
4. Enhanced Marketing Opportunities: Including banners or promotional artwork within podcasts provides a visually captivating way to catch listeners' attention and effectively communicate important information. This translates to improved marketing opportunities for both podcast creators and advertisers, leading to higher engagement and increased listener base.
5. Improved User Experience: The integration of podcast:banner enriches the overall podcasting experience for listeners. By presenting visually appealing content alongside audio, we create a more immersive and enjoyable experience that captivates and retains our audience.
6. Flexibility and Creativity: With podcast:banner, creators can explore their creative side and experiment with different visual formats to promote their content. It empowers us to engage with our audience in innovative ways, leveraging branding and artistic expression to make a lasting impact.

I truly believe that introducing the podcast:banner tag will revolutionize the way we market our podcasts, enhance user experience, and unlock new creative possibilities for all of us. Let's come together and embrace this change, shaping the future of podcasting for the better.

[redimongo]

Just wanted to share an update, we have started to use banners in our RSS feed. Just wanted to show what it could look like when someone views your RSS feed inside chrome browser.

Clearly there still some banner alignment with text still needing to work.

But in this RSS feed we have given it a height of 520px (yes an odd height) we are using a 1920x1080 image and re-positioning it, clearly we would want to support other formats and from our chat with our clients, they love the banner idea and how we are integrating it. The feedback from our creators are:

• Don't make us upload multiple formates in different sizes (your system should resize it)
• If possible auto generate the banner from the text and a background image.
• Support video banners please
• Support live streaming banners.

So we are going, make podcast:banner more flexible, I open to suggestions.

Also just for example this is how podnews rss feed looks, I do need to thank James as we used his stylesheet as the base, and started editing it to come up with the above.

[MerryOscar]

What's the latest on this @jamescridland?

[jamescridland]

OK, @MerryOscar - well, the latest is...

We have a podcast:images tag, but nobody is using it, because it only works with square images, so doesn't really offer much than a resizing script couldn't offer. I've suggested elsewhere here that we should remove the podcast:images tag, because it was a rushed spec that doesn't really answer any of our pain points other than resizing, but this has caused much consternation and gnashing of teeth.

However, @redimongo is right to want sizes that aren't just square - and he's not the only one.

Since all the above, YouTube has appeared. They ingest your RSS feed, and you can either leave it up to them to use the square artwork for each episode, or you can use media:thumbnail, which is an existing tag in the Yahoo media-rss namespace. If you use a tag that is exactly 1280x720, then this HD-tv size thumbnail will be pulled into YouTube, instead of your square episode artwork. And, since I already produced something pretty well the same size, I've been running this for some time. It looks like this:

<media:thumbnail url="https://i.podnews.network/r/v/1280/podnews240419.jpeg" width="1280" height="720" />

This allows anyone to define "banner" images in a podcast feed. It's an existing specification, which YouTube is also using. It's supported by really a quite surprising number of podcast hosting companies already under the hood. The specification is here - caution that it's referred to as "media:thumbnails" in the spec title, because you can have more than one thumbnail, but the tag is media:thumbnail. It also includes timing, which we should ignore.

I'd like to suggest that this is the right tool to use (don't forget to include the namespace declaration of xmlns:media="http://search.yahoo.com/mrss/" in the top of your RSS feed).

I'd also like to suggest that podcast:images is deprecated; since if you want to make a, say, 100x100 icon image for your podcast, you can do this in a media:thumbnail.

@redimongo - does this answer the use-case that you had (excepting the use of video, which you'd use a trailer alternateEnclosure for?)

[redimongo]

@jamescridland yes, we are currently integrating media:thumbnail to replace podcast:banner - which is what we use atm.

[redimongo]

So question media:thumbnail based on the documentation is for images.

I understand that there maybe another way to do what I want to do, but thought I would ask here first.

One of our clients wants to have on their website and app the ability for a netflix style (note easiest way to explain this) UI.

When a user hovers over the podcast or TV show the still thumbnail aka banner shows. Now the client wants away to show a 15 second podcast ad about the podcast which is separate from the trailer item.

I am wondering what the views are of either integrating this feature into banner as the player will play it in the same area as the banner.

Or does anyone have a better more sound solution.

[picard102]

Why wouldn't you add a second trailer that's 15 seconds long to the feed and have the app grab it? Or better yet, have a single trailer that works for both.

[redimongo]

Why wouldn't you add a second trailer that's 15 seconds long to the feed and have the app grab it? Or better yet, have a single trailer that works for both.

Because the client doesn't want that 15 second ad in the item list, and by us putting it there every podcast player would see that item in the item tag. I guess in away they only want podcasting 2.0 apps to see it (one way to put this).

Also it's not how services like Netflix does it. The video that you see is sometimes different to the trailers and in some cases, there is no trailer for the TV show/movie you're about to watch. So when you hit the season button you don't see trailers.

Yes I get what you are saying the app could just exclude trailers that are in item tag.

[picard102]

I think catering to this specific UX example is a niche issue that is best suited to having a developer implement with the existing tags, rather than a whole new tag.

[jamescridland]

alternateEnclosure is your friend. type="video-trailer" perhaps.

But, I suspect this is a very niche thing.

[redimongo]

alternateEnclosure is your friend. type="video-trailer" perhaps.

But, I suspect this is a very niche thing.

Thank you James, that would work and be easier.

Can we do it on the channel level as this way we don't need to scan each item? Or would you suggest put it only in the first item in the rss feed?

[thebells1111]

One thing I'd like to see, and I'm not sure media:thumbnail solves this, is a way to tighten up or define the ratios. As it stands, using this tag is the wild west, and the heights, widths, and resultant ratios can be all over the place. The becomes a nightmare for an app developer trying to create a standard banner across millions of feeds. At least with the image tag, you knew it was going to be a square. It would be nice to have some sort of limitation and consensus on a handful of acceptable ratios, something like this. The limiting it to a few standard ratios is my only argument for creating a new tag instead of adapting media:thumbnail

[thebells1111]

I've always had issues with the podcast:image tag because it's kind of clunky. I get the idea is to save on bandwidth, because we can have multiple image sizes and let the app choose the most appropriate one, but it always felt kind of messy. Cleaning it up and repurposing it could make sense. I'm also in favor of a podcast:banner tag because I like separation of concerns, and a new tag with a very specific purpose is clean. Another argument I have against using media:thumbnail, is we don't control that spec. With creating another tag or adding to an existing tag in the podcast namespace, we're able to define the limitations on the acceptable ratios in the specs.

[redimongo]

@thebells1111 yes in Banner you can do aspect ratio like this

<podcast:banners>
    <banner aspect="16:9" src="https://example.com/16_9.png" filetype="image/png">
   <banner aspect="4:1" src="https://example.com/4_1.png" filetype="image/png">
</podcast:banners>

[daveajones]

I’m in favor of @nathangathright proposal of enhancing the images tag to handle this use case. I hear you @thebells1111, but we already have podcast:images in use by some apps so piggybacking on that would help the adoption curve. It would give hosts reason to support it finally and we win on both fronts.

I think Nathan’s changes make it feel less clunky.

[picard102]

As a designer, I think without giving some artwork guidelines, these may have limited utility. Do these images include text and logos or are they just background graphics. If they do contain logos what is the safe zone?

Maybe Apple's promotional artwork is a starting point? https://podcasters.apple.com/support/866-promotional-artwork

[thebells1111]

@daveajones For sure, I'm totally cool with @nathangathright's proposal, and I'm already working on implementing it for banners since it won't break anything adding some extra attributes. I figure that way people can play around with it before it's finalized, and we can demonstrate it's utility. Really, my only ask is that we define some acceptable ratios or width/heights in the spec, and limit support to just those ratios, or the app devs will have a tough time with supporting every possible width and height. I totally agree with @picard102 that having some standard practices and guidelines should be part of the value we give to the podcasters and app developers.