[Info-vax] Local Versus Global Command Options

[Brian Schenkenberger]

On 2025-02-14 13:38:59 +0000, Simon Clubley said:

> On 2025-02-13, Lawrence D'Oliveiro <ldo at nz.invalid> wrote:
>> 
>> What?s the most complex *nix command you?ve come across? I think it
>> has to be ffmpeg. This looks broadly like
>> 
>> ffmpeg «local-input-options-1» -i «infile-1» \
>> «local-input-options-2» -i «infile-2» ... \
>> «local-output-options-1» «outfile-1» \
>> «local-output-options-2» «outfile-2» ...
>> 
>> The convention is that options apply to the immediately following file
>> specification: this is prefixed with ?-i? for an input file, and is a
>> plain argument for an output file. Note the lack of ?global? options:
>> all settings apply to a particular file.
>> 
>> But that?s not where it ends. Certain of the options can specify
>> ?filtergraphs?, which are entire chains of effects operations to be
>> applied to a particular video or audio stream. The man page talks
>> about ?simple? versus ?complex? filtergraphs, but even the ?simple?
>> ones can be pretty complex.
>> 
>> Filtergraphs can also be used during real-time playback, with the
>> ?ffplay? command. For example:
>> 
>> ffplay -autoexit -vf scale=1152:864,setsar=0.9 \
>> 'Sun Is Shining (Official Video).mp4'
>> 
>> That ?-vf? option specifies a sequence of video filters, first to
>> scale up the video to make more use of my screen, and ?setsar? (?Set
>> Source Aspect Ratio?) to fix distortion in the shape of the image
>> (everybody looking squashed) from the original digitization of the
>> video.
>> 
>> What would DCL-style syntax for ffmpeg look like? I suppose one
>> obvious equivalence would be
>> 
>> ffmpeg -
>> «infile-1»/«local-input-options-1»,«infile-2»/«local-input-options-2»,... -
>> «outfile-1»/«local-output-options-1»,«outfile-2»/«local-output-options-2»,... -
>> 
>> (being very careful about where the commas go), but what about the
>> syntax for filtergraphs? Would it be something like
>> 
>> /vf=(«filter-name-1»=«filter-params-1»,«filter-name-2»=«filter-params-2»...)
>> 
>> Does DCL have provision for this sort of complexity?
> 
> Not in any meaningful way. There's no way to validate the syntax or
> parameters of a filter or other ffmpeg syntax with DCL. For a simple
> example, when merging two files, one with an audio stream and one with
> a video stream, into a MP4 output container then specifying the input and
> output video stream numbers would be a parameter along the lines of "0:v:0".
> 
> How would you even specify in DCL the first and last fields are numbers
> and the middle field is a letter from a list of valid values ?
> 
> You can use DCL syntax in the way you specify, but the vast majority
> of the parsing would still have to be done in ffmpeg as it is at the
> moment. DCL syntax doesn't really give you anything extra.
> 
> Similar comments apply to mplayer BTW, and to make something clear to
> people reading this (which is only implied above), the filters MUST be
> executed in the order given. For example, with mplayer, I might first
> use a crop filter to get rid of black bars within a frame and then
> apply a scale filter to the resulting frame.
> 
> Simon.

If you want to maintain the klunky un*x command syntax, employ a finite 
state parsing table and LIB$T(ABLE)_PARSE. Otherwise, devise a better 
and more sane syntax to specify and pass myriaD arguments with 
qualifiers and parameters thereto.

Your anti-VMS sentiments are one of the reasons why my life has been so 
much more enjoyable because I haven't been reading c.o.v daily.

– VAXman