liveItem - ease of implementation changes

[jamescridland]

I'd like to suggest a change to the liveItem tag.

The problem

First, podcast apps cannot be expected to support every mimetype.

As one example, type="audio/opus" is certainly valid, but because iOS may lack support for Opus at an OS level, it may be non-trivial to support a live Opus stream. For a podcast app to support every known mimetype now and in the future seems daunting to any developer. This also offers a broken experience to listeners, since different podcast apps may have different support for containers, codecs or transports. It's unrealistic to expect a listener to plan in advance aided by a complex matrix of support.

This proposal is not currently fit for purpose, since it is beautifully open but gives no guidelines on what is, and isn't, supported. I am very keen that the specification is defined well enough to aid implementation by podcast app developers.

Second, podcast creators may wish to use a closed protocol.

As Mitch Downey ably puts it:

This seems like the first time where we have a spec where our decision making is not based solely on what podcasters want to do, but rather what we want podcasters to do.

Our overall purpose should be for the creator: not to advance the use of a particular technology, or group of technologies, over others.

If a podcaster wishes to stream live on YouTube, or Facebook Live, then these platforms aren't open, and there may not be a simple API for this stream to appear within a podcast app. Creators may get benefits from that platform, like community features. This is the choice of the creator. Not of our specification.

We should be able to offer a better experience using open, native streaming within the player; especially when combined with other elements of the podcast namespace. This is where we win: not by mandating open streams, but by making use of an open streaming technology better than the alternative.

Accordingly, if I'm a podcaster, I should be able to use a YouTube Live link or a proprietary embedded player if I wish. Creators are in charge. Not us.

The suggestion

I'd like to suggest that a minimum podcast:liveItem looks like this:

<podcast:liveItem status="live" start="2021-09-26T07:30:00.000-0600" end="2021-09-26T09:30:00.000-0600">
    <title>Podcasting 2.0 Live Show</title>
    <link>https://example.com/podcast/live</link>
    <enclosure url="https://example.com/pc20/livestream" type="audio/mpeg" length="312" />
</podcast:liveItem>

• A <link> is mandatory. It MUST link to an HTML page which allows the listener to consume the content. This HTML page MUST be viewable and fully functional within a webView control in both Android and iOS.

• An <enclosure> is highly recommended, but optional.

If the enclosure tag IS present, but the mimetype (including any existing <alternateEnclosure>) is not one that is supported by the podcast app, then a podcast app MUST treat the enclosure tag as invalid.

If there is no valid enclosure tag present, a podcast app MUST open the <link> address and display this to the user. It MAY display this as part of a webView control within an app, or it MAY spawn a browser window.

The best experience within a podcast app for listeners and podcasters alike will be one using a well-supported, open streaming technology, described in an <enclosure> or <alternateEnclosure>.

However, if a podcast app supports liveItem, every liveItem tag MUST be supported: whether natively, via a webView control, or by linking out to the OS's default browser.

[PofMagicfingers]

I understand what you mean and I'm on your side on this. But why not just use the same tag with text/html as mime type? And strongly advise to prioritize html webview.

That's what YouTube did some time ago with open graph video property IIRC.

[jamescridland]

why not just use the same tag with text/html as mime type

I'm ambivalent about this. A <link> tag is just that, after all. But it does mean that a podcaster can't offer a link to both YouTube and Facebook, which they could do in an <enclosure> or <alternateEnclosure>, perhaps. Thoughts from others?

strongly advise to prioritize html webview

Not sure I agree with that. If a podcaster makes a video/mp4 stream available alongside an HTML webview, then I think it's up to the podcast app how it deals with that. A podcast app might produce a lovely embedded view of the MP4; or offer a listener the choice of both options. I'd probably suspect that an embedded view of an open stream is better than an HTML page.

[cottongin]

Y'all are making this too complicated; and trying to enforce HOW people will use things never works.

The live tag, in my mind, serves one purpose: to tell me (the podcast consumer) when a show is live or recording. That's it. If I open my favorite podcast app and see a podcast I follow is at the top of the list with a little "LIVE NOW" badge or something, now it's up to ME to figure out how to consume that.

Will some apps develop ways to bring those URLs/streams in and play them for me? Yes.

Is that within the scope of this project? I'm not so sure.

[PofMagicfingers]

I guess the app should implement the live as they want, either an integrated player or they just open the link with the default system app. Or both, player when supported, opened by system when not.

Le ven. 14 janv. 2022, 15:13, cottongin @.***> a écrit :

Y'all are making this too complicated; and trying to enforce HOW people will use things never works.

