From: dcc@ATHENA.MIT.EDU
Message-Id: <9010192006.AA28650@BOOM>
To: vex@expo.lcs.mit.edu
Subject: Round 3: device control and connectivity and VEX
Date: Fri, 19 Oct 90 16:06:45 EDT


  I sort of promised myself that I wouldn't continue to debate this
  issue.  My goal isn't to convince Todd, but rather to provide
  technical input (issues and alternatives) to committee members.
  Nevertheless, Todd mentioned some additional systems and gave some
  specific examples that are useful to examine.

  The basis of my position is that VEX does not support frame accurate
  synchronization.  If Todd is achieving frame accuracy, it is his
  equipment and implementation that achieve it despite the lack of
  synchronization semantics between independent VEX requests.

  I have already discussed the merits of using a peer server approach.
  The examples below serve to demonstrate how a peer server can be
  used to achieve frame accuracy where frame accuracy is achievable.

/David

  
>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.

  While Todd has described some new more integrated systems, the basic
  characteristics of the problem remain: asynchronous realtime control
  of video devices.  VEX is still controlling devices and displaying
  video across multiple X requests: consistent and guaranteed frame
  accuracy is not possible.  Either more accurate synchronization
  (frame accuracy) is needed or interprocess synchronization is
  sufficient.  

  Todd has justified the need for additional complexity by the need
  for frame accuracy while not achieving that goal.

>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!

  This is a good example.  I would not bury this asynchronous realtime
  activity inside the single X server process.  My approach is to
  invoke an X request to render video into a window, then send a
  request to the video device server to manage the disk.  Rendering
  should start when data arrives (i.e., frame accurate synchronization).

>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.

  This is exactly my point, but not the solution I had in mind.  VEX
  provides no way of saying RenderVideo when timecode (frame number)
  is encountered.  Adding this to VEX should be considered.  More to
  the point, since the video data is used for synchronization, device
  control can be managed outside the X server.  My approach is to
  invoke an X request to render video into a window when a particular
  timecode value is encountered, and then send a video device server
  request to role the tape (i.e., frame accurate synchronization).