[FFmpeg-devel] AAC-Main (round 2)

[Robert Swain]

2008/11/21 Robert Swain <robert.swain at gmail.com>:
> 2008/11/21 Alex Converse <alex.converse at gmail.com>:
>> On Fri, Nov 21, 2008 at 11:30 AM, Robert Swain <robert.swain at gmail.com> wrote:
>>> 2008/11/21 Alex Converse <alex.converse at gmail.com>:
>>>> On Fri, Nov 21, 2008 at 10:51 AM, Robert Swain <robert.swain at gmail.com> wrote:
>>>>> 2008/11/19 Alex Converse <alex.converse at gmail.com>:
>>>>>> I split these off into a separate patch based on Rob's suggestion.
>>>>>
>>>>>> +            } else if (ac->m4ac.object_type == AOT_AAC_LC) {
>>>>>> +                av_log(ac->avccontext, AV_LOG_ERROR, "Prediction is not allowed in AAC-LC.\n");
>>>>>> +                memset(ics, 0, sizeof(IndividualChannelStream));
>>>>>> +                return -1;
>>>>>
>>>>> Is this purely for informative reasons or have you encountered some LC
>>>>> streams with the predictor_present bit set? This case doesn't exist in
>>>>> the specs I have though I know it should not be allowed as prediction
>>>>> is not in LC.
>>>>
>>>> I put that there because if the predictor bit is set in an LC stream
>>>> then there is no sane assumption I can think of about the data that
>>>> directly follows it.
>>>
>>> Good point. Just looking for some files encoded with Main profile with
>>> which I can test, though I expect you have tested it thoroughly.
>>>
>>
>> Try the am##_## series from
>> http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_IEC_14496-4_2004_Conformance_Testing/audio_conformance/mpeg4audio-conformance/compressedMp4/
>
> Thanks, I wondered which were main profile.
>
> /me grins as Quicktime breaks on these files but patched ffplay works nicely.
>
> I will commit the first three patches in a bit after casting an eye
> over the code again.

Apologies for the delay. Applied.

Best regards,
Rob