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

[Fre_ax]

>> >> > 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?

Remember that entry_set function pointer in struct cfg_host ?

This funtion would also allow "config hosts" make further changes to the
configuration.

int (*entry_set) (struct cfg_entry *entry, struct cfg_entry *new);
Would change to:
char *(*entry_set) (struct cfg_entry *entry, struct cfg_entry *new, struct
cfg_entry *root_dir);

Text returned by this "activate option" function could then be showed to the
user
on error cases.

This together with host side callback function should take care of it. ;)
Of course im not sure as i dont know how these things work in reality.

>> >> > 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.

Im exactly reinventing this for my own needs as im working on something that
will
need lots of options and functions to make it work with plugins.
However im still claiming that my system would be adding other than
directories.
>> >> 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... ;)

Im no gui fan! :D
I just see having around 1000(half of them dont even work) channels kinda
troublesome to handle and group with emacs. ;)
Sure there are some programs that can do it but they are all, as far as i
know,bad solutions as they dont directly handle this stuff inside mplayer.

> 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.)

>> 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.

No, not that way. Each module would of course define their own stuff.
What i mean is that UIs would just "render" this directory(module) as they
want.
>> > 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.

Agreed. I see creating new channels can be a problem and thats why i think
playlists should be allowed to optionally define the representation of this.

I mean if dvb, http and ftp gets implemented this way why wouldnt normal
filesystem ?
But then again, would it work ?
That would the command line interface think about this ?

I do think that guis should not be given more than bunch of config_t's to
represent
the outlook of the options.

>> >> 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.

I believe this could be possible since this "activate option" function at the
configuration client side can make further changes to the configuration.
Again im not sure as i havent been reading mplayers sources much.

>> 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? :)

Yes and this would be pretty useless for console users with framebuffers.

> 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... ;)
Hehe.
Yah, im not sure how curses works but as far as i can remember it only allows
users to set chars at x, y location on screen. So this
"show-on-screen"-functioncould just as well be function pointer that can be switched when using
different UIs.

--Aapo Tahkola