Re: RFC: commandline syntax

Hi,

> > AC/VC/AFM/VFM
> > ~~~~~~~~~~~~~
> > Audio/video codecs: in g1 there is no way to pass options to codecs
> > directly in -ac/-vc/-afm/-vfm options. There is -lavdopts for the only
> > codec requiring extra config. So it's unusual that a codec have extra
> > config, so I left codec level migration for now. It's not easy anyway (i
> > have an almost-compilable version locally but it's ugly as hell due to
> > triple typecasts in function calls).
> > If we decide that we need to pass config to codecs in a generic way (ie. no
> > -lavdopts), then the question is there: how??
> > Actually codec modules/plugins are named by -afm/-vfm options, the -ac/-vc
> > options name codecs.conf entries, not plugins.
> 
> Hm, so in g1 there is no difference, between  vc/vfm and ac/afm but in g2 ?
> 
> I don't understand why it is not possible to do: 
> 
> -vc codec=parameters,nextcodectotry

becaus ethere is no module/plugin called codec and nextcodectotry.
the codec names used with -vc/-ac are not the module names, but some
config/template name from codecs.conf. teh codecs.cofn entries contain
the actual configuration for the codec plugin/module/driver.

ok it could be hacked to pass -vc xyz=hjsgja to the module, but its' ugly
hack in the config layers. (you have to send string though the codec.conf
parsing codec opening etc before you can parse it).

> > I guess we should vote for 2 (while 5 mins ago i thought 1. is better),
> > because this way we get parsig for free (automatic handled by cfg layer 1)
> > and we can explicitly name/order drivers, even the same driver with
> > different args (like -stream vcd=dev=/dev/hdd:vcd=dev=/dev/hdc, to force
> > player to try both cdrom drives when playing vcd)
> 
> Uhm, did you mean:
> 
> -stream vcd:dev=/dev/hdd,vcd:dev=/dev/hdc ?

of course :)

> Else I don't see why it is the same syntax as with -vo/-ao

it was typo (not the first one in taht mail:))

> Yes, I vote to have some possibility for a module to "pull" data out of the 
> config-layer if needed.
> 
> So not everything needs to be predicted and unknown values are just ignored 
> and stored for later use.

hmm, no... the core libs shouldn't depend on config parsers.
it was the main issue with g1.


A'rpi / Astral & ESP-team

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