Error tolerance of the tool is not perfect. The MPEG standard is
often misused. Therefore many files out there maybe corrupt and not
perfectly tracked. In either cases it is only the frame count
estimation that can't read out a frame rate -or-, which is worse
than that, the frame reader which is implemented by FFMpeg
In the latter case i.e. if you get the Windows' crash message,
please report the file of suspect to the author - maybe it can get
Due to the limited error tolerance mentioned above it may happen
that the tool loops infinitely. You may have a chance to press the
stop button. If you do so the program's calculation thread will be
stopped unconditionally. This can lead to unpredictable results due
to memory leaks, locked DLL's, etc. Even if you can continue
working with the tool on other files you should restart it and also
report the causing file to the author to fix the problem.
MPEG elementary streams (ES) whose origin are e.g. DVD recorders
in Panasonic VRO format may have a wrong frame count estimation.
This can't be fixed unless the tool would read the file of interest
twice - and surely that's not what you really want it to!
You may get a higher frame count estimated on transport streams
than the tool can really demux after that step when bringing those
frames into the display. This can be caused by transport errors in
the stream so that some frames may be damaged ... but these damages
are not counted in the PTS markers in the file from which the frame
count is calculated. This is a problem which cannot be fixed.