Be Newsletter

Volume II, Issue 5; February 4, 1998

Table of Contents

• SD '98 in San Francisco; Be Developer Conference, Santa Clara
• BE ENGINEERING INSIGHTS: Video Basics 2, By Steve Sakoman
• BE ENGINEERING INSIGHTS: Using the Be IDE with RCS, By Ming Low
• DEVELOPERS' WORKSHOP: Fiddling with Tracker Add-ons, By Voctor Tsou
• Appliances at Demo '98, By Jean-Louis Gassée

Upcoming Be Events

SD'98 (SoftWare Development Conference)
Monday, February 9 to Friday February 13

• Where: Moscone Convention Center
  North Hall -- Booth #454
  San Francisco, California

• Info: http://www.sd98.com/

Be Developer Conference
Thursday, March 19 to Friday March 20

• Where: Westin Hotel
  Santa Clara Convention Center
  Santa Clara, California

• Info: http://www.be.com/developers/BeDC_info.html

All software developers are welcome to join us for two days of in-depth technical presentations, demonstrations, and discussion by the Be team.

BE ENGINEERING INSIGHTS: Video Basics 2

By Steve Sakoman

The human eye seems irresistibly drawn to moving images. Consequently, every last scrap of system performance is inevitably drawn into the pursuit of ever more appealing "eye-candy." This has made digital video the black hole of computer applications -- the application that absorbs each new generation of technology and still is not sated.

The upcoming release of BeOS for Intel opens the doors to some mouth-watering (or should I say eye-watering?) technologies. The performance of 300+ MHz Pentium II MMX processors is nothing short of astounding, but some of the less publicized technologies incorporated into the "Intel Architecture" are proving to be equally exciting.

The competitive chipset market and Intel's devotion to visual computing have resulted in a Darwinian process of selection that has produced memory and PCI performance far beyond what we've seen on other platforms. So-called "Write Combining" in the core logic allows dramatic improvements in bandwidth to display memory, and thus, higher video frame rates.

Offloading the graphics card bus traffic from PCI to the new AGP slot has also been a major win in applications involving capture, processing, and display of multiple video streams. The new Ultra-DMA IDE disk interface allows us to capture 30 fps CIF (320 x 240 x 16 bpp) video images, along with stereo audio directly to an inexpensive ($229) hard drive.

As you might expect, those of us working in the media area are pretty excited by the doors that all this raw power opens. Our media technology demos have gotten increasingly aggressive, and Alex, our VP of Sales and Marketing, has learned not to leave the video demos running if he expects to get any eye contact with his audience.

Developers are also excited by the possibilities they see in the video area. I've noticed, however, that there seem to be a few common conceptual "gotchas" that developers run into when they begin working with video. This isn't surprising, considering that Zworykin developed the first TV camera way back in 1937. Decisions that were sensible and obvious back then seem a bit strange to a developer steeped in the world of high-resolution, progressive-scan computer graphics.

So as you begin your adventures in video, keep in mind that the first experimental television broadcasts began in 1941 and the first color television appeared in 1953 (the year I was born)!

Most of the confusion for video beginners centers around the fact that television signals are not "progressive scan" (like a computer monitor), but "interlaced." What this means is that the display lines that make up the image are not all drawn during each sweep of the screen. The odd lines are drawn during the first sweep of the screen, and the even lines during the next sweep. Note that line numbering starts at one (another strange concept to us computer types). The image drawn by each of these sweeps is called a field, the first referred to as F1 (sometimes called the odd field), the next called F2 (or even field).

The most important thing to remember is that these two fields are samples of the original image, which are taken at different points in space and time. What this means in practice is that unless your image has no motion in it, you *cannot* combine two fields to get a satisfactory still frame. It's possible to do some serious image processing to minimize these temporal artifacts, but this is not for the fainthearted.

Another surprise to many is the limited resolution of a video signal. Standard broadcast NTSC has a horizontal resolution of about 330 image elements, VHS video tape has about 240, and laser disk an amazing 400 image elements per line! ;-)

If you'd like to learn more about these issues, I'd recommend starting with the following resources:

• http://www.sgi.com/TasteOfDT/documents/video/lurker/

  Chris Pirazzi doesn't work at SGI anymore, but his compilation of "little known, undocumented knowledge that you need in order to write any sort of video app" lives on. A great resource for learning about the issues discussed above, with lots of pictures that explain the concepts better than a text-based newsletter like this.

