Thread View: comp.multimedia
4 messages
4 total messages
Started by David Elliott
Tue, 08 Sep 1992 01:58
Centralized timing service
Author: David Elliott
Date: Tue, 08 Sep 1992 01:58
Date: Tue, 08 Sep 1992 01:58
42 lines
2646 bytes
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
Author: Lawrence D'Oliveiro, Waikato Uni...
Date: Thu, 10 Sep 1992 04:32
Date: Thu, 10 Sep 1992 04:32
35 lines
2451 bytes
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
Author: Bob Berger
Date: Thu, 10 Sep 1992 17:11
Date: Thu, 10 Sep 1992 17:11
18 lines
1321 bytes
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
Author: George Drapeau
Date: Fri, 11 Sep 1992 00:53
Date: Fri, 11 Sep 1992 00:53
47 lines
2701 bytes
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