-
Notifications
You must be signed in to change notification settings - Fork 116
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposal: <podcast:alternateEnclosure> update #174
Comments
This is an excellent write up Alecks. I’ll translate it into a formal proposal that takes the place of alternateEnclosure and put into the readme as I do the phase 2 finalization work this week. |
Dave, do you think it would be useful to recommend or provide a place to put one or more public keys on the Channel? The flow would look like:
|
I do like this proposal. Thoughts:
The I still don't quite understand why we're changing the name from |
I think this proposal should reuse existing vocabulary from the HTML5 audio/video tag (e.g. |
I've also asked Thomas Barrasso to take a look at this. He runs PodLP, the most popular podcast app on KaiOS, a mobile phone OS that's in use in many developing countries. PodLP has more than 4 million installs, and I suspect a low-bitrate version would be a great plan for those listeners. |
That’s a great idea James. As far as naming goes, this is a namespaced element. Why don't we just call it |
I just called it something that made the most semantic sense to me -- to my non-podcast brain that's what I came up with (really I kept thinking wtf is an enclosure?) But it doesn't matter to me much one way or another. |
I like this.
The point of keeping this generic enough was there is not just one realistic use case, but alas I only pulled from something I had to work with -- wanted to take something that's not podcast RSS and see what it would take to add it. As long as Dave can wrangle around the different possibilities, maybe a few examples for some theoretical scenarios can be produced |
As far as I'm concerned (again I have no dog in this fight, don't crucify me), the enclosure tag is there for backwards compatibility. Maybe an optional
Agreed |
I think this proposal definitely has value. As far as PodLP is concerned, dynamically selecting an appropriate bitrate based on network speeds is a great idea and is something already supported by file formats like M3U. Some hosts like iono.fm already offer this both manually (by adjusting a URL query parameter) and automatically based on As far as naming conventions, I'd recommend not using
For |
Yes, this will allow any kind of streaming option, be it M3U, HLS, DASH, or some future protocol. Just needs a supported MIME type and source file.
Does
The purpose of
Definitely open to changing the name of this, I just used what was previously in
I like this a lot, and integrity could still be useful for validating the download of .m3u, m3u8, or .mpd stream files for example. My only concern is SRI doesn't appear to support PGP, which I think could be a useful feature for some podcasts (admittedly a low percentage). |
However we do this, I'd like to ensure that things are programmatically readable - so that a podcast app being used on a Spanish-language phone, as one example, can know to choose the correct audio. So if one proposal is to offer different language versions here, please let's use the ISO 639-1 standard language codes - so some form of |
Hmm, maybe language is a bad example for |
Updated the original post, added some suggestions, cleared up the examples a bit. |
Is it possible to add bittorrent magnets or just the CID for IPFS? I know they are not actually http links (which the RSS standard i think is only supposed to accept) Also I assumed that a there would also be space for a youtube link. I release a video version of my podcast on youtube, it is the same podcast from an audio perspective, i don't see why in this case it wouldn't be a valid alternate enclosure (which this is recommended to replace) Finally a lot of people are mentioning the power of this tag for multiple versions of the same audio file, but at lower bitrates. There was talk of bitrate peeling being introduced into the Vorbis specification (used in ogg files): https://en.wikipedia.org/wiki/Bitrate_peeling I was disappointed to find out it was never fully implemented, maybe an appropriate use case to push it through never really materialised. |
As of RSS 2.0, any IANA-registered URI scheme is allowed. I will rename "URL" to "URI" to make it clear it can support any kind of URI and link to the IANA register. This will allow support of both magnet links and IPFS/IPNS, as well as anything else in the register.
My only concern with this is the client is expected to be able to download the media directly from the URI and play it with no other information. To support youtube under this tag, a client would need to bundle something like I'm not against having alternative sources but I feel it goes beyond media files and may belong to its own tag on the item. Something like...
Both HLS ( |
Well this is potentially the problem with replacing words alternate enclosure with media, at least conceptually. I would assume that alternate enclosure is a valid type for youtube, but maybe not for media. Ultimately we are moving into a streaming world and in that case I think it is a valid media type. But you are right, youtube is not downloadable natively. I suppose it depends on how dogmatic we want to be on media, I know @daveajones has mentioned the problem for certain words being picked, but their eventual usage may not track exactly with where they end up being used. If media is a word that is too baised, maybe it isn't appropriate. Maybe there is only one media file per episode and everything else is an alternate source? |
Just a short comment: |
@douglaskastle I'd suggest that this is likely to be the case in reality. The main media file is the
@agates I don't think that's a requirement here. Podcasts don't need to be downloaded; they can quite successfully be streamed (and arguably the 'download' model for podcasting is partially a function of age - it was the only possible way to get hold of media in the era of slow download speeds). I think these are pointers to alternate sources of the same content - different bitrates/codecs, or with video, or something else. But if there's a way to identify a stream, or even a pseudo-mime-type like a 'video/youtube', or something else, I don't see that as being an issue. If the client can ignore the ones it can't deal with, that's cool. I'm still quite keen that "this podcast but in Spanish" is dealt with in a different way. This is a different proposal, I think - and it seems to me that you could do so using a LINK REL in the standard way at the top of the file, in a similar way to HTML, which works like...
After all, if the podcast is in Spanish, so will the artwork, description, etc etc, be. You'll want to point someone off to a different RSS feed in that language, I would suspect. |
For clarification, when I say download, I mean it only in the sense of using a network connection to receive data -- not whether or not the app does it ahead of time, saves it to the disk, etc. (Not saying one use of the word is right or wrong, but I see how that can be confusing) I can see the value in having a sort of YouTube metatype, but on the other hand I can see value in presenting it as an alternative platform for the user to navigate to and not just an alternative source of media -- the idea being YouTube offers a lot more and the user might want to actually open it open in their browser, for example. I've done this to view comments before. That is the distinction I see between files to play and wholly alternative hosts with their own ecosystem -- the app could still see this as YouTube and offer to download/stream it, no argument there. That said, now I'm thinking maybe this should just be alternateEnclosure to avoid confusion. As for the language and size, I'm going to defer that to @daveajones :) |
Why not using the |
I don’t want to get too bogged down in what we call it. Ultimately, what it is called is really just marketing. HTML has the tag I still think it makes sense to call it simply I think we need to pick a couple of main use cases for this tag to address initially (the ones causing the biggest pain points today) and one side case. That will be enough to spur adoption. We can always then extend the spec later to add a new attribute to it if we see that it needs to capture a new use case it can’t handle. On that note, I think these are the pain points that come up the most:
I put that list into the order of biggest to smallest need based on just my own anecdotal observations. It might be wrong. If we can solve all of those needs in one tag or structure that would be ideal since attempts at putting “live” into its own element in the past has had the result of zero adoption of that element. |
Media does feel a bit generic doesn’t it. I think something with “enclosure” in it will carry more weight in the community. It’s really just a marketing thing, but marketing is a reality so it’s something to keep in mind. Telling someone about the new “alternateEnclosure” tag is pretty easy since it carries its full intent directly in the name. (I’m being a little loose with “full” here. 😊) |
Talking about media, maybe we could take a look at the media rss extension.
https://www.rssboard.org/media-rss#media-content
They do have some overlap here with `media:content` I guess, it could be
inspiring on how to handle this.
Imho it's also good to keep it in mind anyway (to prevent confusion or
repeating weakness of an existing tag)
Pof Magicfingers (Giovanni Olivera)
… I suppose it depends on how dogmatic we want to be on media, I know
@daveajones <https://github.com/daveajones> has mentioned the problem for
certain words being picked, but their eventual usage may not track exactly
with where they end up being used. If media is a word that is too baised,
maybe it isn't appropriate.
Media does feel a bit generic doesn’t it. I think something with
“enclosure” in it will carry more weight in the community. It’s really just
a marketing thing, but marketing is a reality so it’s something to keep in
mind. Telling someone about the new “alternateEnclosure” tag is pretty easy
since it carries its full intent directly in the name.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#174 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AADST7PYIQAM3H7AE3OM3RDTBTSMJANCNFSM4W4GN7KA>
.
|
I do like the simplicity of |
For those interested, there's also been a tiny bit of discussion on live media representation for an item at Chocobozzz/PeerTube#3786, but I'll continue it here. One thing I'm not clear on, and this is where me not being a podcaster shows most: What is the general consensus around updating an |
We should avoid anything that even has the potential for problems. The name is the least important thing. |
Trying to think outside the box, threw this together as a quick idea -- what if the recommendation for a live stream is an
(I understand this doesn't take into account youtube/twitch/troll-room -- I've intentionally excluded them for now to focus on live audio/video content streams) Live version of upcoming show at 11am CST on March 4, 2021, 3 hours long: <title>Episode 1326 LIVE!!!</title>
<guid>some-random-live-guid</guid>
<podcast:alternateEnclosure type="audio/mpeg" bitrate="128000" title="Live Audio" live="true">
<podcast:source uri="https://best-podcast.com/live-stream-mpeg" />
<podcast:timeInterval>2021-03-04T11:00:00-06:00/PT3H<podcast:timeInterval>
</podcast:alternateEnclosure>
<podcast:alternateEnclosure type="audio/aac" bitrate="160000" title="Live Audio - High Quality" live="true">
<podcast:source uri="https://best-podcast.com/live-stream-aac" />
<podcast:timeInterval>2021-03-04T11:00:00-06:00/PT3H<podcast:timeInterval>
</podcast:alternateEnclosure>
<podcast:alternateEnclosure type="application/x-mpegURL" title="Live Dynamic Audio/Video Stream" live="true">
<podcast:source uri="https://best-podcast.com/master.m3u8" />
<podcast:source uri="ipfs://exampleLinkThatDoesntWorkHLS" />
<podcast:timeInterval>2021-03-04T11:00:00-06:00/PT3H<podcast:timeInterval>
</podcast:alternateEnclosure> Actual episode release, guid is different: <title>Episode 1326: Clever Title</title>
<enclosure url="https://best-podcast.com/file-0.mp3" length="43200000" type="audio/mpeg" />
<guid>different-guid-for-same-episode-with-enclosure</guid>
<podcast:alternateEnclosure type="audio/mpeg" length="43200000" bitrate="128000" title="Audio" default="true">
<podcast:source uri="https://best-podcast.com/file-0.mp3" />
</podcast:alternateEnclosure>
<podcast:alternateEnclosure type="audio/aac" length="54000000" bitrate="160000" title="Audio - Proprietary AAC">
<podcast:source uri="https://best-podcast.com/file-proprietary.aac" />
</podcast:alternateEnclosure> EDIT: No idea how live streams would work with non-http sources |
Everyone does it a bit differently. Even I’ve done it differently in two different aggregators. But generally the only sure-fire way to make sure it changes everywhere is to change the GUID like you said, which will be a new item. |
It seems to me that How about
|
What's the thinking on this if you don't mind expounding a bit? |
I think I'm just trying to keep things simple. We have an enclosure tag. That will, realistically, never go away. Any podcast RSS needs the standard enclosure tag. An "alternateEnclosure" tag is one that includes alternates to the main enclosure. That main enclosure is in the enclosure tag. The additional ones listed under "alternate" are alternative enclosures. An "podcast:enclosures" tag lists all available enclosures. This new tag may have more detail than is currently available in the old enclosure tag. So it's absolutely valid to include all of them, with all the information. We should probably highlight which is the default. It all depends what the use-case is here. |
Thanks. Makes sense. I say we just keep the naming as “alternateEnclosure” then. Avoids duplication and preserves the intent of the tag. |
On other comment – it looks like peertube is already including torrent links in it's rss feeds (using mediarss): https://video.codefor.de/feeds/videos.xml?videoChannelId=3 <item>
<title><![CDATA[ The Open Show 1.2: Was ist Linked Open Data? ]]></title>
<link>https://video.codefor.de/videos/watch/791d6351-2fbe-4335-bc98-5e99d6dc10fb</link>
<guid>https://video.codefor.de/videos/watch/791d6351-2fbe-4335-bc98-5e99d6dc10fb</guid>
<pubDate>Tue, 19 Jan 2021 17:11:26 GMT</pubDate>
<description>
<![CDATA[ Was ist Linked Open Data und wie können uns verknüpfte, offene Daten im Alltag helfen? ]]>
</description>
<content:encoded>
<![CDATA[ Was ist Linked Open Data und wie können uns verknüpfte, offene Daten im Alltag helfen? ]]>
</content:encoded>
<dc:creator>julia</dc:creator>
<media:title type="plain">The Open Show 1.2: Was ist Linked Open Data?</media:title>
<media:description type="plain">Was ist Linked Open Data und wie können uns verknüpfte, offene Daten im Alltag helfen?</media:description>
<media:thumbnail url="https://video.codefor.de/static/thumbnails/791d6351-2fbe-4335-bc98-5e99d6dc10fb.jpg" height="122" width="223"> </media:thumbnail>
<media:rating>nonadult</media:rating>
<media:category scheme="http://search.yahoo.com/mrss/category_schema" label="Education">13</media:category>
<media:community>
<media:statistics views="22"> </media:statistics>
</media:community>
<media:embed url="/videos/embed/791d6351-2fbe-4335-bc98-5e99d6dc10fb"> </media:embed>
<media:player url="/videos/watch/791d6351-2fbe-4335-bc98-5e99d6dc10fb"> </media:player>
<enclosure type="application/x-bittorrent" url="https://video.codefor.de/static/torrents/791d6351-2fbe-4335-bc98-5e99d6dc10fb-720.torrent" length="88238199"> </enclosure>
<media:group>
<media:peerLink type="application/x-bittorrent" href="https://video.codefor.de/static/torrents/791d6351-2fbe-4335-bc98-5e99d6dc10fb-720.torrent" isDefault="true"> </media:peerLink>
<media:peerLink type="application/x-bittorrent" href="https://video.codefor.de/static/torrents/791d6351-2fbe-4335-bc98-5e99d6dc10fb-720.torrent"> </media:peerLink>
<media:peerLink type="application/x-bittorrent" href="https://video.codefor.de/static/torrents/791d6351-2fbe-4335-bc98-5e99d6dc10fb-360.torrent"> </media:peerLink>
<media:peerLink type="application/x-bittorrent" href="https://video.codefor.de/static/torrents/791d6351-2fbe-4335-bc98-5e99d6dc10fb-360.torrent"> </media:peerLink>
<media:peerLink type="application/x-bittorrent" href="https://video.codefor.de/static/torrents/791d6351-2fbe-4335-bc98-5e99d6dc10fb-240.torrent"> </media:peerLink>
<media:peerLink type="application/x-bittorrent" href="https://video.codefor.de/static/torrents/791d6351-2fbe-4335-bc98-5e99d6dc10fb-240.torrent"> </media:peerLink>
<media:peerLink type="application/x-bittorrent" href="https://video.codefor.de/static/torrents/791d6351-2fbe-4335-bc98-5e99d6dc10fb-0.torrent"> </media:peerLink>
<media:peerLink type="application/x-bittorrent" href="https://video.codefor.de/static/torrents/791d6351-2fbe-4335-bc98-5e99d6dc10fb-0.torrent"> </media:peerLink>
<media:content url="https://video.codefor.de/static/webseed/791d6351-2fbe-4335-bc98-5e99d6dc10fb-720.mp4" fileSize="88238199" type="video/mp4" medium="video" framerate="30" duration="276" height="720" lang="de"> </media:content>
<media:content url="https://video.codefor.de/static/webseed/791d6351-2fbe-4335-bc98-5e99d6dc10fb-720.mp4" fileSize="88135041" type="video/mp4" medium="video" framerate="30" duration="276" height="720" lang="de"> </media:content>
<media:content url="https://video.codefor.de/static/webseed/791d6351-2fbe-4335-bc98-5e99d6dc10fb-360.mp4" fileSize="7863651" type="video/mp4" medium="video" framerate="30" duration="276" height="360" lang="de"> </media:content>
<media:content url="https://video.codefor.de/static/webseed/791d6351-2fbe-4335-bc98-5e99d6dc10fb-360.mp4" fileSize="7774273" type="video/mp4" medium="video" framerate="30" duration="276" height="360" lang="de"> </media:content>
<media:content url="https://video.codefor.de/static/webseed/791d6351-2fbe-4335-bc98-5e99d6dc10fb-240.mp4" fileSize="6599939" type="video/mp4" medium="video" framerate="30" duration="276" height="240" lang="de"> </media:content>
<media:content url="https://video.codefor.de/static/webseed/791d6351-2fbe-4335-bc98-5e99d6dc10fb-240.mp4" fileSize="6511257" type="video/mp4" medium="video" framerate="30" duration="276" height="240" lang="de"> </media:content>
<media:content url="https://video.codefor.de/static/webseed/791d6351-2fbe-4335-bc98-5e99d6dc10fb-0.mp4" fileSize="6649144" type="video/mp4" medium="video" framerate="0" duration="276" height="0" lang="de"> </media:content>
<media:content url="https://video.codefor.de/static/webseed/791d6351-2fbe-4335-bc98-5e99d6dc10fb-0.mp4" fileSize="6660174" type="video/mp4" medium="video" framerate="0" duration="276" height="0" lang="de"> </media:content>
</media:group>
</item> |
They do yes, I am very familiar with this code and currently have a fork that adds the podcast namespace. |
Updated the proposal:
I'm not settled on how to include optional attributes like "height" as it feels like these optional attributes may only grow over time. But adding another child tag to include the information is also clunky, though I think it could work. |
Thanks for this. Should I write it up into the main phase 3 of the readme or does it need its own proposal document? |
I can't think of a reason to keep it separate at the moment |
I've written in up in the README and a separate doc. Just felt right since it's a big tag: |
FYI this was formally adopted in Phase 3. |
This tag is a named collection of different transports available to acquire a single type of media. There can be multiple as needed, to provide media encoded in different ways or provided by different means of transport.
This is designed to provide sufficient information to the podcast player to be able to determine what type of media it supports along with the transports available to acquire it. At the same time, sufficient information should be provided to be able to allow sane defaults or preferences presented to the user.
For example, one podcast player might only support audio, but can play it in various different codecs such as OPUS, AAC, MP3, etc. Another may support video, but only video in h264 format.
If desired, media related to the enclosure -- but which does not have the same content -- can be provided. Perhaps a "bloopers" take, or the same episode in a different language.
Lastly, I propose optional information to verify integrity of downloaded media via hashes or maybe even PGP signatures. Obviously, PGP verification would require the podcast application to separately import trusted public keys to be useful. Adhering to the Subresource Integrity standard will help here for hashes.
EDIT: I also didn't include this on the Channel primarily because I like the idea proposed in #77 to allow an item to be included at the channel level. But I'm not against having this at the Channel level, either.
<podcast:alternateEnclosure type="[mime type]" length="[(int)]" bitrate="[(float)]" height="[(int)]" lang="[(string)]" rel="[(string)]" codecs="[(string)]" default="[(boolean)]"> ... </podcast:alternateEnclosure>
Item (optional | multiple)
This element defines a media file. One or more
<podcast:source>
tags must be contained within this element to list available methods to obtain the file. This is meant to provide different versions of a media file -- such as low or high bitrate, alternate formats (different codecs or video), alternate URI schemes (IPFS or live streaming), or alternate download types not indicated by the URI and type (like torrents).The "rel" attribute is meant to allow presentation of media different from the main content given in the enclosure. For example, "director's cut" or "behind the scenes". If you are only offering one media content (say, a podcast in MP3, AAC, Opus, over HTTPS and IPFS), you can likely ignore the "rel" attribute.
The media element always refers to an available media version. The standard RSS enclosure element is always the default media to be played.
An
<enclosure>
tag must be present along with this tag within the item.type
(required) Mime type of the media asset.length
(required) Length of the file in bytes.bitrate
(optional) Encoding bitrate of media asset.height
(optional) Height of the media asset for video formatslang
(optional) An IETF language tag (BCP 47) code identifying the language of this media.rel
(optional) Provides a method of offering and/or grouping together different media elements. If not set, or set to "default", the media will be grouped with the enclosure and assumed to be an alternative to the enclosure's encoding/transport. This attribute can and should be the same for items with the same content encoded by different means. Should be limited to 32 characters for UX.codecs
(optional) A RFC 6381 string specifying the codecs available in this media.default
(optional) Boolean specifying whether or not the given media is the same as the file from the enclosure element and should be the preferred media element. The primary reason to set this is to offer alternative transports for the enclosure. If not set, this should be assumed to be false.<podcast:source uri="[uri of media asset]" contentType="[mime type]" />
podcast:alternateEnclosure (required | multiple)
This element defines available transport methods to obtain media, such as HTTP, HTTPS, IPFS, Tor, magnet, etc, via alternate URI schemes and content types if the
<podcast:alternateEnclosure>
content type does not suffice, such as torrent or stream files.There should be one or more source elements in a media tag.
uri
(required) This a an IANA-registered URI for the media asset.contentType
(optional) Mime type of the data retrieved from the URI, if different from the media's "type"<podcast:integrity type="[integrity type]" value="[integrity value]" />
podcast:alternateEnclosure (optional | multiple)
This element defines a method of verifying integrity the media given either an SRI-compliant integrity string or a base64 encoded PGP signature.
There may be one or more integrity elements in a media tag.
type
(required) Type of integrity, either "sri" or "pgp-signature".value
(required) Value of the sri string or base64 encoded pgp signature.Example of content served via audio in mp3, high-bitrate Opus, "hi-fi" AAC, low-bitrate Opus -- over both HTTPS and IPFS:
Example of content served via audio (mp3) and video in different resolutions (mp4) with dynamic streaming options:
Example use of the "rel" attribute offering "Behind the Scenes" content:
The text was updated successfully, but these errors were encountered: