[FFmpeg-trac] #1922(undetermined:closed): Broken or incomplete parser for filters

[FFmpeg]

#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]:
 > @saste:
 > 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:
 FILTER,FILTER,FILTER

 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
 here: https://ffmpeg.org/trac/ffmpeg/ticket/1480
 > 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
 process.

 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 <http://ffmpeg.org>
FFmpeg issue tracker