[MPlayer-G2-dev] Re: Data communication between demuxers and UIs

[D Richard Felker III]

On Thu, Jan 22, 2004 at 04:13:36AM +0200, Fre_ax wrote:
> >> > I see no reason playlists are a "config" item. Rather, a playlist is
> >> > a list of sources and configurations for playing them. Some users
> >> > of the mplayer-g2 core will want to have playlists, but for others
> >> > it makes no sense, or needs to be treated differently, so I'm
> >> > opposed to putting all kinds of playlist nonsense into the core.
> >> So lets rename it to "data layer" and add seperate directory types
> >> for config data
> >> and playlists.
> >
> > Config does NOT fit into nice little directories like you imagine. You
> > have little understanding of the config requirements it seems.
> 
> Yes im having trouble understanding how adding directories would make
> everythingincompatible.

Explain for us how you configure audio and video filter chains with
your directory system.

...and nonlinear ones?

> >> > I don't like this whole "directories" thing. It's windowsish,
> >> > bloated, and forces a particular system on the caller which won't
> >> > be
> >> > appropriate for anything but gui players with playlists.
> >> True but who says the command line interface would need to open this
> >> playlist directory and activate(generate entries in side the
> >> directory) this code at all?Of course these directories wouldnt even
> >> exist if user wants no guis. So you think its nicer to have tens and
> >> tens of options without grouping them atall ?
> >
> > No, if you'd read any of the previous material on the config layer
> > you'd notice that it's all associated with instances of something, not
> > horrible globals like in G1.
> 
> Good, so g2's config system is now good and capable of taking care of future
> needs ?

Yes the config system is already good. Please read the work that's
already been done before trying to reinvent it.

> >> what do you mean by bloated exactly?
> >
> > Dependency on an extra layer which isn't needed.
> 
> I believe its needed for option groups. The command line interface is JUST
> another UI with some special needs. If you disagree with this then you are
> discriminating other UIs.

Good. :)
It's not that I want to make things difficult on the gui fans... ;)
but command line/config file option=value type stuff is somehow
special (and imo much more important since the gui stuff will be built
on top of it with extra hints to govern ranges, grouping, etc.)

> Dont get me wrong iv seen these media players for linux come and go

I've seen one usable one come and some other nonusable ones (too slow,
X-only, buggy/crashing, etc.) go...

> so i understand that in mplayer g1 command line interface is superior but
> thisis g2 we speak of.
> This way adding new options can be done by editing just ONE file BTW.

Huh? No way. The options can't all be in one file because they belong
to different _independent_ modules. Independence of the modules is one
of the key goals of g2.

> > In fact when the config system was first discussed, one of the major
> > proposals that caused lots of flames was tightly integrating the
> > config system with gui/app/playlist stuff. The final decision was to
> > layer the config system, with the basic levels only defining data
> > structures and functions for manipulating config, and only putting the
> > gui/app stuff on the very top (and totally optional) layer.
> 
> Again if you guys think g2s config system is now good, i can just as
> well implement this system for playlists only.

Yes. Your idea may very well be good for playlists.

One obstacle though is storing with your playlist the necessary config
to represent the rendering pipeline (audio and video filters, etc.).
Depending on how we want to do this, it may affect the generality of
your playlist system, and that in turn provides a good reason why the
MPlayer core shouldn't depend on the playlist system.

For example most players may not care to support multi-file input
streams with filters to merge them, so maybe the playlist shouldn't
either. It seems to me this sort of feature is mainly useful in an
editor/encoder app instead. On the other hand, maybe someone would
find it useful. I don't know the answers to all these questions right
now, so I'm trying to work on the lower-level stuff that really
matters right now so we can defer decisions like this until after the
basic code is in place and working.

> >> Adding new entry type that contains codecs_t or similar structures is
> >> no problem.
> >>
> >> I do agree that its useless to implement this system if both dynamic
> >> and static configs(including relevant data communication with these
> >> structs) cannot be handled by extending this system.
> >
> > What on earth is a dynamic config??
> 
> Static you mean? Say configuration that cannot take place when
> playing files. This of course makes no difference for guis as all
> configuration can be considered to be dynamic.

Oh, ok. I thought you were talking about extra options that somehow
"dynamically" came into existence later on.

> >> I would however want to remind you that this system solves problems
> >> with DVB playlists, dynamic configuration and probably some other
> >> things.
> >
> > It doesn't solve any problem with dynamic configuration. The difficult
> > end of dynamic configuration is the other end, the implementation.
> 
> I take that back, it implements dynamic configuration.

IMO it doesn't do that. Anyway, there are two ends to dynamic
configuration. The end you (and the other config people) are trying to
"solve" is the trivial end, the api for the UI to use to reconfigure
options. There's nothing difficult about that at all. The difficult
end is "repairing" filter chains, renegotiating link parameters, etc.
to accommodate changing options.

> > As for DVB playlists, WTF is so special about them? How are they
> > different than any other playlist?
> 
> DVB channels arent real files but rather io calls to kernel land.
> This is currently done with libmpdemux/dvb* files in mplayer g1.
> 
> Also i would be willing to partly(or entirely) implement curses based mplayer
> after/if you get this dynamic config stuff sorted out. Or would it be
> better ifthere would be GUI in the playback window ?

UI in playback window would be much better, IMO. How are you supposed
to see the curses interface if there's a movie in front of it? :)

On the other hand, since it might be useful sometimes (windowed
playback under X only) you could make a curses interface, and then add
a terminal-emulator to MPlayer. :))) So MPlayer could run its curses
gui inside its own terminal emulator which displays overlaid onto the
movie... ;)

Rich