From: James Courtier-D. <Ja...@su...> - 2001-10-05 14:21:08
|
> > 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. > In what format? One spu overlay for every possible selection? > Each MENU SPU packet contains an X,Y offset. (From the start of the actual screen to the start of the overlay image). The MENU SPU packet contains one large overlay image (Generally fills almost 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 image, 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. > > 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 actually > 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 dimension: > > +---------------------------------------+ - > | | | > +---------------------------------------+ | > | | | > | 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 DVDs > 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 another > implementation for our SPU overlays, as we can currently only overlay > buttons over the video frame... 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. > > > I currently think that the work required to select a button > should not be in > > the input plugin. > > I think it should be in xine-lib instead. > > I second that, for several reasons: > Pushing data from the input plugin to video out means a roudtrip through > several xine threads, which currently introduces a noticable delay when > selecting another button by mouse. > This is not DVD specific (some VCDs also have menus), so it shouldn't be > in the DVD(NAV) plugin. > > > I would like to implement the button highlight, button select > and subtitle > > code in xine-lib in a non DVD specific way, so that other plugins can > > control its activity as well. E.G. for On Screen displays(OSD). > > Another use for that code... > > > 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 stream. > > 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! SPU packets are DVD specific as well! 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. 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). So, half the decode should be done in the input plugin, and half the decode should be done in the libspudec plugin. > > > 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 be > 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) 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. > - maybe something for IFO data, which could be delivered directly from > 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 that > > 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/highlight > display. That code could really be used by all of them... > > > Any comments? > > Ooops, actually, more than I thought, but I hope they are still useful. > > Cheers, > Siggi > 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 from the actual video out window. (See siggy's image earlier in this email). 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. 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 with scaled window width. 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 missing out the SPU offset step. I am not sure where in xine details of the scaling is kept, but I know about SPU and NAV packets, and that info could go in the libspudec plugin. Cheers James |