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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

and if the size is broken (20 bytes, header-only), calculate the expected
size and skip the index entries anyway. See "[PATCH] rmdec.c: correctly
skip indexes" thread.

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

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

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

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

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

has two possible outcomes: either len and rm->remaining_len are the same, in
which case we care about the outcome and it is zero, or rm->remaining_len is
currently not in use and we don't care about the outcome. In that case, len
is positive and rm->remaining_len is zero, which leads to a negative result.
This is confusing and could eventually lead to a sign-flip if we skip a lot
of packets (unlikely, but still). Therefore, just always set it to zero.

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

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

patchset. Just a reindent.

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

patchset. Idea is to share this common code between the AMR and QCELP
decoders.

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

move MOVContext from mov.c to isom.h" thread on ML.

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

consistent with av_fifo_generic_write.

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

for swf before and after, but it now incorrectly creates additional
streams.

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

That fixes the case when converting 15-bit RGB/BGR to YUV and high bit is set
for input value(s).

Originally committed as revision 28916 to svn://svn.mplayerhq.hu/mplayer/trunk/libswscale

shall now be copied to Picture.data[3].

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

test reference file.

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

has two possible outcomes: either len and rm->remaining_len are the same, in
which case we care about the outcome and it is zero, or rm->remaining_len is
currently not in use and we don't care about the outcome. In that case, len
is positive and rm->remaining_len is zero, which leads to a negative result.
This is confusing and could eventually lead to a sign-flip if we skip a lot
of packets (unlikely, but still). Therefore, just always set it to zero.

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

ff_rm_parse_packet(). See "[PATCH] Make RM demuxer behave better with -an
option" thread, which sort-of turned into an aggregate of unrelated rmdec.c
cleanups.

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

rm->audio_pkt_cnt in case multiple packets should be read before the next
syncpoint in the file, so that ffplay -an on a file containing AAC audio
works. See "[PATCH] Make RM demuxer behave better with -an option" thread
on mailinglist.

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

For proper seeking, they should be set correctly though.

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

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

not 0 in av_seek_frame_generic.

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

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

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

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

it easier to reuse the fifo.

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