[FFmpeg-devel] [PATCH] rmdec.c: merge old/new packet reading code

[Ronald S. Bultje]

Hi Kostya,

On Fri, Mar 13, 2009 at 10:25 AM, Kostya <kostya.shishkov at gmail.com> wrote:
> Can we try to rely on packet flags? It should give a sign for the first
> slice of audio.
> Theoretically same for video.

For audio, flags indicates whether this is the first frame in a series
of frames making up for on scrambled audio-frame, so yes. For video,
partially, we can use it as an indicator of whether it is a keyframe
or not (useful), but that's not all.

> Anyway, if remaining_len was zero and packet was read successfully
> and flags & 2 then you can add it to index. The question is what to do
> with possible tail (i.e. other frames in the packet).

Remaining_len isn't useful, you can have a frame in three packets, the
second packet will have remaining_len set to 0 an the packet
succesfully read, yet if we seek to it, it's useless. We need to be
sure that the packet contained the *start* of a frame.

That's what they type&1 (which means the packet contains a full frame)
or seq&0x7F==1 (which means the frame is divided over multiple
packets, and this packet that we just read contains the first). In
both cases, remaining_len should be zero also to make sure that this
was in fact the beginning of a packet, or alternatively we could cache
the position of the beginning of the current packet if remaining_len
!= 0 (I would actually be in favour of that).

I think we won't get away with simply checking one flag, it's not that
simple. I'm ok with hiding all compelxity in rm_decode_video_slice()
etc., but I'd like to do it perfect so that all packets containing a
first slice of a keyframe for video are indexed, not just a few.

Ronald