From Habari Project
Podcasting Working Group
The Podcasting WG is responsible for implementing robust and usable podcasting support for Habari. Support should be implemented through a plugin. Aspects that this WG will cover include podcasting workflow, and a UI to support this, writing enclosure data to Atom and RSS feeds, and storage of the enclosure data associated with a podcast post. More background and context can be found at #9 on trac.
It has been a goal for the 0.5 release of Habari (to be prior to or coincide with our sponsorship of PodCamp Ohio) to supply podcasting support to its users.
It is the proposal of this working group to produce two deliverable items:
- A plugin suitable for Habari that will:
- Allow users to configure a feed for serving podcasts
- Allow users to easily add media to posts for serving via a podcast feed
- A theme-side flash player that:
- Complies with the ASL
- Is more usable/elegant than the standard player seen on the web
In addition, some augmentation in the core may be required to address some issues with attaching media to the podcast plugin's fields.
Multiple Formats - Multiple Feeds
The podcast plugin will be required to output multiple feeds so that a user can attach many filetype versions of the same media content to a single post.
For example, imagine that a user wants to create a video podcast, and wants it to be available for both iPod/iTunes and Zune. Each of these devices requires a different media format for playback. As a result, each new podcast post will need to have two separate files attached; one for iPod, and one for Zune.
Unfortunately, the RSS spec forbids the inclusion of multiple enclosures for a single post item. To circumvent this issue, the podcast plugin will need to produce separate feeds, one for each playback destination. iPod users will subscribe to the feed with iPod-compatible video enclosures, and Zune users will subscribe to the feed with Zune-compatible video enclosures. Each device will receive the correct format.
Using this method, the author could even configure separate feeds for SD and HD content, or free versus paid content.
While the plugin will produce multiple feeds, each feed will still use the same post title and content for each item's values in the feeds. Only the file used for the enclosure is different in terms of the data used from each post for its corresponding feed item. So when publishing a video post, the author would create a single podcast post, but would attach multiple videos to that single post. The plugin would transparently "duplicate" the content to separate feeds.
It might also be useful to allow certain posts to appear only in certain feeds, such as if an author offers paid content that should not be available via the free feeds.
The feed formats themselves might need to be slightly different to accommodate specific devices or services. More research is required to determine if this is necessary.
The configuration of each feed should determine its output format, the standard description, author, URL, cover art, etc. This configuration could also determine whether that feed receives the standard entries as part of its output.
Each feed will have the following configuration settings for use in output:
- Feed Title: will be fetched from database (same as site title); displayed in config and defaults to site title
- Feed Subtitle: will be fetched from database (same as site tagline); displayed in config and defaults to site tagline
- Feed Filter: a search string which will filter which posts appear in feed; displayed in config and defaults to "type:podcast"
- Feed Type: the type of feed (iTunes, Zune, etc.); displayed in config from dropdown of available types
- Feed Author: Feed author will be a used in Habari which is selectable in feed conig
- Feed Summary: Summary of feed, settable in config
- Feed Image: Coverart for feed, settable in config
- Feed Category or Cateogires: Categories for feed, settable in config
Media Browser Integration
Currently, the media browser only integrates its output with the main content area of a post. To make this more useful for podcasts, this feature should be extended so that it's possible to select an asset from the media browser to insert into any of the available enclosure slots for a post.
Users of podcasting software expect to be able to play back their podcasts on their sites. We should produce some kind of script that can detect the best way to play back media for that user, including using a flash media player that the plugin will provide.
A suggestion of what would the player look like is shown in Figure 1 (A slightly different design is shown in Figure 2). The player has 3 main controls: the play/pause button, the slider area and the volume control. There is an additional button to show/hide the episode’s bookmarks list, which is only shown if such list is defined for that episode. All the colors of these controls (and most of the other player areas) should be configurable; this can be achieved by passing a set of parameters to the flash player object when embedding it in html. Some of the other aspects of the player, for example the width of the player, should also be configurable.
The IDv3 Lyrics tag can be used to store the bookmark list for each episode. The user would need to set this manually in his favorite player or any other tag editor. It can be accessed by the player just like any other IDv3 tag (title, album..etc). The list format would be straight forward and in the same time not easily mixed with other content the Lyrics tag may contain (Notes, Transcripts..etc). Each bookmark entry would have a format similar to:
hh:mm:ss Bookmark title Optional bookmark description here...
The player can read the Lyrics tag, parse it for any bookmarks and add them to the slider area as ticks as well as to the bookmark list. Storing the episodes bookmarks within the MP3 file Lyrics tag has the advantage of being accessible to other players that display the standard Lyrics tag (Winamp, iTunes, iPhone..etc).
The slider area itself consists of 3 controls: the buffering bar (shown in green) indicates how much of the media file have been buffered locally. The seekbar (in dark grey) indicates the current playback position, this position be changed by clicking anywhere in the buffered area of the slider, if a non-buffered area is clicked, the seekbar should be reset to the end of the buffered area. The slider area would also show the start time for each of the episode's bookmark entry (Dots in blue). Hovering on any of those dots would display a popup that displays the Title and the Description (if set). See Fig 3. If the episode has a Bookmarks list, the show/hide bookmarks control would be displayed by the player and when clicked, it would slide down a small box that contains a list of the ‘Titles’ of all entries with a link for the seekbar to jump directly to that part of the episode. See Fig 4.
The display area right above the slider (in grey) will display the current duration of the episode, and It's title, the title can passed to the player when embedding it or can be left to the player to display what it finds in the media file's title tag.
A smaller, minimized version of the player can also be suggested in case some users prefer a player that takes less space.