Re: xine's future and DVD Menues (was: Re: [xine-devel] My two cents... :-))

[Siggi L. <lan...@fa...>]

Hi G=FCnter,
Hi everybody,

On Thu, 1 Mar 2001, Guenter Bartsch wrote:

> On Thu, 1 Mar 2001, Rich Wareham wrote:
>=20
> > OK then following is based on some cursory examination of a few docs an=
d I'm
> > still trying to get my head around the details (oh and pass my degree c=
ourse
> > :)). Firstly I agree that DVD menus are a Big Thing (TM) to get into ou=
r
> > 'Killer App'. However we must decide is Xine is to become more a DVD pl=
ayer
> > that can play other movies or a movie player that happens to play
> > (unencrypted by default) VOBs. <My 2 pence> Personally, I think it is b=
est to
> > concentrate on the latter until Xine has been matured and split into a
> > library (libxine?) as per the roadmap. Then a stand-alone DVD player co=
uld be
> > built without changing Xine too much.
>=20
> yep, I absolutely agree with that. I have thought a lot about the future =
of
> xine in the last few weeks and I think we should go for the "Media Player
> that can play DVDs" direction.

Hey, fine! So xine won't stay too minimalistc.
But what's the use of OMS in that case? *duck*

> Splitting xine into seperate modules is one of the top priorities on my
> personal TODO list. While updating libmpeg2 I found that the way video_ou=
t
> is connected to the GUI and the codecs is a bit of a mess so I'm cleaning
> that up at the moment. The next thing will be to clean up the xine "core"
> <-> gui interface. What I have in mind is a structure like this:
>=20
> video_out_drivers  audio_drivers
>    |                |
>    |                |
> video_out          audio_out     audio/video codecs      gui
>    \                     \       /                      /
>     \                     \     /                      /
>      ------------------- xine core --------------------
>                          /      \
>                         /        \
>                   demux_plugins  input_plugins

There are some details missing:

Where's libspudec? We don't want to miss subtitles...

Some kind of navigation abstraction layer should be provided, so xine can
support interactive menus and such. And I wouldn't necessarily restrict
that to DVDs. Interactive menus would even be a cool feature for
playlists, even if they only refer to files or VCDs.

The gui should be splitted into a general UI abstraction and UI
plugins. One plugin could provide the themed GUI, another one could
provide LIRC (infrared control) support. Maybe KDE or GNOME GUIs would be
useful as well.

So we have something like this:

video_out_drivers    audio_drivers
             |            |            =20
             |            |            =20
          video_out   audio_out    a/v codecs
                \         \         /           ui -- ui_plugins   =20
                 \         \       /           /
                  -------- xine core ----------
                 /         /               \
                /         /                 \
       demux_plugins   input_plugins       navigation_interface
               \                               /
                \............................./


(looks a bit complicated, especially the navigation interface needs some
clear design)

> all these modules should have clean interfaces and should only communicat=
e
> with xine core - which will be a bit abstract then, but it looks worse
> than it really is. Then, you'll be able to replace all these components i=
f
> necessary if you want to build a xine for a specific purpose.

Amen!

> I guess the gui will be the top candidate for replacements - perhaps
> somebody wants to build a gnome/kde media player by replacing the gui,
> somebody else mentioned using xine without X (we'll need a framebuffer
> video_out driver, but that one should be easy to code when I've finished
> my new yuv2rgb scaling code). I hope this will also help the dxr3/h+
> spinoffs.

That's why I suggested the abstract ui interface.

> Besides that we'll have greater flexibility be introducing dynamic linkin=
g
> for some of these modules, we have it already for input und demux plugins=
,
> but I could also imagine somebody wants to link a specific gui at runtime
> or a special video_out module.
>=20
> I also hope that we'll be able to have more independant maintainers for
> these modules so I won't be the bottleneck of all xine developement in th=
e
> future (sorry - but my time is limited and, believe me or not, I'm very
> unhappy with the delay I'm causing for the 0.4.0 release at the moment).

good point.

> > I've been looking into DVD menus, however, and found that the IFO parsi=
ng is
> > not the most critical part. Xine as it is can parse, or partially parse=
, IFOs
> > (or at least handle plugins that do). The final thing we need is parsin=
g of
> > the (and this is my early morning memory here so name might not be righ=
t)
> > Presentation Control Information packets (PCIs). These are embedded int=
o the
> > VOB (like subtitles, AC3, etc) and encode things like 'pause here for 1=
0
> > frames' or 'jump to block 4524'. It is these which allow, for example, =
the
> > looping menus in 'The Matrix' or the single frame displays in the bio's=
 of
> > people.
>=20
> wow - now that really brings some light into that issue, really
> interesting stuff. I wonder if we could simply implement that into the
> xine "core" engine - is the information about these data structures
> publicly available or where did you get this from? Does anyone happen to
> know the legal status (license, patents...) of parsing this?

Looks like the navigation system needs to interface to the demuxer as well
as the input plugin. This doesn't really look nice, but maybe, Anyone has
a good idea...

> PS: please try to use expressive subjects on the list - I've really some
> trouble reading the xine and the other (mpeg2dec/livid) lists and
> filtering the interesting parts out

Or loud & clear: USE MEANINGFUL SUBJECTS!

Regards,
=09Siggi