[FFmpeg-trac] #1922(undetermined:closed): Broken or incomplete parser for filters
trac at avcodec.org
Wed Nov 21 17:00:44 CET 2012
#1922: Broken or incomplete parser for filters
Reporter: burek | Owner:
Type: enhancement | Status: closed
Priority: wish | Component:
Version: unspecified | undetermined
Keywords: | Resolution: invalid
Blocking: | Blocked By:
Analyzed by developer: 0 | Reproduced by developer: 0
Comment (by saste):
Replying to [comment:6 burek]:
> Well, ok, I've changed it to an enhancement, although it is an obvious
malfunction of a basic parsing feature (I've not seen a single newbee user
who figured out on his own that a comma character needs to be escaped,
i.e. it's just not intuitive to them as it is to you, developers).
It is not an "obvious malfunction", I already stated there is no bug in
the parser (at least not related to escaping), also the implementation is
behaving according to design. I already pointed out that there is no way
to workaround this at this level.
You have several filter description of the kind:
since you have some special characters (e.g. ',' to separate each FILTER),
you need some way to mark such characters if they are contained in the
filter description: the classic solution is escaping, and we adopt a
rather standard de-escaping algorithm (no wheel reinvention here) to de-
escape literal "," and other special chars contained within FILTER.
Then each FILTER can support a specific syntax (which depends on the
filter, each filter has a separate parser for that), which in turn may
need a second level of escaping.
There is nothing you can solve on the design level here, we need two
levels of escaping, you can change the escaping mechanics but cannot
eliminate the fact that two levels of escaping are needed.
> I, as a user, don't know much about internal coding problems of such a
feature, but from the outside look, this seems like it's not working well
and the first thing to think of is that it's a bug. What is really missing
in the filters parser(s) is clarity, that's so obvious and that's the
reason for creating this ticket. I just thought that parentheses could
help reading someone else's command line, which involves complex filters,
more easily than it is right now.
We could adopt a different escaping algorithm or use different special
characters, or make the special chars selectable, but still can't avoid
the need for the double level escaping.
> This logic could also be extended to ffmpeg command line in such a way
that you can group your options with each input/output, like described
> That way, there would be no ambiguity, like when you place the -ss
option in between 3rd and 4th input, and you never know if that option
will be applied to the output (slow seek) or to the 4th input (fast seek).
> Long story short, if you practice frequent workarounds instead of proper
solutions, sooner or later you'll get into this kind of situation where
you just can't change anything, because it will break something. Stacked
pile of patches and workarounds will hold the water for some time, but on
a long run, there really should be some radical improvement and API
breakage, that will resolve some fundamental problems in the coding
I object this simplistic view, which also borrows the flawed assumption
that "developers don't think hard when coding / designing", which is not
justified in this specific instance. Provided that I didn't design the
graphparser syntax myself, I don't consider it flawed, still it is not
very suited if there is the need to embed literal strings for which there
is the hardly avoidable need of understanding the escaping logic (this is
not different from other areas where multiple escaping is required).
I'm all for trying to improve the usability if there are suitable
solutions (which save backward compatibility), and tried to extend the
docs with mention of the syntax issues, and I invite you to point out what
could be improved/clarified.
I already proposed to adopt an alternative syntax (more suited for "file"
scripting)). Another solution working at a different level would be to
write a "visual" graph editor.
Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/1922#comment:7>
FFmpeg issue tracker
More information about the FFmpeg-trac