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

[Justin Ruggles]

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

md5sum:
5ef254a48ebfeecff22b02b7167e5987  7_pt_1_sample.evo

-Justin