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

some point in the future.

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

valid. See "[PATCH] rmdec.c: prevent zero-length packets" thread.

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

packets" thread.

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

try #2" thread. Patch originally by Vladimir Voroshilov.

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

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

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

Has been tested against streamed / non-seekable input and passes make
seektest. See "[PATCH] rmdec.c: parse INDX chunk" thread on mailinglist.

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

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

as requested by Kostya). See "[PATCH] rmdec.c: remove cache access
duplication".

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

cache, since this can already be accessed through ff_rm_retrieve_cache().
See "[PATCH] rmdec.c: remove cache access duplication" thread.

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

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

the newer (.rm, audio/video) files. See "[PATCH] rmdec.c: merge old/new
packet reading code" thread on mailinglist.

Originally committed as revision 18005 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

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

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

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

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

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

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

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

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

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

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

libavformat/rmdec.c:550: warning: assignment makes pointer from integer

Patch by Dominique Leuenberger (dominique-ffmpeg-devel A leuenberger D net)

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

the (larger) allocated size. (prevents segfaults due to later failures
from 900MB-sized packets, yes fuzzed file not a valid one)

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

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

of allocated slices matches the actual.
Audio still does a copy (marked with FIXME in the code so this is not missed).

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

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

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

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

accordingly.

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

"rmdec.c: double free" thread on mailinglist.

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

"rmdec.c: double free" discussion on mailinglist, patch with suggestions
from Reimar Doffinger.

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

"[PATCH] oops I broke rdt.c" mailinglist thread.

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

AVStreams can be used to call these public rmdec.c functions as well, as is
the case for RDT/RTSP streams. See mailinglist discussion in "[PATCH] rdt.c:
don't reuse the same AVStream in both RTSP and RM demuxer" thread.

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

This allows multiple video or audio streams per .rm file. See mailinglist
thread "[PATCH] rmdec.c: implement RMVideo/AudioStream".

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