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