🚀 go-pugleaf

|> Hi,
|> 
|> In the Berkeley distribution of mpeg_play, there is a field in the
|> video stream structure called show_time. Apparently, that field is 
|> never used. So is there any real time consideration at all in mpeg_play
|> to ensure a smooth display of the frames, namely that a frame is shown
|> only when its supposed show time is reached? Or is it assumed that 
|> the workstation is never fast enough to display a frame too early so
|> the goal is to get a frame displayed as early as possible?
|> 

I think I'm probably qualified to answer this one.  The mpeg_play
program was never really intended to serve as a full function mpeg
player. To wit (from the README file):

    The decoder is implemented as a library that will take a video
    stream and display it in an X window on an 8, 24 or 32 bit
    deep display.  The main routine is supplied to demonstrate the
    use of the decoder library.

In other words, the mpeg library is meant to be used as part of a system
that handles synchronization with other media.  Such a system exists as
an unreleased prototype (the "player") we're building at Berkeley (we'll
be releasing the system sometime in the future).  A paper briefly
describing the system is available from toe.cs.berkeley.edu
(128.32.149.117) in /pub/multimedia/papers/CMPlayer.ps.Z. The paper
was presented at the "3rd Intl Workshop on Network and OS Support
for Digital Audio and Video", San Diego, CA, Nov 92.

The main routine supplied with the distribution, mpeg_play, displays
the pictures as quickly as possible.  Think of it as a simple demo
program (we felt kinda bad about releasing the library without at
least one sample program :-). 

So, the answer to you questions is this: the "show_time" field is
prototypical -- it is neither meaningfully set nor used in the
mpeg_play program, but something like it will be used in the player.

It shouldn't be too hard to modify mpeg_play so it slows down between
frames.  I'd do it by modifying mpegVidRsrc() to return NULL when it gets
around to actually displaying the picture (ie., put a "return NULL" just
after the DoPictureDisplay call in mpegVidRsrc).  Then, in the main()
routine, when mpegVidRsrc() returns NULL, put the process to sleep
(e.g., with a select()) until it's time to display the next frame.  Simple
enough, but it would be a duplication of effort since we're building that
functionality into the player.

I hope this seems at least vaguely intelligible.

-------
Brian C. Smith				arpa:  bsmith@cs.Berkeley.EDU
University of California, Berkeley	uucp:  uunet!ucbvax!postgres!bsmith
Computer Sciences Department		phone: (510)642-9585