From: mail@SendSpamHere.ORG
On 2025-02-14 13:38:59 +0000, Simon Clubley said:
> On 2025-02-13, Lawrence D'Oliveiro 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-i
put-options-2»,... -
>> «outfile-1»/«local-output-options-1»,«outfile-2»/«loca
-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
--- SoupGate-DOS v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
