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

[Michael Niedermayer]

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?


> 
> >
> > > @@ -43,6 +44,7 @@
> > >      int sample_rate;
> > >      int bit_rate;
> > >      int samples;
> > > +    AACAC3FrameFlag frame_flag;
> > >  } AACAC3ParseContext;
> >
> > why?
> 
> Because of  the code below, I need to know if the frame should be send 
> instantly or stay in the buffer and wait for next frames:
> 
> +                if(s->frame_flag == FRAME_COMPLETE) {
>                  *poutbuf = s->inbuf;
>                  *poutbuf_size = s->frame_size;
> -                s->inbuf_ptr = s->inbuf;
> -                s->frame_size = 0;
> +                s->frame_start = s->inbuf;
> +                s->frame_ptr = s->frame_start;
>                  break;

Hmm, well, ok

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No human being will ever know the Truth, for even if they happen to say it
by chance, they would not even known they had done so. -- Xenophanes
-------------- 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/767d19e5/attachment.pgp>