Message-Id: <9010182319.AA05382@zit.LABS.TEK.COM>
To: dcc@ATHENA.MIT.EDU
Cc: vex@EXPO.LCS.MIT.EDU
Subject: Re: More on removing device control/connectivity from VEX. 
In-Reply-To: Your message of Wed, 17 Oct 90 19:13:48 -0400.
             <9010172313.AA27068@BOOM> 
Reply-To: toddb%sail.labs.tek.com@RELAY.CS.NET
From: toddb%sail.labs.tek.com@RELAY.CS.NET
Date: Thu, 18 Oct 90 16:19:49 PDT
Sender: toddb%zit.labs.tek.com@RELAY.CS.NET

>   The central point of contention seems to be synchronization, and
>   whether managing device control/connectivity inside the X server
>   buys you anything.  

Correct.

>   Todd portrays VEX as a frame accurate video editing service suitable
>   for studio video post production.  Post production systems generally
>   have a central microprocessor and potentially a microprocessor for
>   each video device, all runing in realtime.  Timecodes, frame
>   numbers, or head spins are monitored and multiple devices are
>   synchronized by adjusting the speed or bumping the position of
>   devices during the pre-role process.

What you have described could be one of two things: the previous generation
of edit controllers (like those from Sony, Ampex and Grass Valley Group),
or the current generation of device controllers (like those from VideoMedia,
Lyon-Lamb and DiaQuest).

At the risk of over-simplifying the reason for device control/connectivity
in VEX, let me continue on this niche for video.  The newest generation of
editors includes something now called a "non-linear, off-line, video
post-production editor".  The hottest ones on the market appear to
be AVID/1 from AVID and EMC2 from Editing Machines Corporation.  These do
not fit your description at all.

These machines typically digitize video footage in real time, compressing
and storing it on large SCSI disks.  Then arbitrary editing can be
performed in real time.  These machines must be very low cost (currently
$40k-$80k) and as a result are a single cpu with no other hardware
help; e.g. the AVID is a Mac II with a NuVista board and lots of disk.
This means that during the edit session, there are no external machines
involved; its all happening in the same box, handled by a single cpu.

To perform the equivalent task in an X station, you really don't one
one process handling the device (decompression from the disk) and another
handling the placement of the video on the screen.  They are the same
task!

Consider some others.  Let's say that I have an application that wants to
digitize (RenderVideo) one particular frame from a video media as it flies by. 
If I have a video disc, I could simply seek to that point on the disk and
freeze the interesting frame.  But if I have a video tape player, this will be
impossible because even BetaCam or Umatic quality machines cannot display a
single coherent frame and lesser quality VHS machines only display one field
doubled over.

The only solution is to have the digitizer integrated with the frame
buffer and to be able to decode the VITC (vertical interval time code)
from the frame as it flies by, and when the proper frame is available,
it is digitized.  For this, not only do I want control
of the device, but I have to have a "control" for expressing the
frame or timecode that must be digitized.

One more kick for this dead horse:  There are other aspects of the
RenderVideo/CaptureGraphics process that are tightly coupled to it but
are completely outside of the domain of X.  For example, luminance
or chroma gain could be adjusted when the picture is digitized
(Parallax recognized this and it was part of their extension).  This
kind of thing, and others, fit nicely with the control mechanism.

>   Video device control and connectivity, if not
>   managed by an out-board video editing box, should be managed by a
>   separate server.  A server dedicated to this purpose might actually
>   have a chance of attaining the realtime behavior necessary for
>   proper synchronization and frame accuracy.

Chances are no good in the broadcast industry.  You either do it, or your
product is mud.  For the applications mentioned above, and others, I can
guarantee it with VEX's control mechanism.  In addition, If you feel that VEX
should not have this ability at your site, then you can use your own method of
device control.  VEX was specifically designed to allow this.

I think this is what compromise is about: you get to do what you want
and I get to do what I want.  Your proposal would mean that I
would have to have a private extension to VEX, and that would
mean I shouldn't be doing VEX in the first place.

---------------
internet: toddb@sail.labs.tek.com                                   c--Q Q
US:       Todd Brunhoff; Systems Architecture and Imaging Lab;          `
          Tektronix, Inc.;  Box 500  MS 50-321, Beaverton OR 97077      -
Phone:    (503) 627-1121