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

[Bartlomiej Wolowiec]

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