MJPEG Tools Svn

Fixed: mpeg2enc output bit rate exceeding maximum rate due to faulty
algorithm for self-tuning pass-2 reencoding. New algorithm implemented
that won't have this problem
Fixed: mpeg2enc use of uninitialised variable in pass-2 rate controller.
Fixed: mplex incorrect substream id for multiplexing for dvd authoring.

1) Document that $n (frame count) is no longer subsituted for. The author of
the program hard coded 0 for the value of '$n'.
2) DO NOT USE size_t if '-1' is going to be used as a sentinel! Something like
'if (jpegsize < 0) ...' does not work if jpegsize is size_t. Use ssize_t
instead!

Forgot to comment that the informational message about the input and output
rates needs to be printed BEFORE the '-r' value is clobbered. If -c is given
the program's logic copies the source frame rate over top of the -r value
before entering the conversion. Fix was to move the print statement out from
the conversion routine into the main program before the variable was overwritten

jpegsize of 0 should be treated, I think, the same as "end of file". It's
probably a corrupt file anyhow if jpegsize ends up being 0.

Fix the lavpipe manpage - the warning to remove comments was not clear/strong
enough it seems.

Also in pipelist.c be a little more consistent using mjpeg_error_exit1. Also
check for premature end of file better.

Fix typo - it's "maximum" not "maimum" :)

Cleanup.

# automake 1.9 could use AM_PROG_STDC but 1.10 became picky and needs AM_CC_C_0

Change the date string to something more current (reflecting that a change has
been made recently). Also suppress the version/usage info message if the
verbosity level has been explicitly set to 0.

workaround a crash on OSX 10.5.1 MacIntel systems. Seems the intermediate
buffer was one line too short and while that "works" on many systems (linux
intel, OSX PPC) it is luck due to malloc() implementations and memory layout.

Until someone who understands the program has some time the workaround is to
allocate a larger intermediate buffer.