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
signature.asc
Description: Digital signature
_______________________________________________ FFmpeg-soc mailing list [email protected] https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
