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

[Michael Niedermayer]

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() 

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is 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-soc/attachments/20080330/5fbbac69/attachment.pgp>