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

[Michael Niedermayer]

On Fri, Apr 04, 2008 at 07:44:46PM +0200, Bartlomiej Wolowiec wrote:
> 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)?

uint64_t tmp= be2me_64(state);
init_get_bits(&tmp);


> -why the number of channels is set in parser? 

streamcopy mpeg-ps -> anything
first doesnt have a header with a channel number second does.


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

well, thats a possibility.
a
buf[16];
memmove(buf)
buf[15]= *b++;
would be a possibility as well

a third one (and i think its the best one) is
just to read the header with the channel num before the returning it after
ff_combine_frame(). It has to be a complete frame at that point, also
please reuse the code from the decoder for this if possible!

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

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable
-------------- 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/20080404/f9b720f6/attachment.pgp>