The following appears on the Podcasting 2.0 Substack: the underlying technology for Live Notifications within open podcasting is Podping.
Live streaming audio and video doesn’t have to be proprietary, or rely on huge platforms for distribution. You can live stream your podcast right now, and podcast apps can start playing these streams today using the new <podcast:liveItem> tag and the podping notification system. The details are a bit nerdy, but let’s dig in and look at how it all works.
Live streaming anything needs three components:
- Distribution of the stream information
- Notification of start and stop
- The streaming media itself
The streaming media part has never been an issue. You can choose from quite a few Icecast streaming services or even run your own. Either way you choose to go, it’s not super difficult. So, let’s set that part aside and discuss the other two parts. Those are the ones that have been difficult to provide.
Distribution of Stream Information
With podcasting, we have a perfect information distribution mechanism. We already use it every day. It’s the RSS feed. Distributing structured information is why it exists. So, we decided to extend the RSS spec to hold this data by putting a new tag in the Podcast namespace. We call this tag the liveItem tag. Here is what it looks like:
You can see that all of the basic information you need for a live streaming event is here:
- When does the stream start?
- When does it end?
- What is the current status? (pending, live or ended)
- Where is the media streaming url?
This tag lives in the <channel> of a standard podcast RSS feed right alongside the normal episode <item> tags. Since it is namespace’d it is invisible to apps and platforms that aren’t looking for it.
The overall idea of the <podcast:liveItem> tag is that it can hold any and all data that a normal episode <item> can hold. It also conforms to the same best practices like <guid> tags that should be unique if you have more than one. It is, in most all respects, just an <item> with some extra attributes.
Ok, that’s step one.
Notification of Start and Stop
Just knowing when a live stream is “supposed” to start or stop is not enough. It’s really not reliable in any way. We’re all human. We never start on time. So, we need another mechanism that will tell us when the live stream actually starts instead of just when it’s supposed to. That’s where @podping comes in.
With the new upgrade to the Podping.cloud service, podcast publishing platforms can now easily send live and liveEnd podping events to let the world know when a stream actually goes live. It’s dead simple:
This GET request distributes a live podping event to everyone watching for them, including the Podverse and Curiocaster podcast apps. Podverse, for example, will send you a push notification on your mobile device when your favorite show goes live:
Tapping the notification opens the app where you can listen to the live stream and even join the chat room for the show if there is one.
A podping event consists of three bits of info:
- The url of the podcast’s RSS feed
- The “reason” for the ping event (update, live or liveEnd)
- The “medium” of the podcast (podcast, music, video, etc.)
When a podcast app sees a podping event come through with a live reason code, it first polls the RSS feed and double-checks that the feed’s <podcast:liveItem> tag does indeed have it’s status=”live” property set. Since the RSS feed is always the source of truth, the app will only trust the feed itself as to whether the podping event was accurate. If it is, the app can know with high confidence that the stream is now broadcasting and attempt to play audio or video from the streaming url indicated in the <enclosure>.
Some podcasts have gone a step further and put a chat location attribute in their <podcast:liveItem> tag, like this:
You can see in the example above that there is a link to the IRC chat server for the show, as well as <podcast:person> tags for showing the host profiles and images and a status=”pending” to let apps show this as an upcoming live stream that will start on December 13th, 2022 at 9:00pm. There is also a <podcast:value> tag for streaming payments and a <podcast:alternateEnclosure> tag for more advanced audio stream fine tuning. This is a complex example and shows truly what all is possible with live streams using these new features.
Expanding Live to the Masses… Openly
Live streams using the <podcast:liveItem> tag is ready for podcast apps to integrate today. It has been working well for months and is primed for broader adoption. We do it on our show every week.
You can follow the PodcastsLive bot on Mastodon or Twitter to see in real time (again, the bot watches podping) when various shows go live. Or you can check out the Podverse live streams page to get a sense of how it’s growing in popularity.
Bringing live streams right into the app makes it much more accessible, and live listening audiences will grow as a result. But, this time it will be open, and not locked behind a giant tech company walled garden. Not every podcast wants to (or should) stream live. But, for those podcasts that do, their listeners will truly love this feature because those audiences are very committed to the live experience.
To start supporting live streams in your podcast app you will need to:
- Start ingesting the
<podcast:liveItem>tag - Watch Podping for pings with the “live” reason code
To start publishing live streams in your podcast feed you will need to (or encourage your hosting company to):
- Start using the
<podcast:liveItem>tag - Send a podping when your stream goes live
If you want to use the Podping.cloud service to send your podping events, please get in touch on Hive with a comment or Mastodon for an authorization token. It’s a simple, free service we are able to provide because of the generous donations that supporters have made to the Podcast Index and Podcasting 2.0 @podcastindexorg project.
