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

[Michael Niedermayer]

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?


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch
-------------- 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/e1bd7f45/attachment.pgp>