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

[Kostya]

On Fri, Mar 13, 2009 at 09:51:37AM -0400, Ronald S. Bultje wrote:
> Hi Kostya,
> 
> so let's go to this one now, this is the last easy rmdec patch in my
> queue (after this we get to multirate, let's do that separately).
> 
> On Wed, Mar 11, 2009 at 1:46 AM, Kostya <kostya.shishkov at gmail.com> wrote:
> > Can we use some simpler solution - like when packet flags & 2 and there was
> > no remaining_len before it (i.e. we are not inside partial packet)
> > nor after it (i.e. we were not reading start of partial packet, but maybe
> > this condition can be omitted) then add this packet to index.
> 
> remaining_len isn't particularly useful. An entire video can take up
> one packet, part of a packet (beginning or end), or split over
> multiple full or partial packets.
> 
> In fact, my current patch already screws up there since we're not
> checking remaining_len appropriately. We should only write index
> entries for the beginning of a RM packet, so remaining_len before
> should be zero before the call to ff_rm_parse_packet().
> 
> So then, if remaining_len is zero (= start of RM packet), how do we
> know that this packet contains the first slice of a video frame, or a
> full video frame (this is dependent on the variablt "type", and slice
> number is "seq"), or a full audio frame (codec-dependent, e.g. 14k4RA,
> AC3, AAC) or the first "slice" of a series of scrambled audio packets
> (28k8, ATRAC3, cook, QCELP, etc.)?

Can we try to rely on packet flags? It should give a sign for the first
slice of audio.
Theoretically same for video.
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).
 
> Any hints on how to easiest accomplish that is appreciated.
> 
> > Passing two additional arguments for getting data to index does not seem right.
> 
> I agree, hence my "poor-man's attempt". :-).
> 
> Ronald