• Video Demystified: A Handbook for the Digital Engineer
  2nd Edition
  By Keith Jack
  Copyright 1996 by HighText Interactive, Inc.
  ISBN: 1-878707-23-X (paperbound)
  ISBN: 1-878707-36-1 (casebound)
  

  An excellent introductory book. It covers basic issues for video in a computer environment, color spaces, details of the standard analog video signals, digital video encoding and decoding, composite and component digital video standards, basic video processing techniques, MPEG and Video conferencing compression and decompression.

• Television Engineering Handbook
  Edited by K. Blair Benson and Jerry Whitaker
  Copyright 1986, 1992 by McGraw-Hill Inc.
  ISBN 0-07-004788-X (casebound)

  The bible for broadcast TV -- expensive, but worth it if you really want to dive into the details of broadcast video. Covers light, vision, and photometry; color vision, representation, and reproduction, optics, visual information transmission theory, video waveform and spectra, TV transmitters and receivers, cable and satellite distribution systems, video recording (tape and disc), digital television, high-definition television.

Engineering Insights: Using the BeIDE with RCS

By Ming Low

Searching for a topic for a Newsletter article, I came across an e-mail from a Be Developer who wanted to know how to use Revision Control System (RCS) with the BeIDE. In response, I'll answer that question and also touch briefly on other tools for source management that are currently available for the BeOS. I'll follow up with a limited simple demo of integrating a shell script with the BeIDE to automatically save change revisions to RCS.

Of the three source management tools currently available for the BeOS, RCS is the most basic. In its plain vanilla form, without additional tools, RCS is best suited for use by individuals or very small groups because it does not have the ability to allow multiple engineers to make edits to the same file. On the plus side, it's free, simple to use, and ships with every BeOS CD. If you are not familiar with RCS, I recommend starting with the rcsintro section in file:///beos/documentation/shell%20tools/index.html for information.

The other two source management tools available for the BeOS are the commercial software P4 from Perforce and the GNU-ported version of Concurrent Versions System (CVS). Both are good choices as a source management tool for handling large scale projects where sharing and editing of files and information tracking are essential.

Perforce P4 software stands out: it's fast, has a rich feature set, and its BeOS binary has been tested (very thoroughly ;-). On the plus side for CVS, it is a good source management tool that can do the job as well as P4, it's free, and the source code is available for hacking. At Be, we use Perforce P4 as our source code management tool. We were extremely impressed with its speed and reporting features, but the main reasons we chose it was because it is supported software and has been ported to over 20 platforms, including our own PPC and Intel platforms. For more information on Perforce P4 and its pricing, check out their website at . General information about CVS can be found at http://www.loria.fr/~molli/cvs-index.html. The BeOS-specific version of CVS was put together by the folks at Geek Gadgets; their website is at http://www.ninemoons.com/GG/.

Before I go into the details of hacking together a script to work with RCS and BeIDE, you'll need to make sure that you have the ShellPlugin for the BeIDE installed in the plugins folder. Without the ShellPlugin, the BeIDE will not run shell scripts. You can find the ShellPlugins on the Metrowerks BeOS CD. We do not ship the ShellPlugin on the BeOS CD.

To get the BeIDE to know when to execute our script, we need to add the following in the Target Prefs panel in the BeIDE.

