Proposal: Live System Architecture #212
Comments
|
Thank you for putting in the work for such a thorough writeup. Very helpful. |
|
Hmm, I've seen various live tags proposed in several different places now... this aligns most closely with what I've had in mind, and I'm going to give a shot at an opinionated implementation for Peertube. A few thoughts. I understand some people just want one stream link and a recurring schedule, but we all know the schedules never match up with reality except for perhaps stricter business use cases. I think we can optionally allow for a "planned" schedule such as an ICS file, but I think this would be most useful for 1. feed refresh hints 2. UX display in a sort of calendar setting (when is this stream happening next) WIth ISO 8601 durations we can include the planned start and end time into one tag. The benefit of this is it doesn't strictly require an end time, like you alluded to, but it can be included. I can see a use case both with and without and I think websub should be a strict requirement around this feature for it to function correctly regardless, where the RSS feed host either removes the live item or adds an end after the stream ends. There may be a need here for Podcast Index to offer a basic live notification API for applications that don't host their own servers. RTMP is fine but it's also the most difficult to support especially on the web. I think RTMP, HLS, and DASH should all be options and I foresee HLS initially being the most common due to existing web technologies. All three have their pros/cons that I can see various different providers being interested in supporting. I think peertube does a weird RTMP->HLS thing both to support existing streaming software (OBS for example) but to get the benefits of HLS+peer-to-peer. I know even less about the audio-only streaming side so I can't really speak to that. I'm going to go ahead and plug alternateEnclosure here for those various benefits. Maybe there's also opportunity to provide embedded players instead of having every client bring their own? That could be disastrous for UX, so I'm not sure. Lastly, why not Anyway, with the right implementation here I can see this so close to becoming both youtube live/twitch alternatives with all of our own features built on top. Kind of curious to see if the Floatplane guys would have any input also and be willing to collaborate, since they represent a pretty strong community as a realistic youtube-alternative. |
I had thought of this as an optional tag, for people who intend on keeping a schedule, or at least attempting to keep one. One of the things I had always heard about the success of a podcast is to have a show that maintains some sort of schedule. The granularity may be the most suspect thing. Many shows offer a "daily, weekdays", "weekly", "twice-a-week", with no guarantee on time of day. This is probably the most difficult part of setting a standard for schedule.
Existing standards are good, and for explicit dates I think ISO8601 is a possible solution, but it does not lend itself to posting a schedule... Thursdays and Sundays at 12PM Eastern or Weekdays at 3, at least not from what I can garner from reading the wiki.
I was unaware of websub when I wrote it down. After reading up on it, it looks like I am endorsing the same. I would like to hear hosting providers opinion on this point, as they would bear the burden of running it. That said, there are a lot of implementations that allow for this to be leveraged... (https://github.com/w3c/websub/tree/master/implementation-reports)
I'm not clear on how difficult this is to stand up. I did it in just a few minutes using nginx and the RTMP extension on a RaspberryPi 3 and putting one up as a publisher should be trivial as well. I don't know how it scales in terms of compute resources... This doesn't feel like a limiting aspect of a
I'd like to see what @daveajones has to say here as NA does a live audio stream, but I think they are using a basic html5
I don't know how the various feed aggregators would handle any of this. Does Apple just ignore any tags and their children that it doesn't support? Frankly, I wrote something here to start this conversation...
My goal with this description and of the |
A schedule of when a stream plans to start and the actual start are two very different things. The schedule is ultimately meaningless in the face of when something goes live and trying to predict it will fail, you can only provide a suggestion. To represent the schedule itself, I think ICS is perfect here. It's widespread and a very well known standard. This could just be a URL with a last modified timestamp. I am all for a schedule. However, I'm separately suggesting the "start"/"end" (duration) be the time when the stream has started/ended and applications can display it as an active live stream or know when its over. The live item could even disappear completely if the stream doesn't persist as something to watch after it's over. This gets us the distance between the client application merely guessing when something might be live to having a reasonable amount of confidence that it's live so it can display it and notify the user. It really depends on websub + application notifications however. |
|
This tag deserves a phase all to itself I think. It’s a big one and we need to get it right. |
|
(Regarding schedule, #154 might be related/relevant.) |
This was my intent - that a suggestion could be part of the feed so an app could surface it to the end user. Like a reminder in the morning.
No disagreement there.
I'm assuming that this might just be "solved" because a live episode that comes back as a "produced" episode would automatically update the feed with the permanent version and a temporal live episode with no watch later wouldn't exist. I'm also guessing this particular comment has to do with nuances of peertube and I don't yet understand the challenges there.
I see this is as a "morning reminder" that my show is scheduled to be live at 12:00 (local). PodPing would do the actual announcement. |
|
Whats the reason to wrap the item into |
|
I feel like this was discussed but I don’t remember why the decision was made. |
|
I don't think live stream URLs have to live within Regardless, I need to get a usable test implementation out before saying I have a preference either way. My gut feeling is it should just be |
Well my intention is to provide enough information to keep the application from having to assume anything. If we provide a way to explicitly tell the application what happened, no assumptions have to be made (ignoring the issue with bad data but we will never prevent that).
Yeah, PodPing wasn't a thing when I made this comment :). However schedules do not indicate liveness. They can and will be wrong. |
|
@agates, I feel like we've both come to the conclusion that podping is the obvious solution to notification of live. Maybe I should rename it from podcast:scheduledstart to podcast:suggestedstart or podcast:plannedstart ? |
|
Reminder here to use ISO8601 date format for live start/end. |
I had hoped we could have a standard for the start/end that would allow for a "set once" type of scheduling, such-as "every Monday and Wednesday at 11". It could be accomplished using an iCalendar entry (RFC6321 provides a schema for this in XML), though it may make the file larger, it would help the pod-caster more easily update his audience. It adds all of the repeating functionality without having to make the author update their plan each week in advance of their show. Caveat: I don't think RFC6321 aka xCal, is an easy format to understand, but it is - in my opinion - the "right" way. |
|
As a comment from experience - an automatic "every Monday and Wednesday at 11am" setting leads to sadness. Podcasts (and events) take vacations and sometimes disappear altogether. We don't want to make it too easy to set something like this, and pollute the space with ghost live events for podcasts that have long-since stopped recording. The bottom of https://pod.events says:
While there's nothing to stop someone from producing an RSS feed with repeating events in this use-case, I would strongly recommend not codifying a method to repeat events. |
|
I'm inclined to agree and I think the start/end attributes are best described this way: You can set the start time ahead of the start of the stream to indicate a scheduled start with Having a separate schedule, be it RFC6321, another set of "schedule" timestamps, or otherwise, helps mitigate this confusion. This is really important because it gives flexibility. If you don't want a repeating event, you don't have to use one. ical can support both one-time and recurring events trivially, set per-liveItem. Webcal exists to handle multiple events, recurring or not, and things like cancellations. You can think of webcal like a protocol supporting multiple iCal links. We need to consider things outside of the podcast ecosystem. For example, there is absolutely nothing preventing someone from starting up a regularly-scheduled indie television show/network that handles live premiers. Whether or not that seems feasible to anyone is another matter, but the point is to be flexible. Lastly, my biggest reason for making the distinction between the scheduled start and actual start is because the client having an approximate (albeit relative) starting timestamp is useful for a couple things: 1. metrics and 2. allowing the client to know when it's supposed to be able to play the stream without a failure, in the case of video streams for example that aren't on 24/7. |
|
I can see both sides of this. Having a schedule available makes sense. Also @jamescridland has a good point about schedule pollution. Is the solution to just break that out into a separate A schedule tag could allow for a TVGuide for podcasts service to exist. This would also greatly improve polling performance without resorting to algorithmic guesswork. |
|
@daveajones I was thinking about a separate tag also, yes. We could get away with it in another phase if needed since scheduling is complicated enough. |
|
The only concern I have with an external file for the schedule is that it requires a separate polling to see if it updates. If it's in the rss it would be pulled with each update to the xml. While there is nothing stopping us from polling both, it is antithetical to many of the other things we've done. Maybe we can extend podping to allow a schedule update notice? This would especially be true for a live only show that wouldn't have a need to update their xml in a repeating schedule format. @jamescridland, A dead/ghost feed doesn't get solved by limiting the functionality. A user stops subscribing to a feed if it's dead (and only If it's clogging up their lists or they're ocd like me) and this would be especially true if it were hitting them with reminders for a show that isn't happening. For that matter, I'm not totally clear on what problem posting every planned live event schedule individually solves. In my view, it adds yet another detail that someone will screw up in their rss while updating it weekly/daily. The one thing about using an ics I do like is that there are very easy ways to create and manage the ics. Every available scheduling software supports their creation and editing. Everything from creating a series to an occurrence, to a single occurrence edit. Not that I encourage it, but one could create a calendar in Google calendar for just the podcast schedule and share the ics quite easily. Then any would immediately propagate. |
|
I was indeed thinking about adding a "schedule" reason to podping to indicate the schedule has been updated. I think we were contemplating on doing so for other external resources as well, such as chapters. |
Architecture Proposal
In order to settle on a tag, its important to settle on the usage of the system as a whole.
Conventions
To help with the example I use the following terms and conventions:
bold = subsystem
Terms
Considerations
Proposed Use Case - A publisher model with centralized aggregation and decentralized propagation of notification
Note: The use of RTMP was chosen to provide a specific mechanism, but could be replaced with others interchangeably
Proposed Enclosures
Concerns
<podcast:scheduledstart>could be a discrete time, or a pattern? Having someone update their XML and hope that it propagates to their subscribers in time is worrisome.<podcast:scheduledstop>could be a disaster. I don't even know if anyone would care...<title>&<podcast:episode>are either redundant or useless. I'm not sure they are helpful in the context. The<channel>text is probably the most helpful here and<podcast:episode>suffers from the same issue as<scheduledstart>.The text was updated successfully, but these errors were encountered: