[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mtvp-sdk
Subject:    Re: Atul's problems
From:       Tristan Savatier <tristan () bok ! net>
Date:       1998-04-28 21:36:55
[Download RAW message or body]

To subscribers of the mtvp-sdk@mpegtv.com mailing list:

Tony Higgins wrote:
> 
> Are there any commands besides COM_SEEK that should NOT
> be sent to mtvp until after the A2G_COM_DISPLAY_READY is
> received ?

You can send any command including COM_SEEK but it makes no sense
to send a second COM_SEEK before the player has actually completed
the first COM_SEEK command and displayed the corresponding frame.

A COM_SEEK command is considered completed when the player
has reached a displayable frame after doing the seek.
When this happens, the player sends a A2G_COM_DISPLAY_READY.

-t


> 
> - Tony.
> 
> >----------
> >From:  Tristan Savatier[SMTP:tristan@bok.net]
> >Sent:  Tuesday, April 28, 1998 1:49 AM
> >To:    Atul Sowani
> >Cc:    mtvp-sdk@mpegtv.com
> >Subject:       Re: Atul's problems
> >
> >To subscribers of the mtvp-sdk@mpegtv.com mailing list:
> >
> >Atul Sowani wrote:
> >>
> >> To subscribers of the mtvp-sdk@mpegtv.com mailing list:
> >>
> >> Hi Tristan!
> >>
> >>   I am still facing the problem while implementing the Fast Rewind
> >> functionality.
> >
> >What problem are you facing ?
> >
> >You can implement a fast rewind effect by doing seek(s) at
> >successive points back in the stream.  Make sure that you wait
> >until you get a A2G_COM_DISPLAY_READY before issuing another
> >COM_SEEK command.
> >
> >Normally you should be able to get an effect similar to what
> >you get by dragging the slide bar of mtv toward the beginning
> >of the sequence (i.e. a fast reverse effect).  You may need to
> >take care of timing. If you don't, your fast reverse may become
> >too fast on fast platforms.
> >
> >> Another thing which concerns me is the color allocation.
> >> I am using version 1.0.5.11-XIL of the mtvp (and SDK) on Solaris 2.5
> >> on Ultra-1. And I am hving problems with color allocations with mtvp,
> >> when netscape is running. I think this bug has been fixed for Linux
> >> some time ago.
> >
> >One bug has been fixed (that was causing mtvp
> >to always use a private colormap
> >when video was
> >displayed in an existing windows).
> >
> >This bug was fixed in the source and this is fixed in 1.0.5.9
> >and later versions (including Solaris).
> >
> >But the problem that you have is most likely a combination
> >of a problem with netscape (sometimes it allocates too many colors
> >in the shared colormap - mtvp needs at least 64) and/or
> >the window manager (maybe it does not let mtvp set the
> >colormap for a window that was created by netscape).
> >
> >You can trace mtvp's color allocation calls
> >by passing -w8 to mtvp.  This may give you some understanding
> >of what mtvp does.
> >
> >If you still have problems, I suggest that you contact
> >Tony Higgins from Televitesse (THiggins@Televitesse.Com).
> >He had to deal with netscape and color allocation.
> >
> >-t
> >___________________________________________________________
> >To unsubscribe, send a mailto:mtvp-sdk-request@mpegtv.com
> >with no subject and "unsubscribe" in the body.
> >
> >

-- 
Regards, -- Tristan Savatier (President, MpegTV LLC)

MpegTV:   http://www.mpegtv.com
MPEG.ORG: http://www.mpeg.org - Home: http://www.bok.net/~tristan
___________________________________________________________
To unsubscribe, send a mailto:mtvp-sdk-request@mpegtv.com
with no subject and "unsubscribe" in the body.

[prev in list] [next in list] [prev in thread] [next in thread]