🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Thread View: comp.multimedia
4 messages
4 total messages Started by David Elliott Tue, 08 Sep 1992 01:58
Centralized timing service
#556
Author: David Elliott
Date: Tue, 08 Sep 1992 01:58
42 lines
2646 bytes
I'll have to admit that I'm not familiar with the deep details of
QuickTime, the X Synchronization Extension and other "multimedia"
systems, so if this is something already available, then all the
better.

One of the problems I've seen with multimedia systems is that they
provide support for developing "all-in-one" programs, but not really
for dealing with multiple synced programs.

As an example, let's say I have a program that can display graphics
along with a digital soundtrack.  Now, let's say I have a video camera
and display that I can control from my computer, and I want to be able
to display "pictures" in sync with my graphics/sountrack program.

One way to deal with this is to develop my own program to display the
graphics/soundtrack so that I can more easily sync to the data.  This
may require quite a bit of work, and it may not really do what I want.

Also, there's an additional problem of how to deal with programming
systems that need different kinds of event loops, as well as those that
aren't event driven at all.  For example, trying to write such a
program using X for graphics, something else for video control
(assuming VEX isn't available and XV doesn't control my device), and
something else for synced sound would be a mess -- doable, but a mess.

It seems to me that the ultimate would be to have a centralized timing
service.  Such a service would allow the user to create named "clocks",
which programs could attach to to get timing events.

With this type of service, one could write programs to add capabilities
to existing programs, or build entire multimedia systems out of
separate programs.  In the example above, I could write a separate
program that would control my video camera and display in sync with the
other program.  I would only have to set the cue points ("hits") and
ask the timing service to tell me when one of these times has occurred,
or when the program has paused, or restarted, or reset, or changed time
base, or whatever.

A real advantage to this is that it would not require continually
extending existing programming systems to add new capabilities.  Another
is that hardware-specific additions could be made without having to
revamp the entire subsystem.
Re: Centralized timing service
#574
Author: Lawrence D'Oliveiro, Waikato Uni...
Date: Thu, 10 Sep 1992 04:32
35 lines
2451 bytes
In article <1992Sep9.224534.11086@smsc.sony.com>, dce@smsc.sony.com
(David Elliott) asks about syncing multiple programs as part of a multimedia
presentation.

These sorts of capabilities are described in detail in the QuickTime
documentation. I must admit this is one area of QuickTime which I haven't
actually tried out, but here are some of the things the documentation leads
me to believe you can do:

      * You have "timebase" components and "clock" components.
	A "clock" is an actual time reference (such as a hardware clock),
	whereas a "timebase" is something you slave to a clock (or to another
	timebase). A timebase may also mark time at a rate other than 1:1
	relative to its master, and it may loop.
      * QuickTime 1.0 provides two standard clocks: the "tick" clock
	(60.15 ticks = 1 second) and the Time Manager microsecond clock
	(actual claimed resolution is 20 microseconds). You could define
	additional clock components, for example one that was just a slave
	to a central time service on a network.
      * You can attach callback routines to a clock or timebase component
	instance. A callback can be triggered at a specific time, at a specific
	time but only if time is moving in a particular direction (!), or on a
	change of rate of passage of time, or on a sudden jump in the
	current time value. You specify whether the callback is an interrupt
	or non-interrupt routine; the latter has more flexibility in what it
	is allowed to do when invoked, but the invocation latency is greater.
      * You can change the timebase or clock attached to a movie.
	For example, this could be used to synchronize the playback of
	a group of movies, without any further special action.

Lawrence D'Oliveiro                       fone: +64-7-856-2889
Computer Services Dept                     fax: +64-7-838-4066
University of Waikato            electric mail: ldo@waikato.ac.nz
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00
A copy of my new automatic enclosure-encoding software follows.
Re: Centralized timing service
#582
Author: Bob Berger
Date: Thu, 10 Sep 1992 17:11
18 lines
1321 bytes
(Hi David! come visit some time, I have a copy of what is mentioned below)

The most recent (Sept-Oct 1992) issue of The X Journal discusses this
to a certain extent in Dan Heller's column "X Communications:
Mutlimedia applications under the X Window System". He doesn't really
answer your questions just restates them :-)

There are some folks doing what looks to be important work in the area
of "Meta-scheduling for Distributed Continuous Media" at the Computer
Science Division, EECS Dept. U of CA at Berkeley under the direction
of David P. Anderson (anderson%charming.Berkeley.EDU@ucbvax.Berkeley.EDU?).

Some papers are available in icsi-ftp.Berkeley.EDU:/pub/dash

-- 
Bob Berger  -  SONY Advanced Video Technology Center
685 River Oaks Parkway  San Jose, CA 95134 408-944-4964 FAX:  408-954-1027  
INTERNET: berger@sfc.sony.com   UUCP: [uunet,mips]!sonyusa!sfcsun!berger
Re: Centralized timing service
#588
Author: George Drapeau
Date: Fri, 11 Sep 1992 00:53
47 lines
2701 bytes
In article <1992Sep9.224534.11086@smsc.sony.com> dce@smsc.sony.com (David Elliott) writes:

   I'll have to admit that I'm not familiar with the deep details of
   QuickTime, the X Synchronization Extension and other "multimedia"
   systems, so if this is something already available, then all the
   better.

   One of the problems I've seen with multimedia systems is that they
   provide support for developing "all-in-one" programs, but not really
   for dealing with multiple synced programs.

   [rest of original posting deleted -- George]

You might check out MAEstro, (I'm the Project Leader).  MAEstro is a
distributed multimedia authoring environment for Unix boxes, the core
of which is an inter-application messaging system built on top of Sun
RPC.  We are trying to address some of the problems you mention.  How
successful we are, I'm not sure, but we have learned quite a lot from
our experience so far.

The MAEstro software (source and binaries) are freely available via
anonymous ftp from sioux.stanford.edu, in the directory pub/MAEstro.
The full source distribution comes with copious documentation,
including a paper presented at the 1991 Summer Usenix conference, and
the MAEstro Programmer's Guide which describes in great detail the
protocol, semantics, and how we hope to address synchronization
problems (in part, at least).

The Usenix paper should give you a good technical overview of the
environment and the rationale behind our design.  If you have any
questions beyond that, please feel free to ask me.

(Also, ask me about a possible Sony NEWS port; I'm compiling XView 3.0
in the background, as I write this message, on a NEWS laptop running
4.3; the current MAEstro applications were written with the XView
toolkit, although the protocol itself is window-system-neutral).

I hope this helps some.

	George

P.S.:  I just finished a driver for the Vdeck.  Nice box.
--
______________________________________________________________________________
George D. Drapeau			Internet: drapeau@sioux.stanford.edu
Libraries and Information Resources
Stanford University
Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads