Podlove Deep Linking is a method for describing direct access to audio or video content in Podcast Feeds. It is a very simple extension to a feed that tells a podcast client how to link back to a certain point in time on the podcast’s web site.
The same addressing scheme can also be used by web-based media players to construct links to specific points or ranges in the media, either by generating URLs for users to pass on or to be updated in the URL field of the browser.
Change Log
2012-05-07: 1.1 - Significantly changed spec to be a
subset of Media Fragments URI
2012-05-07: 1.0 - Initial Release
Motivation and Scope
There is usually a huge disconnect between podcast clients playing back content and the content creators presence on the web. Listeners may want to refer to certain parts of a show to either “bookmark” something or share it with other people on the web. This is be done by giving away a simple link that people can use to directly access that particular content.
In order to allow websites to directly react to those links, the website must communicate which URL to use to link to content to the podcast client. It does this by providing a simple base URL that the podcast client can extend to include the bookmarked point in time. The website can then extract the time information from that URL and pass it along to a web player that can start playback at the exact time given.
Media Fragments URIs
This specification relates to the Media Fragments URI 1.0 recommendation of the W3C [1] but clients must only use the temporal fragment dimension and the normal play time (npt) syntax to reference points in time or time ranges. Web Players conforming to this specification do not need to support additional fragment dimensions or time notations.
Including Player Information in a Podcast Feed
In order to provide playback URL information in your podcast feed, you have to put in an extra element <atom:link>
in each of your episode entries.
This element’s ref attribute needs to be set to the URI value https://podlove.org/deep-link/
to denote the proper and Atom-compliant meaning to the podcast client.
The href
attribute then specifies the base URL to be appended with time range information. Please replace the example given here with whatever your podcast publication platform requires.
Please understand that this link is just a base URL that needs to be extended with proper time range information by the client. The link alone does merely communicate to the client that the web page in question is actually able to accept media fragment URIs.
Example
This is how that element would show up in an Atom podcast feed:
<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
...
<entry>
<link href="http://mypodcast.com/episode/index.html" />
<link rel="http://podlove.org/deep-link" href="http://mypodcast.com/episode/player.php?episode=23#" />
...
</entry>
...
</feed>
This is how it would look like in an RSS 2.0 podcast feed:
<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
...
<item>
<link>http://mypodcast.com/episode/index.html</link>
<atom:link rel="http://podlove.org/deep-link" href="http://mypodcast.com/episode/player.php?episode=23#" />
...
</item>
...
</rss>
Appending Time Range Information
The podcast client appends the time range selected by the user. The podcast specifies the selected range in the “normal play time” syntax of the Media Fragment specification.
t=[npt:][start][,end]
If you omit the start time, it defaults to the beginning of the media file, if you omit end it defaults to the end of the media file.
Here are some examples that show how the time field can be used:
t=1:35:52,1:42:16
- play from 01:35:52 to 01:42:16
t=263
- start playback at 4 minutes and 23 seconds
t=,24:12
- play from beginning to 24 minutes and 12 seconds
For more examples and a full specification of the Normal Play Time syntax, consult the Media Fragments [1] specification.
Additional Fragment Parameters
The Media Fragments [1]specification requires the media fragment specifier to be a parameter following a hash sign (“#”) and allows for additional parameters to be passed along. As the podcast client is expected to add just the time range information, any additional parameters that your web player might need must be included in the URL stated in the feed following the fragment identifier.
The Podcast Client MUST honor existing parameters and append the time specification with an ampersand sign (“&”) if a parameter already exists. The following URL
http://mypodcast.com/episode/player.php?episode=23#style=external
must be extended as described to look something like this:
http://mypodcast.com/episode/player.php?episode=23#style=external&t=10,200
Right now, this specification does not define any other parameters but might in do so in a future version.
Website Player Behavior
Once the deep link information has been placed in the podcast feed, the website referenced SHOULD be ready to play back the media content directly. The website player SHOULD start playing at the given start time and SHOULD pause playback after the optionally given end time is reached for the first time.
It is up to the player to decide if playback should be immediate after loading the URL or if the user still needs to explicitly start playback using UI controls.
- Media Fragments URI 1.0 http://www.w3.org/TR/media-frags/ ↩
I have a little annotation:
Your example “37 seconds” should not be “37 – 37 seconds” but should be “0:37 – 37 seconds”, because only hours and milliseconds are optional, but not minutes (at least according to the text above).
Shouldn’t the 37 seconds example be 00:37 since minutes aren’t optional?
You are right. Fixed.
Why is the time limited to 23 hours? Ok, it is very unlikely that you want to link into an audio file at 31:22:17.554, but why this (artificial) limit?
Good question. I haven’t considered files being longer than a day. Do you think this matters?
No, I’m just wondering. An ending of time feels odd.
http://www.worldrecordsacademy.org/society/longest_speech-world_record_set_by_Llouis_Colet_90132.htm ;-)
The Media Fragments URI specification might be worth a look: http://www.w3.org/TR/media-frags/
Thanks for the pointer. I wonder whether W3C choosed a comma as separator instead of hyphen to make time ranges less natural to read for human beings: http://www.w3.org/TR/media-frags/#naming-time Anyway: podlove time-range information should be a simple subset of W3C temporal media fragment when you replace ‘-‘ with ‘,’.
We are actually currently considering changing the spec to use the W3C media fragment specification. The spec is rather new and we were not aware of it when we specified this.
Thanks for the specification effort! The current description, however, could be improved by adding an actual example. The ATOM and RSS snippets above do not contain any deep link. Below it is said that “the podcast client appends the time range selected by the user”. It is not obvious where actually the time range is appended. A full example would help to show which URLs are given, constructed, and accessed how.
The examples do include a deep link. But we should make the example more descriptive.
The terminology should be more strict. As I understand, “http://mypodcast.com/episode/player.php?t=” is not a deep link but a deep link base URL. “http://mypodcast.com/episode/player.php?t=00:23:12-00:25:04” is an example of a deep link.
Hi,
maybe you should take a look at RFC 6570 – URI Template (http://tools.ietf.org/html/rfc6570)
I am not sure if an URI Template itself are valid URIs as required by ATOM link href attribute, but I think would fit 100% to this case, an feels a little more polished than an URI fraction as actual href content, but it ofc adds complexity… But at least one should take this stuff into consideration.
Instead of appending your variable to the URI fraction in the href attribute, an URI Template allows to specify variables in your URI.
Example:
This would translate to http://mypodcast.com/episode/player.html?start=%5BHH:%5DMM:SS%5B.mmm%5D&end=%5B%5BHH:%5DMM:SS%5B.mmm%5D%5D
Wie wäre es mit dem Einbau der Amazon wispersync zugrundeliegenden Technologie?
Dann könnte man wörtlich durchsuchbare Podcasts machen… Wie funktioniert dieses wispersync eigentlich?
Gruß Michael
Pingback: Auphonic Blog: Chapter Marks for MP3, MP4 Audio and Vorbis Comment (Enhanced Podcasts)
Thanks for explaining the Deep Linking method. I am a beginner, more or less, and just started my own podcast. I was searching for a solution like this because my concept is based on the possibility to bookmark certain parts of the podcast. Thereby I intend to make my podcast more interactive. And furthermore I can gain some informations about how the consumers react to certain parts, which part they like, which not, etc. Well, I’ll see if it will work out…