From: dcc@ATHENA.MIT.EDU
Message-Id: <9010172313.AA27068@BOOM>
To: vex@expo.lcs.mit.edu
Subject: More on removing device control/connectivity from VEX.
Date: Wed, 17 Oct 90 19:13:48 EDT


  The following are my counterpoints to Todd's arguments for wanting
  device control and connectivity as part of the VEX extension.  This
  will hopefully clarify our position and reasons for not wanting
  device control/connectivity as part of a standardized X extension.

/David Carver

>This is a non-argument...
>Unless you prove that device
>control/connectivity is not useful in VEX, this cannot be argued.  In other
>words this is backwards...

  Todd seems to be saying that because a service is useful to video
  applications it belongs in VEX: the "all in one" approach.  Our
  position is that amongst all the services useful to video
  applications we should be particular about which to included in an X
  extension, particularly when standardization is at stake.

  Defining a large functionally diverse extension---VEX more or less
  fits that description, though it is not alone---will have a
  profoundly negative effect on keeping X manageable.

>Let me help you out here... what you are alluding to is that an API
>that provides device control should be generic enough to be used
>outside of X, and that because VEX defines an API, it cannot be used
>outside of X.  I can disagree with this on two fronts:...

  If you examine VEXlib you will see that all the procedures and data
  structures reference X types and resources, except, that is, for the
  device control and connectivity procedures which seem quite independent.
  
  This highlights that video device control/connectivity---data
  storage, retrieval, and transmission---shouldn't be part of the X
  server which is concerned mostly with rendition, display, and user
  input.

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

>You are very much incorrect.  Consider the following two scenarios:
>  - I may want to synchronize the playing of my tape machine with the
>    RenderVideo of a *particular* frame.
>  - I may want to synchronize a wipe from one video sequence to another
>    given two video sequences....
>However, if I told my friends at NBC that I can't guarantee
>frame accurate transitions, they wouldn't be my friends anymore.

  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.
  
  Presumably, clients of VEX would attempt the same through the use of
  multiple X requests and events.  For example, simply trying to start
  one tape playing and attempting to display a particular frame using
  separate X requests.  There are many factors that greatly effect the
  timing of requests.  VEX cannot provide a guarantee or even a
  consistently high probability of synchronization and frame accuracy,
  especially across implementations.


			    - - - - - - -

  The alternative I suggest is that VEX be simplified to perform basic
  display and capture: VEX's RenderVideo and CaptureGraphics more or
  less covers this.  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.

  In this model, the user interface and monitoring of a video post
  production system would be provided through X.  The editor client
  would either talk to an out-board editor box or to a video editor
  process.