Difference between revisions of "Parcel media"

From Second Life Wiki
Jump to navigation Jump to search
Line 1: Line 1:
[[Category: Linden Lab Projects]]
='''Media On A Parcel'''=
='''Media On A Parcel'''=
==Overview==
==Overview==

Revision as of 16:06, 31 March 2008

Media On A Parcel

Overview

This document has been rewritten to focus on higher level design details. More specific implementation details are available upon request.

The purpose of this project is to shore up and expand support for Media within Second Life. Currently we support a single Quicktime URL per parcel, which is used in place of a given texture. We plan to rewrite the underlying Media Library and expand it to support a wide variety of Internet Media types, such as HTML and Flash. Also we will support Media display in other areas of Second Life, such as the HUD and on individual Prims.

The Project will deploy in several milestones. The first of these will deliver the underlying re-architecture of the Media Library and support for HTML on a parcel. Subsequent milestones will provide for Media in the HUD, multiple URLs per parcel, and implement new Media Type support.


Project Justification

Problems We Are Solving

  • The current system will scale poorly given our long-term goal of a media-rich environment.
  • The media type to media decoder associations are hard coded.
  • The system is dependent on the Viewer, which contributes to viewer complexity and hampers viewer abstraction initiatives.
  • It's currently only possible to have one media URL per parcel even if your system can support more.
  • Current location of embedded browser (hosted in client UI code via LLWebBrowserCtrl) cannot be used as a media source. A better approach is to move the implementation to the media library and replace the "Web Browser Control" widget with a more generalized "Media Widget".
  • Current implementation is strongly coupled to parcel concept. Long term goals require more flexible support so that media can be used anywhere in client - for example, the HUD.

Pros

  • Rewriting and documenting the Media Library API will allow for easier integration of new media types, which hopefully will involve our open source community.
  • Extricating the media library from the Viewer as much as possible will decrease Viewer complexity and hopefully contribute to greater Viewer stability long term. Debugging the Media Library will be easier as well.
  • Creating a data-driven media association path will remove the compile requirements for changing media type to impl associations.

Cons

  • Any change to this code has the potential to introduce bugs and break functionality.
  • This project does conceive of new features, and therefore is not purely a refactoring of existing code.
  • While media support on a parcel does address long-term goals, it is less relevant to near-term stability and new-user experience initiatives.


Requirements

The new system will:

  • Support a wider variety of media types.
  • Provide a plug-in like architecture for adding new media type support.
  • Allow residents to specify more than one URL per parcel.
  • Allow the viewer to display URLs in HUD and on prims
  • Support a shared interaction experience


Design

  • The Media Library will use common MIME types and URL Scheme to map URLs to specific decoders in the Library.
  • These will all be part of the SL Viewer Open Source project.


Media Setup

  • The parcel owner will initially set the URL in the About Land dialog, and will add information such as Type and Media Size if applicable.
  • They also specify the ID of the Texture to replace with this URL.
  • This information is stored on the server side with the rest of the Parcel information.
  • If the parcel owner is unsure of the media type a lookup can be done of the URL header.
AboutLandMedia.png


Playing Media

  • When a resident enters a parcel which has a media URL defined, an appropriate UI control pops up allowing the resident to load the media.
  • When the resident invokes the media control the Media Library begins decoding the media based on the MIME type for the media.
  • Frames will appear on any face displaying the texture ID specified in the Media Setup.
  • Milestone 2 will also add support for displaying media in the HUD, so rather than being drawn in world, the media would appear on a UI widget displayed in the HUD.

Supported Media Types

  • Implemented in Milestone 1
    • QuickTime (refactor existing one and make sure we're using the latest version of the QuickTime SDK)
    • Mozilla (Will use existing version that's in the client - updating that is another project)
  • Implemented in Milestone 2
    • Opera (Alternative impl for handling Web based content - based on Opera browser 9.5)
    • Flash


Use cases

Please feel free to add any use cases which are not already covered. We want to make this system address Resident needs as much as possible.

  • Parcel owner wants to use a number of web hosted sounds to form a parcel wide soundtrack which doesnt rely on inworld uploaded sounds
  • Parcel owner wants to display some static signage on his parcel
    • This can be done but the visitor will have to hit 'start' before they see it.
  • Parcel owner wants to display dynamic content on his parcel - e.g. Twitter stream
    • (once visitor presses 'start', this will work as expected)
    • This can be done with live RSS-XML parsing on a script in a multi-prim object containing high-quality textures, sounds, and appropriate XyText font. For example, XyText-powered media information screens for internet radio feeds. -Smiley B. .
  • Parcel owner puts a Web page containing a slide show that has transport controls built into the Web page
    • This works but each parcel visitor will see the slide show independently. If one user presses 'NEXT SLIDE' control, no one else will see it.
  • Parcel owner puts a Web page containing a slide show that has transport controls via a scripted object on the parcel
    • Each parcel visitor will see the same URL
  • Parcel owner puts a Web page containing a slide show that has transport controls via a scripted object on the parcel and wants to disallow visitors changing the URL
    • [My lack of knowledge of LSL here means I can't answer this but I think it should be possible to only allow the transport control object (and therefore the URL) to be used by the parcel owner]
  • Parcel owner puts a Web page containing a Flash game on his parcel
    • The current version of LLMozLib doesn't support Flash interaction so this won't work.
  • Parcel owner puts a Web page containing a Javascript game on his parcel
    • This milestone doesn't support interaction with parcel media so this won't work
  • Parcel owner wants to hide content behind a username/password set via .htaccess
    • Won't work since we don't support username/password dialog - will have to implement using Web content
  • Parcel owner wants a movie screen and a Web page with movie details on the same parcel.
    • Works - raises some interesting questions about transport controls that appear at the bottom of the screen
  • Parcel owner wants to hand out personal, attachable media viewers for visitors to interact with their own chosen media streams: museum guide, lecture, mall
  • User has a personal device which they want permission to set their own media texture for even when on a parcel which they do not have permission for - aka personalized radio, video viewer that works globally
  • Parcel owner wants to leave a Web browser on their parcel so that visitors can browser
    • Works as expected
  • Parcel owner wants to create a controlled shared experience - viewing a sequence of images with next/previous links in the page itself
    • Works as expected
  • Parcel owner wants to join his fellow 'parcelees' and browse the Internet together
    • Will work depending on the content but any page that is generated dynamically based on time, cookies etc. will most likely not work as expected.
  • Parcel owner runs a class discussing literature/essays/work. Wants to distribute notecard with content AND discuss from a screen, possibly with editing and notes done pseudo live.
    • Will need to be able to read more than 255 characters per line from dataserver/llGetNotecardLine. Formatting instructions
  • Parcel owner wishes to run a class where students complete a standard form and have their material visibly displayed.
  • Parcel owner runs scripting class and would like to be able to display, share and edit scripts live! (not currently even on the map), save possibly by cutting and pasting to a notecard.
  • AJAX specialist creates an interactive product (like the iPhone) with interactive features.

Also: some ideas here: http://wiki.secondlife.com/wiki/User:Zero_Linden/Office_Hours/HTML_on_a_Prim_Use_Cases