The live tag, in my mind, serves one purpose: to tell me (the podcast consumer) when a show is live or recording. That's it. If I open my favorite podcast app and see a podcast I follow is at the top of the list with a little "LIVE NOW" badge or something, now it's up to ME to figure out how to consume that.

Will some apps develop ways to bring those URLs/streams in a play them for me? Yes.

Is that within the scope of this project? I'm not so sure.

— Reply to this email directly, view it on GitHub https://github.com/Podcastindex-org/podcast-namespace/issues/325#issuecomment-1013151908, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADST7PQUKKYCWQASKKGXYTUWAVSDANCNFSM5L6FLXVA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you commented.Message ID: @.***>

[daveajones]

As currently written, <enclosure> and <alternateEnclosure> are already optional. There is no language in it that states they are required.

I don't think <link> is semantically appropriate for the job of specifying that the actual content of an episode resides on a different place (website or app) that will have to be launched by the app. I think we need a new tag for this sort of thing - something like <contentLink href="<url to the actual content">YouTube</contentLink> or some such, so that multiple links can be supported sanely.

[SpencerPearson]

The part of the pushback I'm struggling to wrap my mind around is what could be different about <liveItem> that isn't already true about <item>

Can a youtuber currently place an episode of their "podcast" in an <item> <enclosure> and host it on an RSS? Don't we debate whether or not this even constitutes a "podcast" in the first place? Don't we fall on the side of it not being a podcast?

I personally have a laughably small knowledge of coding and development compared to all the other participants here, so I know I am not qualified to wrestle or win debates in here. I took issue with the naysaying over <liveItem> on the Masto because I have been genuinely excited about implementing it in my own clumsy, junior way. This summer the live tag was gonna be coming up after Boostagrams, but then cross-app comments were advocated for excitedly and given priority. At the time I was disappointed as I didn't see excitement among my own audience or the podcasters in my circle for cross-app comments as most of us are reading Boostagrams and driving engagement toward IRC. But our circles are small and we are not the norm, so I was not about to put a bunch of negativity out for the cross-app comment feature, as I consider myself a team player and I want to support the project as a whole. I knew that if there were other podcasters who wanted the cross-app comments, it couldn't reasonably be considered a waste of time.

Now that Live is finally rolling out, I am excited for adoption and I am also still in the planning phases of developing something that can use live in an experience that makes sense, as well as coming up with something for the music side of things. To see core players call a tag a "waste of time" and try to wrestle it into something that isn't really the intention for it disappointed me, that's why I pushed back.

If content creators will think of the Live tag as a waste of time, they may still stick to their platform of choice without issue. As Dave points out, they can put a youtube live link in the <liveItem>, link apps to that youtube live experience, tell apps when their show is scheduled, and use Podping to signal when their live show truly begins. This tag has very exciting implications for Podping in my opinion because it's the most necessary use case for the feature thus far in the namespace. When you go live, you need to let people know that instant, which only Podping can pull off right now.

Now I may be out of line on this entire thing, I'm willing to admit that. But this tag I have had a personal passion for ever since first hearing it discussed on PC20. I am a literal nobody, I have no weight to throw around, I have no code to show for the project as of yet, and there's no objective reason why anyone should listen to me over literally anyone else on this github or on the socials. But I can't just keep my mouth shut when this awesome tag is finalized and core players who do have weight to throw around try to fix something that doesn't appear to be broken.

I mean this all in love and respect, and I get that I come off like an idiot. I am an idiot. An idiot who loves Podcasting 2.0.

[czemike]

* **A `<link>` is mandatory.** It MUST link to an HTML page which allows the listener to consume the content. This HTML page MUST be viewable and fully functional within a webView control in both Android and iOS.

I don't like the idea of a spec taking into account specific platform implementations because the platforms change frequently whereas the spec should stand still. I think @SpencerPearson's asks a great question when asking what the specific difference(s) of a <liveItem> tag are versus the <item> tag.

[daveajones]

This would be the new tag:

<podcast:contentLink
 href="[url to the content on an external platform(string)]"
>
[free form string(string)]
</podcast:contentLink>

Channel, Item, LiveItem, Social, etc.

(optional | multiple)

This element can be used as a child element in any tag where content delivery is normally expected to occur. It's intended to let the application know that the content being referenced by the parent element can be found by opening the url denoted by the href attribute. It is expected that this link will be a link to content that can be opened by default on all platforms. Most times this should be a link to an HTML web page.

---

@jamescridland I think we can tweak your idea so that what is required is:

• One of either <podcast:contentLink>, <enclosure> or <podcast:alternateEnclosure>.

That way, apps can know for sure which link to expect the content at, without hosting companies having to make their CMS change tag meaning depending on parent context. It also doesn't attempt to place requirements on what <link> should mean, which feels out of scope.

