[xine-user] RE: [xine-devel] New DVD input plugin (fwd)

[Guenter B. <bar...@st...>]

Hi there,

On Fri, 13 Jul 2001, Rich Wareham wrote:

> Secondly, a forward of an e-mail to James about some things we need in
> Xine for doing NAV. Guenter, is it OK for us to have a NAV decoder in Xine
> itself? Is that compatible with Xine's no-CSS / non-free DVD code
> strategy?

not really. If there's no (resonable) way to implement menus without doing
this, I'd give my ok. But I'd rather like to see this stuff, which is
absolutely DVD-specific, done outside xine. Below you're already proposing
a message-based system in xine to implement menus, I think this is a
really good idea and this should help us keep all the DVD, MicroDVD, VCD
Menu specific stuff outside of xine and pack it into the input plugins.

This is not only legally safe but also a very nice, clean design IMHO.

> I agree with that, its just I didn't have time last night to implement the
> required stuff in Xine for this. If no-one has any objections I'll try to
> make the Xv output plugin support the mouse event stuff in input API v2.

I think mouse events / keyboard input shouldn't be handled by the
video_out plugins but by the gui. So I propose we add a

xine_deliver_input (xine_t *this, int type, data...);

call to the xine-lib API so the gui can deliver these events (remember
that the video_out plugins do _not_ handle the video_window but just do
the plain drawing, the video window creation, resizing etc. is completely
handled in the (g)ui).

> > We need to really think of what the best way for all this will be.
> > I think that we should have 2 methods.
> > 1) have a decoder plugin for nav.
> > 2) have the input plugin for nav.

again, I vote for the second option. The nav stuff is DVD-specific.
Besides that I think it'd be nice to offer a single completely
self-contained DVD plugin, not two - but the final decision of all this is
of course up to you or whoever will take the (legal) risc to distribute
such a plugin.

> I think generally that some sort of message passing system would be good
> rather than keep adding API calls. For example, the video out plugin could
> register istelf as wanting to receive 'MENU' messages and metronom could
> register itself as wanting to receive 'SYNC' messages. The NAV decoder
> could then simply send off messages as it decodes the NAV packets and the
> required plugins would listen. In this way, the NAV decoder doesn't need
> to /know/ what to do if a re-sync is necessary, it just sends out the
> message.

basically a good idea, I'd just simplify it a bit - I don't think we need
message passing within the xine engine so we can simply limit this to
messages passed from the input plugin to the demuxer which then inserts
these messages into video_fifo and audio_fifo. I'm not sure about
metronom/sync messages, but I guess they could simply go into the
video_fifo as well.

> > One problem is the demux buffer. Delaying what the input plugin sends, to
> > what is actually on the screen.
>
> This is why some sort of 'FLUSH' message would be good. With a straight
> API, each plugin (video, metronom, audio, etc) would have to be flushed in
> turn when we jumped but with the message passing system, each plugin could
> just listen for 'FLUSH' messages.

humm ... that could become a bit tricky due to the various buffers between
the plugins. While the demuxers work "in the far future" the video/audio -
decoders work in the near future and the video_out loop works "at present
time", so resetting all of them at the same time will lead to a gap in
playback as some (p)re-buffering will take place until new output will
appear on the screen/speakers.

> > Have you got any ideas on a menu API ?
>
> Since the menu stuf is v. low bandwidth, I think it can be done with the
> message system. E.g. the NAV plugin might send the following messages:
>
> 'BEGIN MENU TRANSACTION (PTS = xxxx)'
>
> 'HIGHLIGHT DATA = (spu stream, colour, etc)'
>
> 'MENU BUTTON x1,y1,x2,y2 NUMBER xxx'
> .
> .
> .
> .
>
> 'END MENU TRANSACTION'
>
> Then when button number xxx is pressed, either the co-ordinate could be
> passed to to the NAV plugin, or the button number, whichever turns out to
> be more useful.

I don't think the xine-engine should handle the buttons, it doesn't even
have to know about them so I'd deliver keyboard/mouse-events(coordinates)
to the input plugin which knows all about it's specific menu
implementation.

We'd then only need quite simple menu messages like

- STILL TIME
  a time might be secified here or a special value telling
  the xine engine to "wait until further notice" - this would be
  necessary for still menus that wait for the next user input
  the video_out plugins should make a backup copy of the current
  image upon this message because changing overlays are to be expected
  metronom should stop it's clock here (for the amount of time if given)
  and set a flag for audio_out to continue playback unsynchronized

- SET_OVERLAY
  package should contain the overlay data (packed / unpacked)

- HIGHLIGHT_RECT
  I'd add this for debugging purposes so for a first try you don't have
  to work with full-featured changing subtitles but can simply
  use this command to highlight the current menu button

Cheers,

   Guenter

--
time is a funny concept