[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 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.

-- 
Bartlomiej Wolowiec
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mutliframe.patch
Type: text/x-diff
Size: 7000 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-soc/attachments/20080404/116e11b7/attachment.patch>