The <podcast:contentLink> is a simplistic pointer tag that leaves no ambiguity about what it's pointing to. That way, the <link> can remain for it's normal purpose as a link to the episode on the podcaster's site.

Any, or all of these tags can be present in a live item.

Example:

<podcast:liveItem status="live" start="2021-09-26T07:30:00.000-0600" end="2021-09-26T09:30:00.000-0600">
    <title>Podcasting 2.0 Live Show</title>
    <link>https://example.com/episodes/69</link>
    <podcast:contentLink href="https://youtube.com/pc20/blahblah">YouTube</podcast:contentLink>
    <podcast:contentLink href="https://twitch.com/pc20/blahblah">Twitch</podcast:contentLink>
    <podcast:contentLink href="https://facebook.com/pc20/blahblah">Facebook</podcast:contentLink>
    <enclosure url="https://example.com/pc20/livestream" type="audio/mpeg" length="312" />
</podcast:liveItem>

Thoughts?

[agates]

@daveajones we came to the same conclusion separately. This covers external links that aren't otherwise fulfilled by the funding or social tags. Liveness of any tag is indicated by being inside a <podcast:liveItem> only, as has been intended from the start.

However, I don't think anyone should expect external live content to be useful from a podping perspective. All these external platforms already have their own notification systems on top of announcement streams like Twitter. It would end up just being more noise.

That said, I think <podcast:contentLink> solves this and other, separate, proposals where people have asked for generic outbound links quite nicely.

I would also ask people, as @daveajones graciously mentioned on the latest episode (69) of Podcasting 2.0, to remember that <podcast:liveItem> was developed with existing people and implementations in mind -- peertube for me/video and icecast for the no agenda stream/audio in particular.

@SpencerPearson people like you were 100% a contributing factor.

[jamescridland]

I like the <podcast:contentLink> tag idea. That's a good suggestion.

@daveajones said:

I think we can tweak your idea so that what is required is: One of either , or .

I'd like to, again, push back on "one of these", because it doesn't solve the first issue in my original post.

Podcast apps cannot be expected to deal with every mimetype - so only offering an enclosure without any guidance is not a realistic solution here for developers. What am I supposed to code for here? What am I supposed to support? An icecast stream? An HLS video stream in H265? Opus audio live? I've not got the faintest idea, and the specification as it stands does not help here - it isn't complete and won't help me develop for this feature.

Either we need:

a) a requirement that there MUST be a <podcast:contentLink> that links to a web-page where the content can be consumed, even if there is an optional but recommended <enclosure>

or

b) a clear and minimal specification of exactly what type of streams we, as developers, are supposed to support in our apps; and a requirement that podcasters offer at least one of these type of streams in their <enclosure>

