MJPEG Tools Svn

New y4m API changes.

This check-in extends the YUV4MPEG2 format to explicitly encode the
type of color subsampling and to allow non-4:2:0 modes. It also
adds a frame header tag so that streams can describe mixed-framing
modes, such as 3:2 pulldown. As before, the stream format is
documented in the yuv4mpeg(5) manpage.

Older code will (for the most part) compile just as before, and these
new extended features will be disabled/disallowed by default. This
default assumes uniform framing (progressive, top-first, or bottom-
-first interlacing throughout) and 4:2:0-JPEG subsampled data. If
the library reads a stream/frame header which goes beyond this default,
it will return a new error to the caller, Y4M_ERR_FEATURE.

The extended API adds another argument to the y4m_read_frame_header()
and the y4m_write_frame_header() functions --- so code using those
functions will need to be tweaked.

Code which directly accessed members of the y4m_stream_info_t and the
y4m_frame_info_t structures will also break, but that is the coder's
fault! The API explicitly said "Use the accessor functions and
don't touch these structures directly."

Added a new schedule option in the script window.

I have applied a patch which was submitted to the mjpeg patches area on SF.
It allows now for AVI and Quicktime to accept also big caps.

Bandwidth parameter checking - 1.0 is max (100%) and 0 is illegal (can cause
divide by 0 fault).

Need to use AM_CONFIG_HEADER instead of AC_CONFIG_HEADER. AM_CONFIG_HEADER
is present in configure.in but was not being found by the autogen.sh script

Add a noinst_HEADERS so that the .h files get put into the .tar.gz file created
by 'gmake dist'

Fixed bug caused by incorrect calculation of how much of an input
stream is available for muxing

gcc 2.95.3 doesn't accept data declarations in the body of a function.

From Michael Hanke:
here follows my patch. Please excuse the long delay.

The original code uses explicitly programmed loop unrolling. I did not do that
because I assume that the compiler can do this much more efficiently.
> >This is what I did. The luminance channel of the matte is used in a
> > convex combination of the input sources thus using the [16,235]/219
> > range.
>
> Well, post your patch, already. You fixed a bug! :)