On niedziela, 30 marca 2008, Michael Niedermayer wrote:
On Sun, Mar 30, 2008 at 03:16:03AM +0200, Michael Niedermayer wrote:
On Sat, Mar 29, 2008 at 08:16:24PM -0400, Justin Ruggles wrote:
Justin Ruggles wrote:
Michael Niedermayer wrote:
On Sat, Mar 29, 2008 at 10:04:30PM +0100, Bartlomiej Wolowiec wrote:
On sobota, 29 marca 2008, Michael Niedermayer wrote: > On Sat, Mar 29, 2008 at 12:19:43AM +0100, Bartlomiej Wolowiec wrote: >>>> 3.change of ff_aac_ac3_parse to make it react correctly to >>>> result returned in flag. >> >> According to suggestions, I wrote new patch to AAC/AC3 parser. >> >> Current data about the stream are taken from frames FRAME_START >> and FRAME_COMPLETE. It will be improved in the next patch. >> -- >> Bartlomiej Wolowiec >> >> Index: libavcodec/aac_ac3_parser.c >> ================================================================= >>== --- libavcodec/aac_ac3_parser.c (wersja 12623) >> +++ libavcodec/aac_ac3_parser.c (kopia robocza) >> @@ -29,35 +29,50 @@ >> const uint8_t *buf, int buf_size) >> { >> AACAC3ParseContext *s = s1->priv_data; >> - AACAC3FrameFlag frame_flag; >> const uint8_t *buf_ptr; >> int len; >> >> *poutbuf = NULL; >> *poutbuf_size = 0; >> >> + if(s->frame_ptr == NULL) { >> + //after sending package of data in the end there was one >> new header + memcpy(s->inbuf, s->frame_start, >> s->header_size); + s->frame_start = s->inbuf; >> + s->frame_ptr = s->frame_start + s->header_size; >> + } > > Instead of this i think you could just return a smaller number. > We do have code in the parser that does what is needed to move > this to the begin (search for overread) in parser*.
I've searched, but I haven't found anything appropriate. Majority of solutions is based on ff_combine_frame and it seeks 4 byte signature, but here, beside the signature other parameters shoulf be read (minimum 7 bytes forward should be in the buffer). Could you tell me what solution do you mean?
I meant something that didnt exist. Sorry! Either way after looking at the parser code again and reading the spec again i think there are a few problems.
First could you explain me how these 7+ch EAC-3 streams are stored in MPEG? Second how are timestamps associated with them if they are stored in a single ES stream instead of 2. Can timestamps be associated with dependant "frames" or not? (If we do not know this its not possible to implement 7+ch EAC-3)
Either way, a parser as you implement it must at least return the correct index (which can be negative up to the header size) current suggested code returns something random. Also it requires at least an increase of AV_PARSER_PTS_NB. And this design requires that timestamps can not be associated with dependant "frames". If they can more changes or better a different design has to be choosen.
besides, do we have sample files for 7+ch EAC3 ? Especially ones muxed in MPEG?
We have 1 sample for 7.1 E-AC3. I can't find the original EVO that it came from, so I sent a message to the person who provided it originally. I'm sure madshi (eac3to author) still has it lying around somewhere as well... (are you subscribed here madshi?)
correction. We have 2 samples. I uploaded a different EVO sample to
http://samples.mplayerhq.hu/A-codecs/AC3/eac3/7_pt_1_sample.evo
Good news, Timestamps do only apply to the first of the 2 chunks, so we were on the right track. Returning the correct (possibly negative) index and changing AV_PARSER_PTS_NB should be correct ...
Also what was the exact reason that ff_combine_frame() wasnt used?
[...]
Perfect, it's better that there are no timestamps in dependant frames... I don't know abilities of ff_combine_frame so good, so I don't know if there is a simple method to read the whole header of the next frame. -- Bartlomiej Wolowiec