To me, a) is much, much simpler, and much less prone to argument. It's very unlikely that any podcaster would be livestreaming in a format that doesn't have (or couldn't have) an accompanying HTML webview. It allows creators to use anything that displays in a webview, and doesn't require that they entirely retool their live streams just to reach a sub-1% share of all podcast apps. But yes, it would be better if they streamed direct into the podcast app.

---

@SpencerPearson I don't much want to go off-topic here, but cross-app comments are a great idea. The issue with the cross-app comments specification is exactly what I'm attempting to stop with this specification.

Just take a look at this car-crash:

The socialInteract specification tells developers that they have to support a fantastically wide list of platforms, and that list is not even complete with ellipsis at the bottom suggesting more may be added at any point. It's impossible for a developer like me to support all these platforms. What should I aim for? ActivityPub because Adam likes it? Twitter, because it has many more users? Facebook because there's a supported API? I've no idea.

As a direct result of this woolly specification, cross-app comments are not being used because this is not a specification you can show even the most competent coder and say "get on with it". Hence my suggestion that it's a waste of time - it's a specification that's directly led to developers putting their hands up and going "I've not got time for this". I'm going nowhere near this specification, because I simply do not know where to start supporting all these different services.

I'd like liveItem to work, just as I'd like cross-app comments to work: because it's very clearly going to significantly enhance the experience of podcast listeners, and help podcast creators. But I don't want an unworkable specification that includes every single make of kitchen sink available. In the liveItem specification right now, not only do we want every single type of kitchen sink, we haven't even helped developers by giving any hints about the shape of the sink.

---

@czemike says:

I don't like the idea of a spec taking into account specific platform implementations

Me neither. My attempt there, probably hamfisted, was to try and suggest that any web page that we link to ought to work and display properly on a listener's device. Do you think there's a clearer way of saying that?

---

@agates says:

I don't think anyone should expect external live content to be useful from a podping perspective. All these external platforms already have their own notification systems

I think podping is extremely useful here, in fact. I listen to plenty of podcasts without following them on YouTube or Facebook. The use-case here is that my podcast app notifies me that BlahBlahPodcast is broadcasting live. I open the app, and I can enjoy BlahBlahPodcast broadcasting live (either direct in the app or on a third-party website). I have the relationship with a podcaster in a podcast app; and this means no lock-in for the podcaster within any third-party platform (since they'll still reach their users through podcast apps, even if they change their third-party platform). I don't see a downside here?

[cottongin]

@jamescridland

Podcast apps cannot be expected to deal with every mimetype - so only offering an enclosure without any guidance is not a realistic solution here for developers. What am I supposed to code for here? What am I supposed to support? An icecast stream? An HLS video stream in H265? Opus audio live? I've not got the faintest idea, and the specification as it stands does not help here - it isn't complete and won't help me develop for this feature.

Is this not true today of the current ecosystem too? I can put really any kind of media / document I want to into an RSS feed. As a developer I would approach this as just targeting whatever stream/mime/media I want my app to support and ignore/discard the rest. If someone wants to write an app that supports the mimetypes my app is ignoring, let them. Isn't this the point? Restricting it down at a spec/platform level just doesn't make sense to me.

[czemike]

@jamescridland says:

[I don't like the idea of a spec taking into account specific platform implementations] either. My attempt there, probably hamfisted, was to try and suggest that any web page that we link to ought to work and display properly on a listener's device. Do you think there's a clearer way of saying that?

I think it's the on the content creator/distributor to output formats that are supported. What's the point of distributing content is a GPL3 format not supported by iOS or Apple? If you are Richard Stallman and only targeting a niche who can handle that then fine but it's an odd podcast you've created at this point.

Alternatively, this is a chance for PC20 apps to support newer and more efficient CODECs than Android and iOS natively support which could be a competitive advantage (and the app either defaults to the newer codec or you can set it to prefer it). On the downside: that might require software decoding and suck more battery than formats which are decoded in hardware. Just thinking out loud...

[SpencerPearson]

Ok, so again I ask: how is a liveItem more difficult to code for than an item?

You can stick a PDF in an item enclosure if you want! Do all apps serve a PDF if it's put in an enclosure? It's up to the app to figure that out. The question "how do I develop for this" shouldn't be that herculean of a task. The live tag as I have always understood it gives apps access to a raw live audio or video asset. Simple as. You're trying to mirror this "gotta catch em all" quest for cross-app comments into the live tag when in reality they have nothing to do with each other. With cross-app comments (as Dave admitted, the most complicated tag that will ever exist), you're trying to capture all that engagement into one source to have a big number in a centralized data set to better track it, which makes sense for the portion of the industry that is engagement-driven (For the record @jamescridland I have never said anything about the comments being a bad idea or not worthwhile. I have in fact stated the complete opposite. I also said they don't excite me personally and I won't be adopting them on my own show, but because of that when comments were being worked on and developed I stayed out of the way and waited for live, which is the tag I'm excited about and most wish to use). For live, it's only gotta come down to the broadcaster saying "how do I find where the raw output of my show is hosted online? I will put it into my live tag."

If a digital broadcaster is unable to produce a link to a raw audio output that is universally accessible to different apps, they don't own their own broadcast stream. This is not desirable and any professional should realize this. This is the exact reason why we need podcasting 2.0.

If digital broadcasters wish to produce their content for YouTube or Facebook or some other entity and relinquish control of distribution, they still have a workable solution with the proposed <podcast:contentLink> tag, but ultimately this is just not the smart or professional way to produce content long-term. There are insanely simple ways to broadcast your raw audio or video content in a distributable manner like an icecast or SHOUTcast server or an application like OBS. If somebody like me can figure that part out then industry titans have no excuse. Similarly for development, when you are given a raw audio resource such as http://listen.noagendastream.com/noagenda you could put that in any sort of audio player, you could develop an app that auto-plays subscribed shows at a certain time, you could have a live push notification that takes you there...you can plug that link in as the source for just about anything you can code audio to do.

The question of "why can't I give these apps access to a YouTube live stream" is a question for YouTube, not for the namespace...and I'm betting there's a way to do it anyway, you'd just need to isolate where the audio stream is coming from, or at the very least with little effort you could mirror your stream to a point you control. Broadcasting a live show with no control over the raw output signal is irresponsible anyway.

It was actually a huge relief to hear the Podcasting 2.0 episode yesterday as I felt like I am on the same page with Adam and Dave when it comes to the live tag's purpose and correct usage. I appreciate @agates kind words as well, I struggle mightily with imposter syndrome in this space. I'm here to learn and contribute, I've been integrating the project via my show from the earliest days when the only way we could stream sats was via Sphinx chat. Now look at how much has since come online!

The tools to consume the live resources largely have yet to be built, but they will be developed and I'll do what I can to help it come about. At the very least I'm including live elements on the redesign of our web page which will signal when the show starts and generate some sort of email or other notification that goes out to subscribers. There is huge potential for how this tag could be implemented though, in my overactive imagination.

[jamescridland]

how is a liveItem more difficult to code for than an item

For a podcast app, it's expected that you'll be given MP3s or AAC files. That's the ad-hoc standard, and while you can put other things in there, they'll not be supported.

The specification, as currently written, doesn't suggest any live stream standard. As a developer, it's a useless specification, because it tells me nothing about what is supposed to be supported by my app.

The live tag as I have always understood it gives apps access to a raw live audio or video asset. Simple as. You're trying to mirror this "gotta catch em all" quest for cross-app comments into the live tag when in reality they have nothing to do with each other.

I agree that the live tag gives apps access to a raw live audio or video asset. But currently, it's worse than a "gotta catch them all" with a list of 400 Pokemon. It's a "gotta catch them all but we're not gonna tell you what any of them are".

I'm simply (?) asking for either/both of:

a) a minimal list of supported codec/containers for a developer b) a mandatory fallback HTML link, to ensure that a listener can always access the live stream, irrespective of what the developer has coded for.

