Proposal: <podcast:valueTimeSplit> tag #512
Replies: 5 comments 9 replies
-
|
I like this a lot. It adds a few thing I had not considered. |
Beta Was this translation helpful? Give feedback.
-
|
I'm thinking about the TLV that gets sent to the remoteSplit. It seems like we could add a clipped by podcast/episode in the TLV so the remoteSplit knows who is clipping their episode. That's easy enough to get from the main channel/item. Also, the clipped podcast and episode are easy enough to get from the two guids, but some way to have a timestamp of where the clip is occurring in the remoteItem might be nice to be able to include in the remoteSplit, so the clipped podcaster can see in their TLV record exactly what was being clipped from their episode. |
Beta Was this translation helpful? Give feedback.
-
I actually had a |
Beta Was this translation helpful? Give feedback.
-
Yeah, that would work. |
Beta Was this translation helpful? Give feedback.
-
|
What is the possibility of remote time split inception with this approach? Is it something we need to be worried about? If so, we can just put wording in like: "If the value block from the remote item also contains a That's hard wording. I hope I'm making sense. |
Beta Was this translation helpful? Give feedback.
-
|
That makes sense, yes. I will add that. |
Beta Was this translation helpful? Give feedback.
-
|
As described, clips that don't span a 1 minute marker would not receive any streaming sats. For example, the 53 second clip above would not receive any streaming sats if the start time was "305". If clips are likely to be more than 1 minute this doesn't matter. (I haven't implemented streaming sats myself yet so I may have misunderstood the podcast:value spec) |
Beta Was this translation helpful? Give feedback.
-
|
There is no actual mandatory requirement to have minute-by-minute payments, that has just how people have been implementing it for statistical purposes. It's very limited for reasons you described and I think apps should make sure to account for this. In the future I want to push people to have less payments overall and send batch timestamp metadata in TLVs instead of having individual payments, which would help address the issue by thinking of listening/watch statistics as metadata instead of number of payments. |
Beta Was this translation helpful? Give feedback.
-
|
The spec does say The "time interval" for calculating payments is always 1 minute which I understood to mean on the minute boundary but I guess that can be interpreted in different ways |
Beta Was this translation helpful? Give feedback.
-
|
Nothing enforces clients to adhere to bad specifications, at the end of the day they are only suggestions :) I provided an example of how we can get passed in this Mastodon thread |
Beta Was this translation helpful? Give feedback.
-
The "1 minute" is a sliding window instead of a boundary. Some podcasts could actually be less than 1 minute (like maybe a music track) so it's not necessary to hit a certain minute boundary. |
Beta Was this translation helpful? Give feedback.
-
|
IDEA: If a podcast supports music chapters like Boostergram Ball. Then each track has a unique itemGUID with a start time and duration. Each music track is really just a link to an external podcast episode/track. 
Podfans already allows users to create episode-level playlists from podcasts using the itemGUID. This also means Podfans can now reward the creator of the playlist with a small 1% split if any of the episodes in their playlist is shared or played. #V4V Example of a Phase 7 tag? But what if we extend this remoteItem to the chapter level for a non-music podcast. We could also use startTime and Duration fields to link to a specific point in a chapter. <podcast:remoteItem 
Of course I answered my own question. We don't need a chapterGUID if we simply use the ValueTimeSplit start time and duration on the itemGUID where the medium is 'podcast' In fact we could contain multiple ValueTimeSplit tags in the RSS feed from multiple podcasts if we also use the feedGUID. <podcast:valueTimeSplit startTime="60" duration="237" remotePercentage="95"> The question now is what UI to give podcast creators so they can create PodRolls, simply by looking up the name of a podcast but storing it as a feedGUID in the RSS. We already have a search against the PodcastIndex for users. We can adapt this search to make the action button 'add to podroll' 
podcast:podroll We already have a UI for users to create Playlists from one podcast or multiple podcasts. 
We could extend this UI to chapters by adding an action button next to chapters but we would still store the chapter playlist using the itemGUID and take the chapter time marker and duration between chapters.
The question is would users want a chapter level playlist. I can see the value in doing this with music playlists. Boostergram is storing music tracks/episodes as chapters. The other UI is for podcast creators. Sovreign Feeds is the only/best option right now. But how could other podcast apps offer creators a similar UI. Dave and Adam often play clips on their Podcasting 2.0 show. What if those clips were stored in the RSS feed as ValueTimeSplits??? |
Beta Was this translation helpful? Give feedback.
-
|
This is the idea of List Mediums with We may need to re-evaluate value attribution on those scenarios, I could see a 1% split being reasonable. Maybe that should be up to the app, however. If users were able to set their own split in a playlist that would be easily abused. If you wanted to create playlists all you would do is host the RSS feed and submit it to Podping -- I don't know if @daveajones consumes them yet in podcast index. |
Beta Was this translation helpful? Give feedback.
-
|
Since we're using remoteGuids to reference a feed, perhaps we need some sort of new <podcast:curation split='1'>tag in the referenced feed where the podcaster decides how much they are willing to share with a curator. It can default to zero if not present. |
Beta Was this translation helpful? Give feedback.
-
Proposal: <podcast:valueTimeSplit> tag
The intent of this proposal is to provide a tag that allows different value splits for a certain period of time. It is a combination of the concept of
<podcast:soundbite>and<podcast:remoteItem>where a start time and a duration is supplied with alternative value recipients. The alternative value recipients are not required to be remote, as the recipients may not have an RSS feed/item of their own to reference.This is suggested as an alternative to a chapter-based approach to simplify the implementation and use existing XML tags.
Example referencing external music
The following shows an example referencing two different external songs. The first is played in full starting at 1 minute into the podcast. The second is played 5 minutes and 30 seconds into the podcast for a duration of 53 seconds, starting at 2 minutes and 54 seconds of the song featuring a wicked guitar solo.
Example referencing different value recipients
The following shows an example different value recipients for a two specific segments of a show
Definition
<podcast:valueTimeSplit>The
<podcast:valueTimeSplit>tag allows time-based changes of value recipients in a given value block for an item.This can either contain one or more
<podcast:valueRecipient>tags or exactly one<podcast:remoteItem>tag. If a<podcast:remoteItem>tag is present, theremotePercentageattribute can be defined to control how much the remote value block's<podcast:valueRecipient>tags will receive as a whole on top of the default, non-fee<podcast:valueRecipient>tags.If the remote value block contains any
<podcast:valueTimeSplit>tags, they should be ignored even if theremoteStartTimeindicates it's in a position that would invoke them. When referencing a remote value block, only the root level block splits should be used and any<podcast:valueTimeSplit>children are to be ignored.Fees from the default
<podcast:valueRecipient>tags should remain to be calculated before anything is taken out from<podcast:valueTimeSplit>.Parent
<podcast:value>Count
Multiple
Attributes
startTime(required) - The time in the current item where the value split beginsduration(required) - How long the value split lastsremoteStartTime(optional) - The time in the remote item where the value split begins. Allows the timestamp to be set correctly in value metadata. If not defined, defaults to 0.remotePercentage(optional) - The percentage of the payment the remote recipients will receive if a<podcast:remoteItem>is present. If not defined, defaults to 100. If the value is less than 0, 0 is assumed. If the value is greater than 100, 100 is assumed.Beta Was this translation helpful? Give feedback.
All reactions