File Type:  text/*
Extension:  psh
Tool Name:  sh
Flags:      Check the Postlink Stage and no resources

We set the File Type to text/* so that it will run a script which is text. The Extension field tells the BeIDE to run any file ending in .psh. The Tool Name field specified with which tool to run the script. We set the flag stage to Postlink because we want our shell script to run after a successful link.

The new entry line should look something like this in the Target Prefs panel:

Filetype   Extension   MakeStage   Resources   ToolName
 text/*     .psh        4                       sh

Cut between the two dotted lines below and paste into a text file named SaveToRCS.psh. Add the file to your project. Edit the variable SRCHOME to be the path where your source directory is. Then do a make from the project menu of the BeIDE.

This script automatically saves to RCS any files that have changed since the last successful link. This is not an ideal way to do source management if you are doing a significant amount of editing and testing. But it does demonstrate how you can tie RCS into the BeIDE's scripting functionality to save change revisions.

#-----------------------------------------------------------
#!/bin/sh
# SaveToRcs.psh
# postlink stage shell script


SRCHOME="/boot/demo-src"  # change to your source location
RCSHOME="$SRCHOME/rcs"    # where rcs will be
LOGHOME="$SRCHOME/log"    # where log will be
LOGFILE="$LOGHOME/`date '+%y-%m-%d.%H%M%S'`"  # log file

# make sure log dir exists
[ -d "$LOGHOME" ] || mkdir "$LOGHOME" || exit 1

# make sure rcs dir exists
[ -d "$RCSHOME" ] || mkdir "$RCSHOME" || exit 1

# create the file
echo "  RCS Log for $SRCHOME" > "$LOGFILE"

# force the file type
mimeset "$LOGFILE"


# the following  line will fail if any of the files has
# a space in the file name.
for i in `ls *.h *.cpp`  # files we want to rcs
do

 if [ ! -f "$RCSHOME/$i,v" ] # check if it is new

 then

  # set up the initial check-in of the source
  ci -q -u -m"`date`" "$SRCHOME/$i" "$RCSHOME/$i,v" >> "$LOGFILE"

  # for demo, we are setting rcs to non-strict
  rcs -q -U "$RCSHOME/$i,v" >/dev/null

  # print something to the log file
  echo "<<<< file $i was added to RCS as 1.1 >>>>" >> "$LOGFILE"

 else

  # rcsdiff seems to be ignoring the return status ($?)
  # value so we have to use another way to find out if
  # a file changed
  newChange=`rcsdiff -q "$SRCHOME/$i" "$RCSHOME/$i,v" 2>/dev/null`

  if [ -n "$newChange" ]

  then

   # check the file in using RCS's ci tool if it has
   # been modified
   ci -q -u -m"`date`" "$SRCHOME/$i" "$RCSHOME/$i,v" >> "$LOGFILE"

   # this next line grab the revision number from rcs.
   REV=`rlog -h "$RCSHOME/$i,v" | grep head | awk '{print $2}'`

   # print the header info with the rev and the changes
   echo "<<<< Updating file $i to RCS as $REV >>>>" >> "$LOGFILE"
   echo "$newChange" >> "$LOGFILE"

  fi
 fi
done

# for demo, we open the file to show the change information
if [ `wc -l "$LOGFILE" | awk '{print $1}'` -gt 1 ]

then

 # it may make more sense to just pipe the info to another
 # file but for demo, let's have the BeIDE open it
 /boot/apps/Metrowerks/BeIDE "$LOGFILE" &

else

 # nothing changed, delete the log file
 rm -f "$LOGFILE"

fi

DEVELOPERS' WORKSHOP: Fiddling With Tracker Add-ons

By Victor Tsou

"Developers' Workshop" is a new weekly feature that provides answers to our developers' questions. Each week, a Be technical support or documentation professional will choose a question (or two) sent in by an actual developer and provide an answer.

We've created a new section on our website. Please send us your Newsletter topic suggestions by visiting the website at: http://www.be.com/developers/suggestion_box.html.

Tracker add-ons allow a user to easily run a program on a set of files. Many Tracker add-ons have already been written, including the ever-popular TermHire, which opens a terminal window in the current directory; and ZipMe, which creates a ZIP archive of the selected files and directories.

Any program can act as a Tracker add-on if it exports the symbol process_refs. In BeOS Release 3, the prototype for this function will be found in be/add-ons/tracker/TrackerAddOn.h. In the meantime, you can add the following lines to your source:

#pragma export on
void process_refs(entry_ref dir_ref, BMessage *msg, void *);
#pragma export reset

Once Release 3 is released, replace those lines with

#include <be/add-ons/tracker/TrackerAddOn.h>

The prototype in the header file differs slightly from the PR2 form. Under Release 3, the Tracker looks for the unmangled form of the name to ease compatibility between the PPC and Intel versions. While the old form will still work for PPC machines, it will not for Intel.

Now that the prototype has been declared, it's time to write the function itself. process_refs takes three arguments:

• The first argument is an entry_ref giving the current directory. If the add-on was invoked from a Tracker window, then this directory will be the same as that of the window. If it was invoked from the desktop, then the directory will be /boot/home/Desktop.

• The second argument is a B_REFS_RECEIVED BMessage with the "refs" field containing an array filled with the entry_ref's to the items selected in the Tracker window.

• The third argument is currently unused.

The add-on runs in the Tracker's team. If your program dies, you can kiss your Tracker goodbye. At the same time, the add-on is perfectly capable of acting as an application; all it needs to do is implement main(). For example, you could turn grep into an add-on that also can be run from the command line.

A simple Tracker add-on is shown below. It displays the current directory as well as any selected files. It's also very ugly. You have been warned.

#include >Application.h<
#include >InterfaceKit.h<
#include >StorageKit.h<

// Release 3 way
#include <be/add-ons/tracker/TrackerAddOn.h>

// PR2 way
// #pragma export on
// void process_refs(entry_ref dir_ref, BMessage *msg, void *);
// #pragma export reset

void process_refs(entry_ref dir_ref, BMessage *msg, void *)
{
    BWindow *window =
       new BWindow(BRect(100,100,300,300),
                   "Sample Tracker Add-on",
                   B_DOCUMENT_WINDOW,
                   0);
    BTextView *view =
       new BTextView(BRect(0,0,200,200),
                     "view",
                     BRect(0,0,200,200),
                     B_FOLLOW_ALL_SIDES,
                     B_WILL_DRAW | B_FULL_UPDATE_ON_RESIZE);
    BPath path;
    BEntry entry(&dir_ref);

    // fetch current directory
    entry.GetPath(&path);
    view->Insert("Current Directory: ");
    view->Insert(path.Path());
    view->Insert("\n");

    int refs;
    entry_ref file_ref;

    // fetch each selected file
    for (refs=0;
         msg->FindRef("refs", refs, &file_ref) == B_NO_ERROR;
         refs++) {
      if (refs == 0)
        view->Insert("Selected files:\n");
      entry.SetTo(&file_ref);
      entry.GetPath(&path);
      view->Insert(path.Path());
      view->Insert("\n");
    }

    if (refs == 0)
        view->Insert("No files selected.\n");

    view->MakeEditable(false);
    window->AddChild(view);
    window->Show();
}

// executable code stub
main()
{
    new BApplication("application/x-sample-tracker-add-on");
    (new BAlert("",
                "This is a sample Tracker add-on",
                "swell"))->Go();
    delete be_app;
}

Appliances at Demo 98

By Jean-Louis Gassée

Before I jump into my main topic, a tip of our collective hat to our friends at Adamation. Before an audience of professional cynics assembled at this industry conference in Palm Springs, Stephen Adams and Mark Hall demonstrated Home Studio, a personal video editing and compositing application.

This was the first time a third-party BeOS application was featured at this industry forum. Unlike other products shown earlier in the day, the demo went flawlessly, was very well received, and the feedback in the hallways was extremely positive, both on the application and the underlying BeOS. We know what we have to do: Let's make sure we have a festival of BeOS products at Demo 99.

Back to Demo 98, one session featured a bearded researcher telling us we didn't understand the future of PCs. They are too complicated, the future is appliances, PCs must become invisible. This reminded me of another conference, Agenda, in October of last year. There, another industry sage berated us for not seeing the consumer electronics industry was much larger than the PC market, for not listening to consumers, for making products too complicated.

For a while, I sat there feeling guilty. Yes, we're not paying enough attention, we mindlessly pile features upon features, we fall in love with technology. The guilt trip had been going on for a while when I woke up with a start. I suddenly realized the vaticinating gentleman had no experience whatsoever in anything even remotely connected to the consumer electronics industry.

There is no need to reveal his identity since this isn't an ad hominem argument; suffice it to say he had been the head of a software firm providing highly technical design tools and had just joined another one after briefly working for a prestigious and unfortunately misunderstood financier. He and the bearded professor make a similar argument regarding the faults and the future of the PC industry. And, in several respects, they're right, as stipulated earlier.

But their politically correct discourse suffers from three defects. The first one is what I call the diet problem, the second one could be called the dirigiste mistake, and the last one is myopia.

Let's start with dieting. Everyone knows in order to lose weight one has to exercise more and eat less, but no one really knows how to gain and keep the resolve to permanently alter one's behavior. Don't tell me what, tell me how. I'm struck by the fact that these critics and their many brothers rarely offer concrete suggestions, a new UI design, or a new product. Still, they play a useful role in reminding us of the dangers of complacency.

The dirigiste problem reminds me of my country of birth where, without even thinking twice, high-level civil servants suggest the creation of free enterprise government programs and of clones of Silicon Valley. This is the same delusion as decreeing desire -- it doesn't work that way. Why do these critics berate the PC industry for not seeing the big opportunity? There is a free market out there, it creates competition every day and big opportunities always attract big money. The free market dealt with IBM and Digital, to name but two, when they ignored new life forms.

Lastly, the appliances are right here under their very noses. WebTV Plus (a very insightful review appeared in the February 3rd "New York Times") is an excellent example of an appliance providing elegant simplicity of installation and use in navigating the Web and TV broadcasts. Demo 98 also featured the CIDCO iPhone, a device combining Web browsing, e-mail, and a telephone, the size of a full-featured set, for less than $500. I heard many participants referring to computerphobe relatives who would use such a device on their kitchen counter. Just like in the original Macintosh brochures...