[FFmpeg-soc] [soc]: r2021?-?in?eac3:?ac3dec.h?ac3dec_data.c?ac3dec_data.h eac3dec.c

[Michael Niedermayer]

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


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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-soc/attachments/20080330/dc95f01c/attachment.pgp>