Loading...
 
Development

Development


Proposed changes to support media casting

posts: 38 United States

Proposed changes to support media casting:

We'd like to do podcasts from Tiki. Actually, we'd like to support media casts of all kinds. Currently we can take the RSS output from File Galleries and run it through FeedBurner, which converts the feed to something podcast compatible, but that seems silly. Why not update the RSS feed so it has all the information needed to support a podcast directly?

Current Tiki RSS feeds include the following information for each "item": title, link, description (text), author (email), and publication date. Podcasts need a number of pieces of information not included in the current RSS feed, including media type, duration, bit rate, frame rate, etc. This data is not currently captured when files are uploaded to a gallery, for example, but it could be. Manually recording it would be a nuisance, but that shouldn't be necessary.

The solution I propose involves using getid3.php (currently used in the MFolder plugin), which extracts all the required information directly from the file (I THINK — I'm not sure about frame rate). This file currently isn't part of the default installation, and may slow down file processing on upload or something. In the spirit of the 3 Rules, either media casting needs to be an option on the existing file gallery feature, or a separate feature called Media Cast needs to be created. I'm not sure which is preferred from a Tiki development point of view. I suggest the latter, but re-use the existing code as much as possible. Alternatively, the getid3 package could be included in the installation process and all the file_gallery stuff could be updated to support the required number of fields for length and filetype data, etc. That would probably be cleaner, but I'm not familiar enough with the existing code to be sure I've caught all the changes that would have to be made not to break file galleries completely.

Documentation of what needs to be done for full iTunes compatibility is here: http://phobos.apple.com/static/iTunesRSS.html. I also took a look at other existing services, e.g. FeedBurner, to see what they provide in their XML feeds. FeedBurner not only provides the "enclosure" tags required by Apple but also provides "media" tags presumably used by other services. It seems trivial to support both. There are also some iTunes specific tags to be supported both at the channel and item level. The only other bit of effort that would be required is to support the iTunes category lists.

Here's what I think would need to be done (but I'm new to Tiki development and to PHP, for that matter, so I'd like a sanity check on this):

Create the following:
tiki-Mediacasts.php (similar to tiki-file_galleries.php)
tiki-MediaCast_rss.php (similar to tiki-file_gallery_rss.php, subscribes to one MediaCast)
tiki-Mediacasts_rss.php (similar to tiki-file_galleries_rss.php, subscribes to all MediaCasts on this Tiki)
lib/mediacastlib.php (from lib/filegallib.php, but uses getid3 code in the insert_media() function, similar to insert_file() function)
table tiki_MediaCasts (similar to tiki_files, but more fields)

Edit:
lib/tikilib.php
- add the following functions:
get_media() - similar to get_files()
add_MediaCast() - similar to add_file_gallery()
get_MediaCast() - similar to get_file_gallery()
list_MediaCasts() - similar to list_galleries()
list_visible_MediaCasts() - similar to list_visible_file_galleries()

The main difference in all of these is the number of fields used to describe the file, with the extra data being extracted on the initial upload using getid3.

- edit the following functions:
list_sections() - add MediaCasts to the list
get_event_watches() - add MediaCasts to the handling list

Edit:
lib/rsslib.php
Add function:
generate_media_feed - similar to generate_feed, but more XML fields to support the podcast/media cast requirements.

A new table, tiki_MediaCasts, needs to be created. This table has more fields than tiki_files. The setting to decide whether to use the db to store files or not probably ought to be included, but media files are typically so big, use of a directory is much more likely.

Again, the other alternative is to edit the above files and functions rather than creating new ones, and alter the existing tiki_files table. Would that be preferable from a Tiki development point of view? Can someone give me a sense of whether I've found all the places that would need to be changed?

Thanks,

e.dalton

posts: 119 Germany

I think making it an extension/option to Blogs would be much more natural - don't you think?

Didn't know though, that it's that much work - I thought, that you just provide a link in your blog.


posts: 38 United States

Thanks for the response. biggrin

A link in the blog doesn't create the necessary "enclosure" tags in the RSS feed for a podcast reader to treat it like a podcast. I can look at the blog code and see if it would be easy to add there. I agree that it would make more sense from a usability perspective. The functionality seemed to be more similar to existing file gallery functionality in some ways, but users would probably look for it in blogs, not file galleries.

e.dalton


posts: 9304 Germany

I've added a new RSS type now, that gives itunes podcast 1.0 output. use ?ver=pc1.0 to get the result, works on a file gallery. Check the output of http://tikiwiki.org/tiki-file_galleries_rss.php?ver=pc1.0

I'm trying to add a special type of file gallery right now, podcast (audio) and podcast (video).

What I hope to have later: file galleries that automatically give you podcast rdf if you click the RSS icon and a link you get after a file upload that's name like "Blog this!" or something, which lets you choose a blog you can comment the new gallery entry.

Is this the way it works? Or is the blog needed if the file gallery delivers the correct rss data already?


Upcoming Events

No records to display

Why Register?

Register at tiki.org and you'll be able to use the account at any *.tiki.org site, thanks to the InterTiki feature. A valid email address is required to receive site notifications and occasional newsletters. You can opt out of these items at any time.