[FFmpeg-devel] [PATCH] ffprobe integration

Nicolas George nicolas.george
Tue Feb 9 14:04:13 CET 2010

Le primidi 21 pluvi?se, an CCXVIII, M?ns Rullg?rd a ?crit?:
> I don't know how you write parsers,

When parsing the output of ffprobe, I usually use awk.

For example:

awk -F= '
/^.PACKET/ { video = key = 0; pts = "X" }
/codec_type=video/ { video = 1 }
/flag_key=K/ { key = 1 }
/pts=/ { pts = $2 }
/^..PACKET/ && video && key { print pts }

to print the timestamps of the keyframes. Without an end marker, it has to
rely on the order of the fields, which is much less robust.

>				      but the way I'd do it doesn't
> require any special cases.  No matter how you do it, you obviously
> must do _something_ at end of file.

Just stop, or maybe print the final result, is almost always enough.

>					Also, if you do require a closing
> token, and the file ends without one, what will you do?

Nothing. Or more precisely: whatever the code happens to do in such a case,
which is probably silently ignore the last block.

Or, if I want to be extra careful, I can detect truncated input and report
an error.

> It is a bad idea to have the closing marker depend on the
> group/section name since it allows for malformed content which then
> must be detected and rejected.  A generic "close whatever was last
> opened" token avoids this problem.

I completely disagree with this assertion. A generic close marker does not
make malformed content impossible, it makes it impossible to detect.

Lorem <bold>ipsum dolor <italic>sit amet</bold>, consectetur
adipisicing</italic> elit

Lorem \bold{ipsum dolor \italic{sit amet}, consectetur adipisicing} elit

The second one is syntactically correct, but its semantics is not what was

So let me rephrase your sentence: with matching end-markers, malformed
content *can* be detected.

This is better both for quick-and-dirty parsers and for careful ones:

- For quick-and-dirty parsers, which may let daemons fly in your nose on
  malformed content, it is possible to rely on the extra information to
  make things simpler.

  For example if there are subsections which you are not interested in, you
  do not have to keep track of the nesting level of the end marker.

- For careful parsers, it makes it possible to report more accurate and
  helping diagnostics, and detect more errors.

Of course, this comes with the cost of more visual (and keyboard) noise. So
this is not always better. It is a question of balance.

In the particular case of ffprobe, of course, all this is rather moot: there
are no subsections, the syntax is mostly trivial. Any end marker will do.


  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100209/f315342e/attachment.pgp>

More information about the ffmpeg-devel mailing list