| Close |
| Comment |
Executive Overview
Technical Overview
Components
System Requirements
Installation
Adding Content
Adding Images
Publishing Pages
About ATVEF Triggers
Supporting Additional Devices
Supporting Accessible Devices
Additional Resources
Copyright Information
The Interactive Television Publishing System (ITPS), originally developed to provide enhancements for the WGBH/PBS series Antiques Roadshow, offers a simple way to produce ETV features.
At the heart of the system is a database that separates form (in this case, device-specific markup code) from content (in this case, text and images appropriate to show segments). Serving a new device is simply a matter of preparing a new template that uses that device's dialect of markup language. Content and images can be added to the database without any knowledge of HTML nor any concern for what devices will receive it.
The system was designed with ATVEF A capable receiver devices in mind, but any device that renders some kind of markup language could be supported without re-engineering the code base.
Database content is published to HTML via Perl using device-specific modules. A handful of additional static HTML pages, such as the search form, make up the remainder of the code required to support a particular client device. Devices are routed to appropriate pages via a "sniffer" page currently implemented using the XSSI syntax available in Apache 1.3 or higher. The content database may be searched dynamically by end users via Perl CGI. Devices are directed to the content via ATVEF A triggers embedded in a television signal.
As distributed, WebTV and AOLTV are supported, as well as arbitrary devices other than these that are truly compliant with the ATVEF 1.1r26 transport A specification.
The system consists of
Unpack the distribution archive.
Move the contents of the "htdocs" directory to (a subdirectory of) your web server's document root. Make sure your web server has server-parsing (SSI) enabled for this directory. Also, check to make sure "sblurbs" is a symlink (a.k.a. alias, shortcut) to the neighboring "blurbs" directory.
Move the contents of the "cgi-bin" directory to (a subdirectory of) your web server's executable directory.
In your RDBMS, create a new database and user for this application.
Initialize the database using init.sql, e.g.:
mysql -u <db_user> -p <db> < init.sql
where <db_user> and <db> are the new user and database you just created.
If you like, seed the database with sample content to see how the pieces fit together:
mysql -u <db_user> -p <db> < content.sql
In cgi-bin/ITPS.pm, configure your local settings.
Update the FORM ACTION in htdocs/*/search.html to point to cgi-bin/search.cgi.
Add your content (see Adding Content below).
Publish pages (see Publishing Pages below).
Test.
Use a closed caption encoder with the timecode/trigger data generated
during the publish process.
Broadcast the triggers with the related video content and monitor server
load.
Content comes in two forms: textual "blurbs" related to specific video segments and images related to those blurbs. Up to three blurbs can be associated with each video segment. Blurb text is stored directly in the database while images are merely described (including file format, dimensions, ALT text, and relative URL).
Blurbs will belong to one of three categories: "as", "tip", or "bio" (relating to the Antiques Roadshow features Antique Speak, Tips of the Trade, or Appraiser Bio). At most one of each of these will be available per video segment. To add a blurb to the database, first make the appropriate entry into the table named "blurb". "short_text" is intended for display on a television display; "long_text" is intended for display on a computer or handheld.
There is no limit to how many images can be associated with each blurb (although only one image per screenful will be shown, so the number of images the end user will see depends on how many screenfuls are required to display the entire blurb).
The association between blurbs and related images is abstracted in several ways:
The first reason for this is device compatibility. Each type of device might support different image codecs (GIF, PNG, JPEG, etc.) or prefer certain sizes (TV display vs. hand-held) or colors (RGB, NTSC, grayscale). This is handled via the image_format table and the image_format_nick setting in the device-specific Perl modules. In a future iteration, each device, blurb, and image_group (described below) will have its own list of preferred image_format's from which one can be chosen. In this implementation, since all target devices supported 125x125 full-color JPEGs, that is the only image_format in use.
The second reason for this is to enable a group of images to be associated with a single blurb. When a blurb is long enough to require several screens, images are pulled from this group in order as needed. This grouping is handled via image_group table and image_group_id's.
When determining which image is needed next, the page stamper looks to the image_lookup table. Given an image_format and an image_group_id, the image_lookup table will provide a list of appropriate images ordered via the sort_order column.
The final reason for this abstraction is to keep images themselves out of the database. Only image metadata such as size, format, and relative URL are stored. The image files themselves are regular, flat, web-ready files.
To make images for a given blurb:
* Identify which image_format(s) are required for these images
* Generate copies of the images in these target formats
* Enter metadata for each image in the image table
* Create a new image_group entry for the new group
* For each image, add an entry to image_lookup including sort order
* Update the blurb table to associate the blurb with the new image_group
Run cgi-bin/publish_all.pl. This will iterate over every episode, every segment, every device, and every blurb, generating device-appropriate pages for everything it finds. You needn't run this on your web server; just make sure the &db_connect_stamp method in ITPS.pm is configured properly then upload all the newly-generated files.
Each segment includes up to three ATVEF triggers. One to load the segment-specific data, one to warn the user they're about to learn the appraised value of the on-air item, and one to reveal that appraised value to the user. (the latter two only act if the user has entered values in the Appraise It Yourself feature.) Trigger data is generated by publish_all.pl and stored in "
The process of writing these triggers to videotape is beyond the scope of this document. If you have closed caption hardware and software, it's probably up to the task.
First, find out what you can about the dialect of whatever markup language the device supports. Implement some test pages and refine them. Port these files from an existing device to the new markup dialect:
* index.html
* search.html
* default*.html
* aiy*.html
* tv.html
Duplicate ITPS/default.pm to a file named appropriately for the new device. Adjust the HTML it outputs (blurb pages, nav menu pages, search result pages) appropriately. Republish the site. Test. Repeat.
Supporting Accessibile Devices
Although the current generation of ATVEF-capable devices has done a poor job making content available to those with sensory disabilities, the ITPS system provides hooks for future devices. Every image in the database has a field for a text alternate that can be used either by accessibility-aware devices to serve vision-impared users or for non-graphical rendering of interactive presentations.
To take advantage of this capability, make sure all images in the database have appropriate text in the alt_text field. At least for devices capable of using alt text, make sure each device's static template pages and stamper module contain ALT attributes for every IMG tag. Within the stamper module, alt_text for database-retrieved images can be accessed via the $img_ref->{'alt_text'} variable.
Additional information on this application and interactive television in general can be found online at www.etvcookbook.org.
© 2003, WGBH Educational Foundation and the Local Enhancement Collaborative
Application source code is licensed under the GPL (see "COPYRIGHT.GPL").
Example database content and images are © 2003, WGBH Educational Foundation and are for demonstration purposes only. Distribution in any form is strictly prohibited.
Return to Source Code page.
Revised Wednesday, 28-May-2003 07:53:50 CDT - h -
© 2000 - 2003 Local Enhancement Collaborative &
-
Please Comment