Originally committed as revision 18002 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 18001 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 18000 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 17999 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 17998 to svn://svn.ffmpeg.org/ffmpeg/trunk

to it were removed in r6606

Originally committed as revision 17997 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 17996 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 17995 to svn://svn.ffmpeg.org/ffmpeg/trunk

A config.h present in the source tree takes precedence over a config.h
in the build tree, which can possibly result in an incorrect build.
patch by matthieu castet, castet.matthieu free fr

Originally committed as revision 17994 to svn://svn.ffmpeg.org/ffmpeg/trunk

discussion in the ML thread "[PATCH] rmdec.c: merge old/new packet reading
code".

Over time, this code broke somewhat, e.g. seq was never actually written
into (and was thus always 1, therefore the seq condition was always true),
whereas it was supposed to be set to the sequence number of the video slice
in case the video frame is divided over multiple RM packets (slices). The
problem of this is that packets other than those containing the beginning
of a video frame would be indexed as well.
Secondly, flags&2 is supposed to be true for video keyframes and for these
audio packets containing the start of a block. For some codecs (e.g. AAC),
that is every single packet, whereas for others (e.g. cook), that is the
packet containing the first of a series of scrambled packets that are to be
descrambled together. Indexing any of the following would lead to incomplete
and thus useless frames. Problem here is that flags would be reset to 2 to
indicate that the first packet is ready to be returned, and in addition if
no data was left to be returned (which is always true for the first packet),
then we wouldn't actually write the index entry anyway.
All in all, the idea was good and it probably worked at some point, but that
is long ago. This patch should at the very least make it likely for this code
to be executed again at the right times, i.e. the way it was originally
intended to be used.

Originally committed as revision 17993 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 17992 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 17991 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 17990 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 17989 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 17988 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 17987 to svn://svn.ffmpeg.org/ffmpeg/trunk

complete nonsense if timecode_frame_start was used on big-endian systems.

Originally committed as revision 17986 to svn://svn.ffmpeg.org/ffmpeg/trunk

See discussion:
http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/86209

Originally committed as revision 17985 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 17984 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 17983 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 17982 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 17981 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 17980 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 17979 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 17978 to svn://svn.ffmpeg.org/ffmpeg/trunk

PIX_FMT_RGB565_BE -> PIX_FMT_RGB565BE
PIX_FMT_RGB565_LE -> PIX_FMT_RGB565LE
for consistency with the other pixfmts macros.

Originally committed as revision 17977 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 17976 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 17975 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 17974 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 17973 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 17972 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 17971 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 17970 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 17969 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 17968 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 17967 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 17966 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 17965 to svn://svn.ffmpeg.org/ffmpeg/trunk

seeking before data_offset and is more consistent with how the generic index
seeking code handles it.

Originally committed as revision 17964 to svn://svn.ffmpeg.org/ffmpeg/trunk

some 'may be used uninitialized' warnings.

Originally committed as revision 17963 to svn://svn.ffmpeg.org/ffmpeg/trunk