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

[Michael Niedermayer]

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.

One small comment
packets can be out of order if they where transmittet over the net using
something like UDP.

The demuxer should support assembling frames that are split into packets
and they are not in their expectet order, also it must handle the case
correctly that a packet is lost, the frame still should be sent to the
decoder as it might be able to decode part of it.

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Thouse who are best at talking, realize last or never when they are wrong.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090314/d7655308/attachment.pgp>