Many developers might simply drop all live links to the browser to deal with. Others might support some streams natively, but drop others out to the browser. But as a creator, this would mean we know that every app that supports the liveItem will give listeners access to my live stream. We simply do not have that certainty now.

If a digital broadcaster is unable to produce a link to a raw audio output that is universally accessible to different apps, they don't own their own broadcast stream. This is not desirable and any professional should realize this.

Absolutely. I'm not disagreeing. It will always be a better experience if the stream is dealt-with natively within the app. As a creator, I'd like that. I may not always have the choice of how I create a stream, but of course we should be promoting the use of raw streams in this way.

However, there are many podcasters who are currently producing live output within YouTube or Facebook, or other proprietary services. We have the choice of saying:

a) FUCK YOU! USE OPEN STANDARDS FOR EVERYTHING OR GET THE FUCK OUT! b) Yeah, that's not ideal, but we'll support them in a webview so you can start seeing how useful this is to your listeners, show you the benefit of providing an open stream in future, and then you'll evangelise about podcasting 2.0 and new podcast apps.

I'm totally perplexed as to why we'd ever want to choose a).

I'm also totally perplexed as to why there is nothing in the specifications about which open standards we wish to support.

I want to make a useful, supportable tag for the future of podcasting. I love the idea of a liveItem tag. I just want it to work for developers and for content creators. It currently doesn't work for either.

[daveajones]

@jamescridland Is it your opinion that <enclosure> be removed as an option for <podcast:liveItem> altogether? Because, if that is what you want, I'm completely fine with it. <podcast:alternateEnclosure> is better in every way.

[jamescridland]

@daveajones I have no opinion on tags.

I'm asking for:

a) a minimal list of supported codec/containers for a developer (we currently don't have any guidance)

b) a mandatory fallback HTML link, to ensure that a listener can always access the live stream, irrespective of what the developer has coded for (and I cannot see why this is being so vehemently fought against).

(This is really perplexing. Am I really this bad a communicator?)

[daveajones]

You're not a bad communicator. I thought we had already settled the issue of including <podcast:contentLink>, thus satisfying b). I'm not fighting against it. I created the tag for it. :-)

[jamescridland]

Have you made it mandatory?

[theDanielJLewis]

I fully agree with @jamescridland's points on this. We should be advocating for freedom, ease for the consumer, openness, and avoiding proprietary silos.

it's up to ME to figure out how to consume that

@cottongin, while your desire to figure something out on your own is respectable, I'd rather not make my listeners have to figure out anything.

