[MPlayer-dev-eng] demux_mf: improve format string processing

[Alexander Strasser]

Hi Erik!

On 2021-04-28 10:18 +0200, Erik Auerswald wrote:
> On 28.04.21 08:47, Alexander Strasser wrote:
> > [...]
> > Not sure when or if it will ever happen, but as a first step in
> > that direction I will start with a documentation for the current
> > state of mf:
>
> If you do re-implement this functionality, it might be nice to
> have a way of "quoting" special characters.  This is just a
> suggestion, of course.  I'll add some details below.
>
> If you do re-implement this functionality, and if you do add
> some kind of quoting mechanism, I would prefer consistent
> quoting (at least) inside the <mf spec>, e.g., a backslash
> ('\') removes the special meaning from the following character,
> including "\\" to get a single backslash ('\').  As opposed
> to, e.g., doubling special characters if they shall be taken
> literally in one of the sub-specifications.
>
> (I did not check if MPlayer already supports some kind of
> quoting, since I have not yet needed something like this.)

Agree. That will need some serious thinking though.

Regarding your following comments, they cover mostly what I
thought when reading the code and even some more aspects.

The most annoying thing is probably that you can't avoid the
<comma delimited paths> interpretation. E.g. if your files
contain a `,` in their names, you need to rename them or put
them in a list file and load that with @<list file> or use
a glob pattern that hides the `,`.

For my taste mf:// works a bit too much in the do-what-i-mean
fashion. That's fine and simple for ad-hoc usage most of the
time, but it's not very nice if you want to use it e.g. out
of another program.


Thanks for your thoughts on this,
  Alexander

>
> > ---8<---
> >
> >      mf://[<mf spec>]
> >
> > The *mf spec* is a specification from which the input paths should be
> > deduced. It can be one of these:
> >
> >      <glob pattern>|<printf format>|<comma delimited paths>|@<list file>
> >
> > If the *mf spec* is left out, a shell globbing pattern of `*` is used.
> >
> > ## list file
> >
> > If the first character of after *mf spec* is `@`, the remaining
> > characters will be used as a path to open as a file.
>
> If a file name starts with '@' this can probably worked around
> by using "./@...", thus quoting does not seem to be essential
> here.
>
> > If the file is
> > readable, each line will be interpreted as one path for the multi
> > file input.
> >
> > ## comma delimited paths
> >
> > If *mf spec* contains a `,` it is considered to be list of comma
> > delimited paths, that will be used as input paths in that order.
>
> This seems a bit more restrictive in that file names that
> contain a comma would need some way to prevent this rule
> from kicking in ("quoting").
>
> > ## glob pattern
> >
> > If it **doesn't** contain a `%` it is assumed to be a glob pattern.
>
> It might be helpful to have a method of allowing '%' in a
> glob pattern.
>
> > The glob pattern will be evaluated and the resulting list of files
> > if any, will be used as paths for the multi file input.
> >
> > If the glob pattern doesn't contain a `*`, it will be appended.
> >
> > ## printf format
> >
> > If *mf spec* **didn't** yet match any of the cases described above,
>
> So this seems to be keyed on seeing '%' and thus inferring
> a printf format string.  I would think it would be nice to
> have a method of quoting '%', but not necessarily the printf
> method "%%".
>
> > it will be considered to be a printf format string. This string
> > will be used to render an input path with a single int argument.
> > This argument is a counter starting at zero, incrementing by one
> > after each call.
> >
> > Should it happen that for, in sum, 5 of any of the rendered paths
> > the file status (stat) couldn't be retrieved, the path sequence
> > will be considered finished.
> >
> > --->8---
> >
> > WARNING: I reverse engineered the description from the source
> > code, but didn't actually test if all my assertions are correct.
>
> Thanks,
> Erik