[MPlayer-G2-dev] RFC: commandline syntax

[Arpi]

Hi,

Before we start flaming about commandline parsing is UI's job, of course it
is. But we have to prepare core libs and config code to serve it.
And anyway defining a standard (reference) syntax for g2 libs is not a bad
thing, imho. And anyway 2, we should implement a simple CLI for testing g2
libs (sth like current test-play.c).

Ok, the topic of this thread will be the reference (recommended) commandline
syntax. Ie how to pass arhs to the core libs, modules/plugins.

AO/VO
~~~~~
In case of ao and vo, i would keep the old (g1) syntax, with the little
difference that 'subdevice' is now parsed by the config layer instead of
sscanf and such mess. I've already updated libvo2 to use it.
Libao2 isn't update dyet, but 1. Anders promised some libao3? 2. we need to
change libao2 API anyway to get rid of ao-data and such globals, so we can
do the ao_info=>module_info change at the same time.

So the syntax is -vo driver1[=[param1=]arg1[:[param2=]arg2...]][,driver2][,]
In short: oen or more drivers (even teh same driver with different args,
for example -vo mga:/dev/mga_vid1,mga:/dev/mga_vid0) can be listed together
with their optional args (which may be just arg-list (like g1's -vf syntax)
or named params (like g1's subconfig) or the combination of them).
The list may be terminated by a comma (,), it means that non-listed drivers
should be tried too.

AF/VF
~~~~~
For audio/video filters, imho g1's -vf syntax is still ok:
-vf filter1[=[param1=]arg1[:[param2=]arg2...]][,filter2][,]
(so it's the same as ao/vo but lists filters instead of drivers, and all the
filters are loaded/inited/used not only the first available one)
It's implemented for video filters in g2 (ok it's buggy as it uses reverse
(-vop) order but -vf name :)). I plan to redesign audio filter layer, so i
left it for now.

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.
Maybe an -vdopts/-adopts can do the job? see bellow at stream.

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

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.

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.

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

ok, enough for today. happy brainstorming :)


A'rpi / Astral & ESP-team

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