Menu
▾
▴
RE: [Dvd-devel] Re: [xine-devel] Button active areas.
|
From: Siggi L. <si...@us...> - 2001-10-05 15:18:13
|
Hi again,
sorry for the high percentage of quotes, but I wanted to keep all
information in one place...
On Fri, 5 Oct 2001, James Courtier-Dutton wrote:
> > > 1) NAV packets for active areas and CLUT.
> >
> > This will tell us
> > - location/dimension of (rectangular?) buttons currently on screen
> > ("active areas", needed to select button by mouse)
> > - CLUT for color/alpha values of button highlighting
> >
> > > 2) SPU packets for active area offsets and alpha blend info.
> >
> > This gives us the button highlights as subpicture.
[...]
> Each MENU SPU packet contains an X,Y offset. (From the start of the actua=
l
> screen to the start of the overlay image).
> The MENU SPU packet contains one large overlay image (Generally fills alm=
ost
> the entire screen).
> Most often the SPU MENU Overlay image is a bit smaller than the entire
> screen, so the SPU X,Y offset values are non-zero.
> NAV packets give us an X,Y offset (From the start of the SPU Overlay imag=
e,
> not the actual screen) and width and height. There is an entry for each
> button on the screen.
> These entries are used to select different areas of the single SPU Menu
> overlay image to use when highlighting the menu buttons.
Okay, got the point. Does this only sound complicated to me or is it
really difficult to handle? I thought the logical way to represent button
highlights is one overlay per highlighted button...
> > > 3) Current stream dimensions.
> >
> > Okay, that's with/height of the current frame, should be known to the
> > video decoder and vidoe_out plugins already.
> >
> > > 4) Current video output windows size. (To work out scaling).
> >
> > Width/height of the current video out window. The frame (->3) is actual=
ly
> > scaled to this size.
> > Well, this can actually be
> > a) size of the scaled video
> > b) size of the output window, which can be more than a) in one dimensio=
n:
> >
> > +---------------------------------------+ -
> > | | |
> > +---------------------------------------+ |
> > | | |
> > | video | |
> > | frame | |
> > | (scaled) | window height (pixels)
> > | | |
> > | | |
> > +---------------------------------------+ |
> > | | |
> > +---------------------------------------+ -
> >
> > note that the video out window is actually higher than the scaled frame
> > in this example, which should be a common scenario when playing 16:9 DV=
Ds
> > on a 4:3 screen...
> > I think that the black bars are an optimal place for OSD and similar
> > stuff (maybe even subtitles). However, that would probably imply anothe=
r
> > implementation for our SPU overlays, as we can currently only overlay
> > buttons over the video frame...
>=20
> The DVD SPU packets actually tells us where on the video frame to put the
> subtitles.
> So, we cannot move them off the video frame.
We can. There are hardware DVD players which allow several subtitles at
the same time by simply adding an offset to the subtitle position, so they
don't overlap.
That doesn't make sense for menu highlights, of course, since the menu
itself _is_ the video frame...
[...]
> > > There should be two methods for passing info from input plugins
> > to the video
> > > out.
> > > 1) Via the current fifo method, as a special buffer_type in the strea=
m.
> > > 2) Via the current events method, for more immediate action.
> > >
> > > So, for my solution, I would expand the libspudec plugin to
> > also partially
> > > decode NAV packets to get the button info.
> >
> > What's the gain with this? NAV packets are DVD specific, AFAIK, so they
> > really belong in the DVDNAV plugin!
>=20
> SPU packets are DVD specific as well!
Not really. I have a lot of .vob files with those ;-)
> For MENU buttons, we need half the info from the NAV packet and half the
> info from the SPU packet. So putting them in the same plugin seems a good
> idea to me.
Which would break subtitles on .vob files, right?
> So, half a NAV packet is for menu buttons, the other half is for input
> control.(Selecting which sector off the DVD to read next).
That sounds like a stupid approach, but we can't help it...
But it would still make sense to make the NAV decoder a "special" plugin,
that passes input control information back to the input plugin and menu
information to the overlay manager, wouldn't it?
> So, half the decode should be done in the input plugin, and half the deco=
de
> should be done in the libspudec plugin.
Is input control so timing-critical that it has to happen directly in the
input plugin? I thought the NAV packets come from xine's MPEG demuxer and
are _then_ decoded (currently by DVDNAV). Is that wrong?
> > > The xine-lib/src/xine-engine/video_out.c would receive mouse and
> > > keyboard/remote control events from the GUI.
> > > For mouse events, it would adjust the mouse x/y values to allow
> > for scaling.
> >
> > Makes sense.
> >
> > > It would then pass this info to the libspudec plugin.
> >
> > Aaah, now I get the point. But does this really belong to the spudec?
> > I think we need something like an "overlay manager" here, which would b=
e
> > responsible for displaying subpictures (subtitles, menu highlights, OSD=
).
> >
> > That way we have:
> >
> > - input plugin
> > - read media, decode everything that's specific for the medium,
> > eg. IFOs for DVDs
> >
> > - demuxer
> > - demultiplex the system stream, hand substreams to audio, video and
> > "special" decoders
> >
> > - audio/video decoder plugins as they currently are
> >
> > - "special" decoders. These decode non- audio/video substreams
> > - spudec (decodes DVD subpictures)
> > - navdec (decodes NAV packets)
>=20
> SPU and NAV packets reference each other and need to be matched together =
by
> comparing PTS values, so I think they should be in the same plugin.
That matching could also be done later, as pts don't change, but of
course, you're the one who implements (and knows enough about) it so
you're free to decide...
I thought about separating them, because I considered navdec DVD specific,
in contrast to spudec, but maybe I'm wrong.
> > - maybe something for IFO data, which could be delivered directly fro=
m
> > the input plugin, I admit I don't know enough about that stuff...
> > - OSDdec which would be more of an OSD generator, that could display
> > funny things like a volume slider, time remaining, current
> > file/movie/chapter/whatever names, ...
> >
> > We don't have something like that,yet, but I really think it's worth =
to
> > introduce a clean interface. Otherwise, we'll end up using hacks to
> > manipulate our xine_t instance or such ;-)
> >
> > > The libspudec plugin would then work out which button to
> > highlight, and send
> > > any event to the navdvd input plugin with just the "Button 1
> > Pressed" type
> > > messages.
> >
> > Sounds sensible, but I'd prefer to separate this funtionality from the
> > actual subtitle decoding. This could also be useful for non-DVD
> > (SVCD?) menus or OSD, which are probably not based on DVD-SPU format...
> >
> > > In this way, no mouse info will get to the navdvd input plugin,
> > just button
> > > press info.
> >
> > Which would reduce complexity and communication overhead, fine!
> >
> > > Then, when other subtitle decoders arrive (DVD Scripts etc.), all tha=
t
> > > happens is that the libspudec plugin is changed for a different
> > plugin which
> > > handles scripts.
> >
> > Well, I wouldn't force them to "reinvent the wheel" wrt subtitle/highli=
ght
> > display. That code could really be used by all of them...
[...]
> So, to calculate if the mouse is over a button, one needs to do the
> following: -
> Adjust the mouse X,Y values to allow for scaling.
> In some scaling situations, the entire original image might be offset fro=
m
> the actual video out window. (See siggy's image earlier in this email).
Okay so far.
> Then, we need to subtract away the SPU X,Y offset values contained in the
> SPU MENU Image.
> Only then do we have X and Y values which we can compare with the Button
> Highlight details in the NAV packets.
Really? So "Button Highlight details" (ie. mouse coordinates for the
sensitive area of a button) are given relative to the SPU MENU image, not
relative to the video frame??? These DVD formats really seem, well,
unnecessarily complicated to me...
> Currently, the navdvd plugin recieves X,Y MOUSE values which have somehow
> already been scaled. (Wrongly at the moment, it does not take account of
> image offsets done while scaling, it just compares original image width w=
ith
> scaled window width.
Okay, that explains why it's difficult to point at some buttons...
> navdvd then compares these X,Y values with the NAV packet buttons.
> So currently, it is getting bad scale adjusted X,Y values, and also missi=
ng
> out the SPU offset step.
>=20
> I am not sure where in xine details of the scaling is kept, but I know ab=
out
> SPU and NAV packets, and that info could go in the libspudec plugin.
Okay, let's see...
Size of the video output window is kept in the ui, we don't want to touch
that, I guess...
Size of the current frame can be found in video_out.h:
in struct vo_frame_S: int width, height;
(this is in pixels for the unscaled picture, if it's anamorphic 16:9, it's
still in 4:3 format)
This was intended to allow "seemless branching" even when the resolution
changes, it's probably obsolete. (G=FCnter?)
The video out driver (struct vo_instance_s) gets width and height when
the xine engine asks to allocate a frame via get_frame(). That's the same
info as above.
Size of the output window and scaled size of the video frame are currently
private to the video_out drivers, AFAICT.
Let's take video_out/video_out_xv.c as an example:
width and height are stored in a struct xv_driver_t, in these members:
int output_width; /* frames will appear in this
=09=09=09=09=09 size (pixels) on screen */
int output_height;
int output_xoffset;
int output_yoffset;
It should definitely be the video_out plugin's job to convert mouse
coordinates to vide frame coordinates before passing them on...
Hope that answers some questions, hope my ideas about separating out
"special" plugins are not too weired,
=09Siggi
|