(I'm reading all the comments and responding to each in order.)

I don't think <link> is semantically appropriate for the job of specifying that the actual content of an episode resides on a different place (website or app) that will have to be launched by the app. I think we need a new tag for this sort of thing - something like <contentLink href="<url to the actual content">YouTube</contentLink> or some such, so that multiple links can be supported sanely. <link> could be used for this, but then we would risk having the redundancy of both <link> and a <podcast:contentLink> pointing to the same place.

@daveajones, I think <link> can serve this purpose, as that's how it normally works in RSS readers and podcast apps: the link points to the page where the media can be consumed. However, I really like the versatility of being able to specify platforms or links. That would support restreaming, allowing one to list any combination of YouTube, Facebook, Twitch, private page, public live page, Clubhouse, etc. Hosting providers and feed-generators could offer multiple standard choices (like those I previously listed), as well as letting the podcaster specify their own. But we might need a very short character limit, like 16.

Now I may be out of line on this entire thing, I'm willing to admit that. But this tag I have had a personal passion for ever since first hearing it discussed on PC20. I am a literal nobody, I have no weight to throw around, I have no code to show for the project as of yet, and there's no objective reason why anyone should listen to me over literally anyone else on this github or on the socials. But I can't just keep my mouth shut when this awesome tag is finalized and core players who do have weight to throw around try to fix something that doesn't appear to be broken.

I mean this all in love and respect, and I get that I come off like an idiot. I am an idiot. An idiot who loves Podcasting 2.0.

@SpencerPearson, your opinion is important! Please don't undervalue yourself!

@daveajones, I think any kind of <podcast:contentLink> (or maybe simply <podcast:link>) should also have an optional attribute to define the default, unless we say in the spec that the first link will always be assumed to be the default/priority. For example, although I might live-stream to Facebook, my live page with a YouTube embed, and Clubhouse, I'd really rather everyone go to my own live page because it has the best experience.

<link> can remain for it's normal purpose as a link to the episode on the podcaster's site.

@daveajones, for clarification: in most live-streaming cases, the episode doesn't its own page, yet. There might be unique URL for that live-stream (like from YouTube or Facebook), or it might simply point to a standard live page with the embedded media.

However, I don't think anyone should expect external live content to be useful from a podping perspective. All these external platforms already have their own notification systems on top of announcement streams like Twitter. It would end up just being more noise.

@agates, I'm not sure it we be only more noise. I listen to podcasts I don't follow on Twitter or anywhere else. But if my podcast app notified me that they were doing something like (if I "rang the bell" for notifications from that podcast in my app), I would be far more likely to notice and to attend because it would be an actively pushed notification, instead of the more passive notifications within other apps. And it looks like @jamescridland and I were thinking the same thing.

It's very unlikely that any podcaster would be livestreaming in a format that doesn't have (or couldn't have) an accompanying HTML webview.

@jamescridland, we shouldn't forget app links, either. I can't say Clubhouse anymore now that they do offer a web experience, but anything like Clubhouse might be there. I think Castbox's live-stream solution also works only inside the app and not a browser, but such an experience is still shared with a normal URL, and usually not even an app deep link. So while webview is good, we need to remember that some webviews/URLs might need to trigger an app, just as if the link was tapped from a normal browser. I don't think you meant to exclude this, but I wanted to ensure we didn't forget this use case.

Is this not true today of the current ecosystem too? I can put really any kind of media / document I want to into an RSS feed. As a developer I would approach this as just targeting whatever stream/mime/media I want my app to support and ignore/discard the rest. If someone wants to write an app that supports the mimetypes my app is ignoring, let them. Isn't this the point? Restricting it down at a spec/platform level just doesn't make sense to me.

@cottongin, I think (but I could be wrong) enclosures are different because operating systems can natively play most media file formats. In other words, Overcast can simply say "play this MP3" instead of writing an MP3 encoder. But I think the only live-streaming format supported by all modern devices is webRTC. But I think that's only for video, not audio. But, again, I could be totally wrong on this point.

Alternatively, this is a chance for PC20 apps to support newer and more efficient CODECs than Android and iOS natively support which could be a competitive advantage (and the app either defaults to the newer codec or you can set it to prefer it). On the downside: that might require software decoding and suck more battery than formats which are decoded in hardware. Just thinking out loud...

@czemike, I think it could be fine (and consistent with the rest of the Podcasting 2.0 standard) to define specific formats for live-streaming into a Podcasting 2.0 app, as long as a compatible-with-everything web link is also included. After, we do this with nearly everything else: it functions in traditional podcast apps, but you get more benefits and a better experience in a Podcasting 2.0 app. So maybe we say the liveItem enclosure supports only webRTC and whatever else is modern for audio-only or video streams.

I come from a heavy web-design background. I remember all the creative hacks we had for displaying rounded corners. But then CSS3 started coming around and a lot of designers decided to just throw away the hacks. Old browsers would get sharp corners, modern browsers would get beautifully rounded corners. But even then, good designers had to ensure no functionality was broken with this decision. For example, making an arrow with CSS3 tricks, but older browsers might see only a square, which could be horribly misleading (imagine being told "turn SQUARE at the light"!).

Last reply!

@daveajones, since "live" is so much outside the realm of podcasting, both technologically and even the actual standard of podcasting, I think it's fine to avoid confusing repurposing of normal <item> tags. So maybe we drop everything except <title> and <pubDate> (I can see some benefit to communicating when the announcement was published).

[daveajones]

Have you made it mandatory?

I will as soon as we finish hashing this out.

[daveajones]

@jamescridland You also think there should be guidance for app developers to know what codecs and transports to prepare to handle, correct?

[theDanielJLewis]

To throw another wrench in the barrel of monkeys, we should ensure the live tag/block can be used even when the podcaster does not know their actual URL, yet. For example, if they live-stream to YouTube, it's a different URL every time, but they might not generate that URL until an hour before they go live.

[jamescridland]

@daveajones If you're really asking me, I'm failing hard in my comms here.

@theDanielJLewis I wonder how we can stipulate that the contentLink, wherever possible, goes to a method of watching/listening and not just a front page of a website. If that were me, that's what 301 redirects or Bitly links are for, but I do hear you that sometimes it's a little harder than that.

[daveajones]

If you're really asking me, I'm failing hard in my comms here.

I'm just trying to simplify the communications here with some simpler Q&A. I can't handle these gargantuan posts. It's just too much to parse. Not being trite. Just trying to keep our collective sanity. It's 9:30 at night here and I'm trying to figure out what the hell I'm supposed to do without reading the encyclopedia above. This morning I thought I knew, and it was simple. Now there's a ton more written. Humor me.

[theDanielJLewis]

@theDanielJLewis I wonder how we can stipulate that the contentLink, wherever possible, goes to a method of watching/listening and not just a front page of a website. If that were me, that's what 301 redirects or Bitly links are for, but I do hear you that sometimes it's a little harder than that.

Ah, you're unintentionally proving a point. Never use a 301 redirect for a destination that will change. :)

[theDanielJLewis]

You also think there should be guidance for app developers to know what codecs and transports to prepare to handle, correct?

@daveajones, since @jamescridland and I seem to be on the same page here, maybe I can answer for us both in my lovely American accent.

Within my longer-than-it-should've-been post, I mention that I think, yes, we should probably declare a very small list of codecs/transports that the Podcasting 2.0 live item will handle. Modern stuff like webRTC, and whatever is the equivalent for audio-only. But then also require/highly recommend a standard URL fallback that points either to a webpage where the stream can be consumed in any browser, or it's an app-specific URL (like Fireside Chat—barf).

[jamescridland]

@thedanieljlewis says:

So while webview is good, we need to remember that some webviews/URLs might need to trigger an app, just as if the link was tapped from a normal browser. I don't think you meant to exclude this, but I wanted to ensure we didn't forget this use case.

Indeed. On an Android phone, a youtube link is normally captured by the YouTube app, and opens in that for the best user experience. I think we ought to stipulate that these are https: web links, rather than non-standard protocols like overcast: that may not work on a device.

Never use a 301 redirect for a destination that will change. :)

Sorry. I meant a 302. My bad.

operating systems can natively play most media file formats

One example here is that iOS can't play Opus. This format is particularly useful for podcasters, since it's very low bitrate, very high quality audio for voice. Choose the little listen link in the byline when using Chrome, on any platform except iOS, to listen to a 16kbps stream.

@daveajones

I'm asking for:

a) a minimal list of supported codec/containers for a developer

