[MPlayer-G2-dev] g2 config - restart...

Ivan Kalvachev ivan at cacad.com
Wed May 14 00:00:34 CEST 2003


It looks like am too late with my drafts
anyway i see that many of the ideas i had have
been introdused. Anyway i send it as
attachment, maybe there are still good ideas

Ivan

Arpi said:
> Hi,
>
> (pre-note: Andriy please don't offend Albeu, he seems to understand the
> actual problems and solutions better than you...)
>
> Ok I guess we want to much from the config api.
> Actually wanting _a_ config api is alreayd too much.
> Better separate it to layers, like the rest of teh code
> (stream/demuxer/decoder/filter/ao/vo for example).
>
> the layers may depend only on eachother.
>
> imho the first layer should be a very lowlevel one, as all core libs
> will depend on it. ye syou read it right, i said depends.
> and even if you're saying no core dependency on config layer you still
> defien structs and parameters inside core plugins so you lie :)
>
> ok, back to the reality. let's define things:
>
> config layer 0 (any better name?):
> ==================================
> It's actually only a concept (==documentation) and 2 structs. No code.
> (why are you surprised? :))
>
> This is teh only layer on which teh core libs may depend.
> This layer is responsible to tell the library user about teh available
> options/parameters and their type, valid range. In Albeu's terminology
> it exports the C-types.
>
> One of the structs is the good old (with possible changes to make it
> better for g2) struct config, aka config_t etc. So that one which you
> use to define the possible options.
>
> The other struct is a very simple struct to keep all info we want to
> know about a module/plugin/layer. It's inspired by Andriy's common
> generalized plugin_info thingie. While his idea is basically good, he
> wanted to generalize the whole instances types (like vf_instance_t),
> afair.
> So we could define a common structure to keep the pointers of config_t
> struct (and related data: pointer to default values struct and struxt
> size) and as a bonus, it could keep:
> - type of the module (like: core, stream, demux, vd, ad, vf, af, ao, vo
> etc) - (short) name of the module
> - plugin filename (NULL for core and built-in/compiled-in modules)
>   (in first draft i wanted filename to be computable from
> type+shortname, like type==vf + name==scale -> filename=vf_scale.so,
> but then i find several nice uses of different plugin names, like
> multiple versions of the same plugin co-exists, etc)
> - credits related stuff (maintainer and author name/email/url/whatever)
> - long (one line?) description (for GUIs and automatic -help screens)
>
> Then redesign the current core APIs to base the vf_info_t etc on these
> structs. Some APIs already have some such info_t structs, so it's easier
> for them.
>
> Each core library should have an array of its built-in (static) modules,
> and a separate struct describing itself (the library may have "global"
> parameters, which belongs to the library itself (to control how to fins/
> insert plugins or whatever) not to one of its specific plugin!
> for example, for demuxer layer you have parameters to control the
> autodetection process (extensionbased, contentbased, forced demuxer,
> list of preferred ones etc), other example is stream layer's -cache
> parameter)
>
> so what about libdemux exporting plugin_info* demux_core_info and
> plugin_info** demux_modules_info, and so on for every library.
>
> config layer 1:  core libs configuration helper functions
> ===============
>
> you may ask now, what about the dinamic (dlopen'ed) plugins?
> we could write a helper function (probably as part of the config layer
> core) to scan a whole plugin dir(-structure) and read the above
> plugin_info structure from each plugin. it could include some kind of
> cache, as Michael proposed. if the UI (it may be CLI's -vf help kind of
> option, or GUI's dropdown combobox) needs the list of available
> modules/plugins, it can additionally call this function to get info
> about dinamic (optional) plugins. it's fully optional, UI only calls it
> if it wants, no one (esp. not the config parser!) will call that
> automatically at startup.
>
> also there should be a function to get plugin_info of one named plugin.
> it could also use the cache, or just dlopen() that plugin.
> this function could be used by CLI's what directly name the plugin to
> load (like -vop foobar=1:2:3 means that we should try to load
> vf_foobar.so)
>
> layer 2 will handle the lowlevel parsing, ie. string -> C-type
> conversions, =========================================
> based on config_t structs. it will provide simple functions to parse
> options from sing and return teh dinamically allocated (cloned from
> static 'prototype' and the parsed options then overwrite defaults)
> ((there could be an optional prototype arg of the func, so UI can
> override the static prototype by some other, like configuration
> inherited from upper level, aka configtree/playtree)).
>
> it should also implement the opposite, ie C-type -> string conversion,
> for config file saving etc.
>
> =====
>
> Ok now we have everything for a lowlevel API, so if we have parameters
> (in string format!!!) for various plugins, modules (like vo_subdev, vf
> args, etc) we can do this while building the framework (path of layers)
> we'll use:
>  - retrieve layer/module/plugin's plugin_info (see layer1's 2nd func) -
> call layer2's parser func to transfer string to config structure, also
> do
>    error/syntax checking and handle fatal errors (fail-out)
>  - call the layer/module/plugin open() with the config structure as
> parameter
> repeat this for every layer/module initialization.
>
> =====
>
> to be continued... :)
>
>
> A'rpi / Astral & ESP-team
>
> --
> Developer of MPlayer, the Movie Player for Linux -
> http://www.MPlayerHQ.hu
>
> _______________________________________________
> MPlayer-G2-dev mailing list
> MPlayer-G2-dev at mplayerhq.hu
> http://mplayerhq.hu/mailman/listinfo/mplayer-g2-dev


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: configdrafts.txt
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-g2-dev/attachments/20030514/46681d7a/attachment.txt>


More information about the MPlayer-G2-dev mailing list