Fix index generation in the way that it was supposed to be used. See the
commitdbb2ac42dde01dfd74dfa994f0e3a9e71a773268
authorrbultje <rbultje@9553f0bf-9b14-0410-a0b8-cfaf0461ba5b>
Sun, 15 Mar 2009 20:14:25 +0000 (15 20:14 +0000)
committerrbultje <rbultje@9553f0bf-9b14-0410-a0b8-cfaf0461ba5b>
Sun, 15 Mar 2009 20:14:25 +0000 (15 20:14 +0000)
tree7e7dbf09e383be68ef5c8a03c9facfb8e7308741
parent0c7ff52f2a6e6c38de3320b8e980aebc1fe8c8d2
Fix index generation in the way that it was supposed to be used. See the
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.

git-svn-id: file:///var/local/repositories/ffmpeg/trunk@17993 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b
libavformat/rmdec.c