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

FFmpeg trac at avcodec.org
Fri Nov 16 16:13:21 CET 2012


#1922: Broken or incomplete parser for filters
-------------------------------------+-------------------------------------
             Reporter:  burek        |                    Owner:
                 Type:  defect       |                   Status:  closed
             Priority:  normal       |                Component:
              Version:  unspecified  |  undetermined
             Keywords:               |               Resolution:  invalid
             Blocking:               |               Blocked By:
Analyzed by developer:  0            |  Reproduced by developer:  0
-------------------------------------+-------------------------------------

Comment (by burek):

 @Cigaes: I'm not sure why any of those 2 need escaping? The only thing
 that is not logical is double '=' character, which can be solved the way
 VLC solved it, by surrounding the text "text=8-(,drawtext=8-)" with curly
 braces (or quotes/parentheses), so you would get:
 {{{
 drawtext={text=8-(,drawtext=8-)}
 }}}
 or
 {{{
 drawtext=(text=8-(,drawtext=8-))
 }}}

 Making the parser aware of this is as simple as implementing one of
 several well known algorithms (for which there is also a sample code
 available for most popular programming languages):
 http://stackoverflow.com/questions/4582398/writing-a-simple-equation-
 parser

 I believe this won't be as complex as it looks like, because people have
 solved this kind of a problem a long time ago and it would be wise to not
 reinvent the wheel. Also, as soon as the parentheses thing is parsed
 correctly, you can place parentheses in most of expressions, to clarify
 the expression for reading and to make it simpler for parser to understand
 what did you want to say with that expression.

 @saste: It maybe isn't a bug, but it's better to fix it to have a cleaner
 usage. People who use ffmpeg already have to think about shell escaping +
 this escaping because of the filter's inability to parse the expression
 correctly. I'm just suggesting that this ticket shouldn't be closed as
 fast as possible, just to lower the number of open/unresolved tickets, but
 rather should be discussed more to find the best way to fix this issue,
 because it is an issue and it should be fixed.

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


More information about the FFmpeg-trac mailing list