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

[Justin Ruggles]

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?)

-Justin