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

[Bartlomiej Wolowiec]

On piątek, 4 kwietnia 2008, Michael Niedermayer wrote:
> On Fri, Apr 04, 2008 at 01:45:44AM +0200, Michael Niedermayer wrote:
> > On Thu, Apr 03, 2008 at 11:53:22PM +0200, Bartlomiej Wolowiec wrote:
> > > On niedziela, 30 marca 2008, Michael Niedermayer wrote:
> > > > 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()
> > > >
> > > > [...]
> > >
> > > Hmm...
> > >  I tried to implement it using ff_combine_frame, but the code which I
> > > got is in my opinion significantly worse. Main problems which I had:
> > > -ff_combine_frame is rather adapted to using on one frame, when in
> > > buffer is one frame and it currently reads the next one  it isn't
> > > convenient (the whole buffer size is not just a new frame's size, so
> > > that we should remember size of earlier frames).
> > > -in the genuine code there is
> > > memmove(s->frame_start, s->frame_start + 1, s->header_size - 1);
> > > s->frame_ptr--;
> > > here we can operate on pc->buffer and pc->index (remembering also where
> > > the new frame begins). However, surely it isn't the simpliest
> > > solution...
> >
> > What i had in mind is below, this is blindly written and likely contains
> > bugs. I did spot one each time i looked at it :)
> > But it does not look fundamentally worse to me, it also has the advantage
> > that its not full of unneeded memcpys and memmoves.
> >
> > while(s->remaining_size <= buf_size){
> >     if(s->remaining_size && !s->need_next_header){
> >         i= s->remaining_size;
> >         s->remaining_size= 0;
> >         goto output_frame;
> >     }else{ //we need a header first
> >         for(i=s->remaining_size; i<buf_size; i++){
> >             ctx->state= (ctx->state<<8) + buf[i];
> >             if((len=parse_header(ctx->state, &s->need_next_header,
> > &s->new_frame_start)))
>
> just to clarify before you ask ...
> state is a 64bit variable in your context unrelated to the 32bit state
> ff_combine_frame() plays with.
>
> [...]

The code works almost perfectly, but I have two questions:
-is there any effective method of getting bitstream from uint64_t (or it 
should be "unpacked" to 8-byte array)?
-why the number of channels is set in parser? I have this question because the 
number of channels in eac3 depends on chanmap, to read which there it needs  
92 bits of header. (or I should put there something like x = (x<<8) + 
(y>>56); y = (y<<8) + buf[i]; and keep 128 last bits?)

-- 
Bartlomiej Wolowiec