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 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
On sobota, 29 marca 2008, Michael Niedermayer wrote: 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
On Sat, Mar 29, 2008 at 10:04:30PM +0100, Bartlomiej Wolowiec wrote: 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 ... My notes of the file being below for the ones bored ... av_read_packet stream=1, pts=5400, dts=5400, size=2013 av_read_frame_internal stream=1, pts=5400, dts=5400, size=620 <---5400 av_read_frame_internal stream=1, pts=8280, dts=8280, size=488 av_read_frame_internal stream=1, pts=11160, dts=11160, size=620 (5888) av_read_packet stream=1, pts=6360, dts=6360, size=2016 av_read_frame_internal stream=1, pts=14040, dts=14040, size=488 av_read_frame_internal stream=1, pts=6360, dts=6360, size=620 <---6360 av_read_frame_internal stream=1, pts=9240, dts=9240, size=488 av_read_frame_internal stream=1, pts=12120, dts=12120, size=620 (6840) av_read_packet stream=1, pts=7320, dts=7320, size=2016 85 av_read_frame_internal stream=1, pts=15000, dts=15000, size=488 av_read_frame_internal stream=1, pts=7320, dts=7320, size=620 <---7320 av_read_frame_internal stream=1, pts=10200, dts=10200, size=488 av_read_packet stream=1, pts=8280, dts=8280, size=2016 505 av_read_frame_internal stream=1, pts=13080, dts=13080, size=620 (7800) av_read_frame_internal stream=1, pts=8280, dts=8280, size=488 av_read_frame_internal stream=1, pts=11160, dts=11160, size=620 <!!!8280 av_read_frame_internal stream=1, pts=14040, dts=14040, size=488 av_read_packet stream=1, pts=9240, dts=9240, size=2016 305 av_read_frame_internal stream=1, pts=16920, dts=16920, size=620 av_read_frame_internal stream=1, pts=9240, dts=9240, size=488 av_read_frame_internal stream=1, pts=12120, dts=12120, size=620 <!!!9240 av_read_frame_internal stream=1, pts=15000, dts=15000, size=488 av_read_packet stream=1, pts=10200, dts=10200, size=2016 105 av_read_frame_internal stream=1, pts=17880, dts=17880, size=620 av_read_frame_internal stream=1, pts=10200, dts=10200, size=488 av_read_frame_internal stream=1, pts=13080, dts=13080, size=620 <!!!10200 av_read_packet stream=1, pts=10680, dts=10680, size=2016 393 av_read_frame_internal stream=1, pts=15960, dts=15960, size=488 av_read_frame_internal stream=1, pts=10680, dts=10680, size=620 <---10680 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Old school: Use the lowest level language in which you can solve the problem conveniently. New school: Use the highest level language in which the latest supercomputer can solve the problem without the user falling asleep waiting.