Re: RFC: commandline syntax

Am Montag, 26. Mai 2003 01:41 schrieb Arpi:
> Hi,
>
> AO/VO
> ~~~~~
>
> So the syntax is -vo
> driver1[=[param1=]arg1[:[param2=]arg2...]][,driver2][,]

I vote to keep that one.

>
> AF/VF
> ~~~~~
> For audio/video filters, imho g1's -vf syntax is still ok:
> -vf filter1[=[param1=]arg1[:[param2=]arg2...]][,filter2][,]

I agree.

>
> Ok we're over the simple things.

:-/

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

>
> STREAM
> ~~~~~~
> It'ts tricky. Currently the stream driver to be used is determined from
> the url. If it has prot://... syntax, then stream_prot.c is used (if
> exists, otherwise dummy stream handle is created for stream-less
> demuxers...). If it has no prot://... syntax, it's assumed to be plain file
> or stream (==non-seekable file, like stdin or pipe).
> Ok it's not so simple. Plugins may be named differently than url:// syntax,
> to allow multiple plugins to handle same url (for example rtsp:// or rtp://
> cases, when there is live.com, real-rtsp and dvbstream's rtp).
> So, we also need a way to explicitly name (or list in order) the stream
> drivers to be used.
> There is 2 methods to pass config:
> 1. -stream [option1=]value1[:option2=value2...], ie g1-subconfig syntax.
>   it will allow options for single driver/plugin only, and will eb applied
> to the driver selected based on url/type.
> 2. -stream driver1[=[option1=]value1[:...]][,driver2...][,], ie. ao/vo
> syntax

I vote for 2.

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

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

>
> DEMUX:
> ~~~~~~
> After writting the above lines, i guess it's the same case as stream.
> Maybe we should extend the syntax (both stream & demuxer, but it could
> help in codec acse too) somehow to allow out-of-order configuration.
> Ie list various plugins with their config/args, but _without_ changing
> the order 'hardcoded' in the core libs or codecs.conf.
> It could be different option (like -demuxopts or -demuxconf) or some
> special sign in the option list to note it's unordered, for example
> -demuxer !mpeg=maxpkt=8192 would mean use maxpkt=8192 for moeg demuxer,
> but do not raise mpeg demuxer to top priority.

Hm, I like -demuxopts better if one just wants to configure the demuxer.

>
> I'm interested in comments, better ideas, i'm not too good in CLI design ;(
> Also we should discuss/decide if we keep CLI somewhat compatible/consistent
> with g1 or redesign (option names, syntax) from scratch?
> Imho g1's syntax is not as bad, with the above things decided it could be
> usable. Also keeping g1's syntax will make migrating easier for users,
> and even for developers.

yes :)

>
> Ah, and yet another thing: currently the cfg-parser is very strict, if
> you do synatx errors, list non-existant modules/plugins, it will exit with
> error. 

I already oticed this while trying to use -vop pp :)) (-vf pp did of course 
work)

> Imho we should find some nice way to handle existing but
> non-available options (like -dvd without dvdread support compiled in
> (YES i know it's wrong example for g2...)), and non-existant (or
> non-available, == not compiled / downloaded plugin) plugins.

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.

> For example, g1's -vop allwoed to list non-existant filter, and it didn't
> even fail, just printed warning message that that filter doesn't exist and
> is ignored.

that is good :)

cu

Fabian
>
> ok, enough for today. happy brainstorming :)

lightning/thunder ... *roll*

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