Re: About final cfg.h (config layer 0 discussion)

Hi,

> 1. Why did you dropped CONF_TYPE_SUBCONFIG ? I've just noticed that. It's
>   because all such options are modules parameters and you want to parse
>   they by different way?

yes
there is CONF_TYPE_MODLIST now
it handles -option module1[=[paramname=]param1:param2...][,module2=...]...
format options (like -vf, -vo, -ao etc).
the 'priv' field of the config_t entry points to a function which retrieve
module_info_t* for a named module (ro NULL if it doesn't exists).
the result (config_t->p) is stored in a config_modlist_t array, which
contains module_info_t* and config_data_t* for each entry.

see -vf in pre29. pretty clear and simple!

anyway there is subconfig parser func in layer-1, used by CONF_TYPE_MODLIST
parser too. so adding subconfig support is just a few lines, but until we
find a good reason for it i don't add.

imho we should keep g2's commandline syntax as consistent and logical as
possible, it also means avoid subconfigs.
as you (and others) said, subconfig in g1 was to pass module-specific stuff.
since it's now handled in clean way (MODLIST, MODULE types) it has no use.

> 2. Do you still have something to argue about CONF_TYPE_LIST option type?

isn't my CONF_TYPE_SELECT the same?

> 3. Will we change CONF_NOGUI to CONF_NOUI ?

i like Rich's answer - UIs producing visual option lists are considered
GUIs, even if they are actually CUI :)

> 4. Let's change unsigned short type, version to unsigned short version,
>   type in module_info_t definition to have compatibility forever. :)

no
i'm thinking about add type-specific versions
so if we change vf API we don't have to force demuxer, stream, vo etc plugin
authors/users to recompile their plugins just to get version number bumped.

>     Discussion about CONF_TYPE_GROUP isn't my concern right now since
> that option is application level only and it's marked as TODO anyway. :)

actually i've added CONF_TYPE_MODULE which does the same as you expected
from CONF_TYPE_GROUP.

>     Also about how to apply new config level 0 to video filters (and to
> all other in the future, of course). We have to describe how parameters
> will be passed to modules. So:
> 
> 1. vf_open_filter(), vf_open_encoder(), and vf_insert_filter() functions
>   have to get not char *args but void *args and that void * have to be
>   preallocated array with parsed parameters (see module info);

of course, it's already changed (see pre29)

> 2. we have to introduce VFCTRL_GET_PARAMS and VFCTRL_SET_PARAMS requests

yes, it's a TODO

>   for vf->control(). These requests will have void *data as parameters
>   array, preallocated by caller: for VFCTRL_GET_PARAMS it's array with
>   undefined values and filter has to set all changeable parameters there;
>   VFCTRL_SET_PARAMS will ask the filter to apply changed parameters to
>   the instance. Size of that array defined by config_size in module info.

imho VFCTRL_GET_PARAMS is useless.
config_data_t* (the struct containing the preallocated config vars)
is part of the instance structs (vf_instance_t), and is used by the filter
to keep the config data. (ie it's free()'d only at filter uninit).

it's always readable by upper layer (so VFCTRL_GET_PARAMS is useless), but
we should add VFCTRL_SET_PARAMS (or better name) to notify filter about
config changes made by UI. i'm not completely sure about this one yet.
(runtime config change is always a mess...)

>     It must be documented before we have all filters/encoders ported from
> G1 since it'll be huge headache after that. ;)

yes

and we (i) should migrate the already ported modules first, so we can test
(and find errors in) new config layer, and give some nice examples for
porters.

>     For example, I want to port vf_dint.c to G2 but I still cannot until
> we decide all above and I wait for it...
> 
>     BTW, we have in VF API functions for inserting filter into begin of
> chain and to somewhere inside chain but how about adding filter at the
> end of chain? May be better is something like:
> 
> vf_instance_t* vf_insert_filter(vf_instance_t *last, vf_instance_t *next,
> char *name, void *args);
> 
> which will insert filter between instances last and next, and so if
> last==NULL then we'll insert filter at begin of chain (as vf_open_filter
> does) and if next==NULL then we'll add filter at end of chain. I think

no
but i'l mayeb rename functions to insert_above and insert_below instead of
append and insert.

> it's the best way to do it. BTW, with new layer 0 concept it may be more
> correct if we will use module_info_t* instead of char *name.

of course. see pre29...

A'rpi / Astral & ESP-team

--
Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu