[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
-------------------------------------+-------------------------------------
Changes (by burek):

 * priority:  normal => wish
 * type:  defect => enhancement


Comment:

 @Cigaes:
 In the 1st filter you provided the "text" parameter and in the 2nd you
 didn't, hence the confusion. If this is your intended example:
 {{{
 drawtext=text=8-(,drawtext=text=8-)
 }}}
 then this would be a solution:
 {{{
 drawtext=(text="8-("),drawtext=(text="8-)")
 }}}
 When you have a proper parser, it is just a matter of assigning a proper
 precedence to make the quotes having the highest priority and everything
 inside quotes should be considered as a text (and in that case it is
 obvious and logical that you have to escape just a quote itself + escaping
 character, of course, and nothing more). That being said, this would be an
 example of it:
 {{{
 drawtext=(text="~!@#$%^&*()_+-=8-(\"'.|,\\<>"),drawtext=(text="8-)")
 }}}

 Also, regarding API changes, I have a feeling that the mistake was made a
 long time ago when the proper interface towards users/programmers wasn't
 defined, which later caused all the mess with those famous "API changes
 that break everything". The interface here would represent an analogy to a
 class in OOP, which has its internals hidden away from the users/other
 programmers and the class definition never changes (API never breaks), but
 internal implementation of the class changes constantly, improving things.
 Interfaces are usually used for such cases, so I believe that we have a
 much bigger issue here than just the filter parser(s). Also, I believe
 that time involved in designing a proper interface now (for future
 versions of ffmpeg) would save you a lot of time and headaches in the
 future and would finally allow you to focus on improvements, not taking
 much of a care about API breakages, like you do right now, which makes
 implementing/fixing a lot of features a nightmare.

 @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).

 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.

 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.

-- 
Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/1922#comment:6>
FFmpeg <http://ffmpeg.org>
FFmpeg issue tracker