b) a mandatory fallback HTML link so that a listener can always access the content, irrespective of app support. I am requiring this, not "strongly recommending it" - a liveItem should always work, irrespective of the app's support for individual codecs/containers/streams.

[daveajones]

a) a minimal list of supported codec/containers for a developer

b) a mandatory fallback HTML link so that a listener can always access the content, irrespective of app support. I am requiring this, not "strongly recommending it" - a liveItem should always work, irrespective of the app's support for individual codecs/containers/streams.

The solution for B is settled.

Is there any such list (A) that you know of, or do I need to start doing research to find out which codecs and transports overlap on web, ios, android, kaios?

[daveajones]

This is me talking out loud with a keyboard. By repeating what I think I'm hearing you say and narrating it back to you for confirmation, it helps us both know we're being understood. It's just the way I operate when overwhelmed with information.

[jamescridland]

@daveajones :

do I need to start doing research to find out which codecs and transports overlap on web, ios, android, kaios

My priority is to make things simple - so I think we should start with a very simple list of what existing creators are using. That list is probably driven by who wants to support this tag and what streams they are already making available. It would be helpful for developers to link to a live example (and to have an example RSS feed).

With a mandatory webview fallback (which might be to a proprietary alternative to an open stream, one shouldn't forget), it actually doesn't matter which is supported and which isn't, of course - we've now successfully fixed that issue. But a list of supported formats is going to help developers know what they should focus on supporting.

Streaming video isn't my specialism, and I'm afraid I don't really know how it works. What I do know is that most web browsers don't support .m3u8 playlists as used for HLS, though iOS/Safari does natively.

(As an aside, I'm assuming this tag is for both video and audio)

[SpencerPearson]

a) FUCK YOU! USE OPEN STANDARDS FOR EVERYTHING OR GET THE FUCK OUT!

Nobody has ever advocated this absurdly dramatized take and I don't appreciate the insinuation here at all.

[daveajones]

(As an aside, I'm assuming this tag is for both video and audio)

Very much so.

I'll add a list of bare minimums. We can expand later as needed. Mostly it will be mp3/icecast. That alone would cover 90% of it.

[SpencerPearson]

If we use the correct audio link in the enclosure in the first place, why mandate a web view fallback? Why not make it optional? Especially since the stated priority is to "make things simple"

[theDanielJLewis]

I know webRTC is commonly used for video streaming. It's what powers the backend of StreamYard, SquadCast, and the like.

[theDanielJLewis]

If we use the correct audio link in the enclosure in the first place, why mandate a web view fallback? Why not make it optional? Especially since the stated priority is to "make things simple"

@SpencerPearson, what are you calling "correct"?

The main reason for web fallback is for the apps that don't support streaming.

And for the audience, the web fallback might provide a preferred experience, such as video when the app can only do audio, or a live chat room, or other engaging benefits.

[daveajones]

I'm good with what needs to be changed now. I'll work on it tomorrow and post to close this thread with the PR.

[SpencerPearson]

By "correct" I just meant this list we are coming up with of suggested formats discussed above.

So if, like Dave says, ~90% of streams are mp3/icecast, and I put mp3/icecast in an enclosure, and my <link> points to a listen live page, does that cover all of the proposed requirements? Or is the suggestion to require this new <podcast:contentLink> in the tag as well?

[jamescridland]

@SpencerPearson wrote:

Nobody has ever advocated this absurdly dramatized take

I think this is an entirely accurate summary of the original discussion in Mastodon (and on the podcast) which essentially said that we don't want podcasters who want to use YouTube Live or other proprietary tools to use this tag to advertise their live streams. For humour, I added some naughty words and put it all in capitals; but in substance, it's what was originally proposed. Trying to add some levity to what is increasingly a bit of a grumpy discussion.

If we use the correct audio link in the enclosure in the first place, why mandate a web view fallback?

Because many podcasters out there are already using live streaming solutions from companies like YouTube, Facebook, Twitch, and others. Either they can't use liveItem as it stands, or they need to re-engineer their streaming to also offer a stream in the correct format (formats which, I need to remind you, are not documented yet, so who knows what a developer needs to offer).

We mandate a web fallback so that, whatever app you're using on whatever platform, liveItem always works. If, as a creator, the only live stream I have available is in YouTube Live, then liveItem still works for them.

Or, in short:

"Why are we mandating a fallback?" <= so it works for every podcaster; and so that developers can quickly integrate this into every app without having to support every possibly streaming format under the sun.

[SpencerPearson]

I think this is an entirely accurate summary of the original discussion in Mastodon (and on the podcast) which essentially said that we don't want podcasters who want to use YouTube Live or other proprietary tools to use this tag to advertise their live streams.

What you think was essentially said seems wildly off base from my perspective, so much so I find it difficult to believe we were party to the same conversation and listened to the same PC20 episode.

For humour, I added some naughty words and put it all in capitals; but in substance, it's what was originally proposed. Trying to add some levity to what is increasingly a bit of a grumpy discussion.

It is interesting also that you see the levity coming for your direction. As for implying that we are somehow chasing people we don't see eye-to-eye with from the project, hurling insults and obscenities at them and acting like spoiled petulant children who absolutely must get their way, it seems that particular position is already occupied. For the sake of levity, tee hee hee.

[jamescridland]

What you think was essentially said seems wildly off base from my perspective

What was said was that unless live streams were open and could be played directly in the app, then they were not to be supported in this tag. Your own comments, above, say that using YouTube Live is not "smart or professional" and that there's "no excuse" for not providing a different more open stream. That's not a million miles away from my précis of "use open standards or get out".

I'm delighted that we've managed to make this tag more inclusive - so that even if you only have a YouTube Live stream, you can still use it. It won't be as good to link to a webview; but it means that we've considerably more podcasters who are capable of using this tag.

Now, either you agree or disagree with that, and that's fine; but I've not descended to personal abuse, Spencer, and there's no need for you to do so. Try and be constructive.

[theDanielJLewis]

"Why are we mandating a fallback?" <= so it works for every podcaster; and so that developers can quickly integrate this into every app without having to support every possibly streaming format under the sun.

And so it works for every listener.