Re: RFC: commandline syntax

Am Montag, 26. Mai 2003 02:23 schrieb Arpi:
> 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.

hm, ok

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

hm, I understand now.

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

ok, understood.

cu

Fabian

PS: Sorry for being off-topic, but are there other stream-things left to port 
?

>
>
> A'rpi / Astral & ESP-team
>
> --
> Developer of MPlayer G2, the Movie Framework for all -
> http://www.MPlayerHQ.hu
>
> _______________________________________________
> MPlayer-G2-dev mailing list
> [email protected]
> http://mplayerhq.hu/mailman/listinfo/mplayer-g2-dev