On 06/09/2011 01:34 PM, Alex Converse wrote:

> On Wed, Jun 8, 2011 at 8:45 AM, Justin Ruggles <[email protected]> 
> wrote:
>> On 06/08/2011 03:49 AM, Alex Converse wrote:
>>
>>> On Tue, Jun 7, 2011 at 6:56 PM, Justin Ruggles <[email protected]> 
>>> wrote:
>>>> On 06/07/2011 06:04 PM, Alex Converse wrote:
>>>>
>>>>> The 'wfex' is just a Microsoft WaveFormatEx struct.
>>>>> ---
>>>>>  libavformat/mov.c |   14 ++++++++++++++
>>>>>  1 files changed, 14 insertions(+), 0 deletions(-)
>>>>>
>>>>> diff --git a/libavformat/mov.c b/libavformat/mov.c
>>>>> index 3aec86c..0630b6e 100644
>>>>> --- a/libavformat/mov.c
>>>>> +++ b/libavformat/mov.c
>>>>> @@ -507,6 +507,19 @@ static int mov_read_dac3(MOVContext *c, AVIOContext 
>>>>> *pb, MOVAtom atom)
>>>>>      return 0;
>>>>>  }
>>>>>
>>>>> +static int mov_read_wfex(MOVContext *c, AVIOContext *pb, MOVAtom atom)
>>>>> +{
>>>>> +    AVStream *st;
>>>>> +
>>>>> +    if (c->fc->nb_streams < 1)
>>>>> +        return 0;
>>>>> +    st = c->fc->streams[c->fc->nb_streams-1];
>>>>> +
>>>>> +    ff_get_wav_header(pb, st->codec, atom.size);
>>>>> +
>>>>> +    return 0;
>>>>> +}
>>>>> +
>>>>>  static int mov_read_pasp(MOVContext *c, AVIOContext *pb, MOVAtom atom)
>>>>>  {
>>>>>      const int num = avio_rb32(pb);
>>>>> @@ -2249,6 +2262,7 @@ static const MOVParseTableEntry 
>>>>> mov_default_parse_table[] = {
>>>>>  { MKTAG('e','s','d','s'), mov_read_esds },
>>>>>  { MKTAG('d','a','c','3'), mov_read_dac3 }, /* AC-3 info */
>>>>>  { MKTAG('w','i','d','e'), mov_read_wide }, /* place holder */
>>>>> +{ MKTAG('w','f','e','x'), mov_read_wfex },
>>>>>  { MKTAG('c','m','o','v'), mov_read_cmov },
>>>>>  { 0, NULL }
>>>>>  };
>>>>
>>>>
>>>> Interesting...
>>>>
>>>> What happens if extradata is already set? ff_get_wav_header() doesn't
>>>> seem to handle that cleanly.
>>>>
>>>
>>> Good catch. Should that be handled by mov_read_wfex() or 
>>> ff_get_wav_header()?
>>
>>
>> It wouldn't be a bad idea for ff_get_wav_header() to check for existing
>> extradata and free it before setting the new extradata.
> 
> Fixed.
> 
>> Also I guess we
>> need to decide which extradata take precedence.
>>
> 
> For now I just think we should use the extradata we find last unless
> we have compelling reason to do otherwise (which is the current
> behavior). The files I've found in the wild with a wfex atom don't
> seem to have competing extradata.


patch ok then.

-Justin
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to