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

[Michael Niedermayer]

On Fri, Apr 04, 2008 at 11:58:09PM +0200, Bartlomiej Wolowiec wrote:
> On piątek, 4 kwietnia 2008, Michael Niedermayer wrote:
> > 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!
> >
> > [...]
> 
> ok, I enclose patch based on your code.

Looks ok iff it works.

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- Aristotle
-------------- 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/20080405/cc685249/attachment.pgp>