[FFmpeg-trac] #909(FFprobe:closed): FFProbe Print_Format Improper Formatting

[FFmpeg]

#909: FFProbe Print_Format Improper Formatting
------------------------------------+-----------------------------------
             Reporter:  ChrisAtlGA  |                    Owner:  stefano
                 Type:  defect      |                   Status:  closed
             Priority:  normal      |                Component:  FFprobe
              Version:  0.9.1       |               Resolution:  invalid
             Keywords:              |               Blocked By:
             Blocking:              |  Reproduced by developer:  1
Analyzed by developer:  1           |
------------------------------------+-----------------------------------
Changes (by saste):

 * analyzed:  0 => 1
 * status:  new => closed
 * resolution:   => invalid
 * reproduced:  0 => 1


Comment:

 Replying to [ticket:909 ChrisAtlGA]:
 > When using ffprobe, using the XML option for print_format, character
 encoding on values does not take place which creates invalid XML which
 can't be parsed.
 >
 > The JSON option will render proper encoding to protect JavaScript run-
 time by adding an additional backslash when one is present such as in
 media path/filename. Example: "D:\movie.mp4" appears in JSON output as
 "D:\ \move.mp4". No special handling takes place with XML.

 XML doesn't require '\' escaping like in JSON, check function
 xml_escape_str() in ffprobe.c, but you may need a function to perform XML-
 de-escaping for parsing the resulting output (which will be different from
 a JSON de-escaping function).


 > In all formats (default, XML, JSON) using the show_streams option, the
 Bit_Rate for both audio and video are omitted. This information is present
 in the standard metadata/duration/stream sections in the console output.

 Yes this is intentional, when the bit_rate (or other) information is not
 available, it is preferable not to show it in the output, so that
 application code doesn't need to interpret the assumed string value for
 "undefined". This is different in case of output formats which *require* a
 constant number of fields per each section (compact, default).

 > Thank you for the consideration of this bug submission.

 Closing the ticket as invalid, please re-open in case you are not
 satisfied with my answer.

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