Middlebury

Difference between revisions of "MiddTube"

(Potential Server-Side Solutions)
(This project is now nearing completion as MiddMedia. Redirecting to the MiddMedia documentation page.)
 
(17 intermediate revisions by 4 users not shown)
Line 1: Line 1:
[[Category:Initiatives]]
+
#REDIRECT [[MiddMedia]]
[[Category:Projects]]
 
[[Category:Internals]]
 
[[Category:web2.0]]
 
=Description=
 
Using the Flash Media Server as the media manager, we will build a front-end interface to help users manage their own media, implementing a self-service model.  Faculty, staff and students can create video on their preferred platform, save a rendered file in a platform-specific format, then upload their media through the Flash Media Encoder, which will convert standard formats to FlashVideo (.flv)*, allowing anyone with the Flash Player to view.  Uploading the video can involve compression, reducing the storage space needed to host the media.
 
 
 
<nowiki>*</nowiki> H264 video may be used once we have a new version of Flash Media Server that supports it.
 
 
 
=Required Features=
 
*Users defined by LDAP/AD
 
**Frontend application needs to be organized by user
 
*Users upload video/audio
 
*Users manage their video/audio
 
*Generate embed code
 
*Default and custom limits on size of upload and storage
 
*Granular permissions, allowing restrictions on who can see which videos a user owns, as defined by AD.
 
**Public
 
**Middlebury only
 
**Private
 
*if closed source code, then needs API for at least uploading media files
 
 
 
=Desired Features=
 
*Playlists or favorites
 
*Users record video/audio in browser, right into their library.
 
*RSS feeds of users' channel/playlist
 
*Granular permissions, allowing restrictions on who can see which videos a user owns, as defined by AD and/or secondary authentication.
 
 
 
=Nice To Have=
 
*Permissions for other Middlebury users:
 
**Class
 
**Other AD groups
 
**Guest accounts
 
*tagging
 
*voting
 
*folders/groupings/channels of video/audio allowing media created by multiple users to be grouped together.
 
*Embed a playlist into a viewer
 
*Support for multiple viewers with different feature-sets.
 
*Comments on videos
 
 
 
 
 
=Potential Client-Side Solutions=
 
==[http://flowplayer.org/ FlowPlayer]==
 
Easy to use, open source flash video player with room for customization.  Embed code is generated by the Flash player, and native support for playlists and chapters.  This player is in use by [http://www.abroadview.org AbroadView].
 
 
 
 
 
=Potential Server-Side Solutions=
 
==[http://www.getmiro.com/create/broadcast/ Broadcast Machine]==
 
[http://www.getmiro.com/create/broadcast/ Broadcast Machine] is a video-blogging platform created by the Participatory Culture Foundation. It sounds like it would be very similar to what we are looking for for MiddTube:
 
 
 
<blockquote>3. Run a Community Site<br/>
 
 
 
Want to get everyone involved? Broadcast Machine has a simple user management system that lets you accept submissions of videos and video links from visitors to your site (you can require them to register first, if you choose to). This means you can create a channel for a community: let anyone post to an "open" channel and then pick the best stuff to include in more selective channels-- "Featured Videos", perhaps. Perfect for communities and organizations of every kind.</blockquote>
 
 
 
Unfortunately it is no longer under development. They are awaiting funding for a redesign.
 
 
 
 
 
==Drupal==
 
 
 
 
 
==In-House Development==
 
Advantages:
 
*Easy integration with other campus systems.
 
*Code would be a known commodity, written to our standards and security practices.
 
*Minimal configuration difficulty once written.
 
*Access control of videos could follow practices already used in our existing systems.
 
Negatives:
 
*Need to fit the project into already busy schedules.
 
 
 
Several possible tracks...
 
 
 
===Segue Component===
 
"MiddTube" could be composed of as several screens within the Segue UI, for instance linked off the user's portal page.
 
 
 
* Possibly a little easier to do a staged roll-out with only the barest functionality first.
 
* Could tightly couple with Segue UI if desired, for very rich integration.
 
 
 
===Stand-Alone Application===
 
Would be built similarly to a Segue component (Harmoni-based), but would have its own branding and url.
 
 
 
* Separate branding from Segue.
 
* Could be developed on a different schedule from segue.
 
* Could run on separate servers.
 
* Looser/standards-based coupling with Segue.
 

Latest revision as of 12:51, 2 February 2009

Redirect to:

Powered by MediaWiki