[FFmpeg-soc] [soc]:?r2021?-?in?eac3:?ac3dec.h?ac3dec_data.c?ac3dec_data.h eac3dec.c

[Bartlomiej Wolowiec]

On niedziela, 30 marca 2008, Michael Niedermayer wrote:
> On Sun, Mar 30, 2008 at 01:53:18PM +0200, Michael Niedermayer wrote:
> > On Sun, Mar 30, 2008 at 12:36:30PM +0100, Bartlomiej Wolowiec wrote:
> > > On niedziela, 30 marca 2008, Michael Niedermayer wrote:
> > > > On Sun, Mar 30, 2008 at 03:16:03AM +0200, Michael Niedermayer wrote:
> >
> > [...]
> >
> > > > Also what was the exact reason that ff_combine_frame() wasnt used?
> > > >
> > > >
> > > > [...]
> > >
> > > Perfect, it's better that there are no timestamps in dependant
> > > frames...
> > >
> > > I don't know abilities of ff_combine_frame so good, so I don't know if
> > > there is a simple method to read the whole header of the next frame.
> >
> > The header should just be there in the buffer with ff_combine_frame().
> > Anyway what i meant was that i _think_ the current aac/ac3 parser could
> > be simplified by using ff_combine_frame().
> > The advanatges of ff_combine_frame() being that it takes care of the too
> > much read header and doesnt by itself force a unneeded copy.
>
> Note, to add the header into the buffer calling ff_combine_frame() with
> END_NOT_FOUND and a smaller buffer size should work.
>
> After its in the buffer you just run the header decoder thing over the
> header and when you know the final frame size you call ff_combine_frame
> with appropriate next value.
>
> Anyway iam not insisting on you changing the current aac/ac3 parser to use
> ff_combine_frame()
> But what you will end up implementing will be quite similar in
> functionality to ff_combine_frame()
>
> [...]

Ok, now I understand... I was just thinking how to make solution similar to 
other solutions..
I'll try in short time to write this parser with ff_combine_frame(),
but now I'll try to finish my GSoC application, because the deadline is 
near...


-- 
Bartlomiej Wolowiec