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

[Kostya]

On Fri, Mar 13, 2009 at 06:16:47PM -0400, Ronald S. Bultje wrote:
> 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.

Probably rm_assemble_video_frame() should set the flags according to the
frame it read.

In any case we need more data about the real streams so I'm going to debug
them a bit.
 
> Ronald