On 06/09/2011 01:11 PM, Alex Converse wrote: > On Thu, Jun 9, 2011 at 10:06 AM, Justin Ruggles > <[email protected]> wrote: >> On 06/09/2011 01:02 PM, Alex Converse wrote: >> >>> On Wed, Jun 8, 2011 at 6:54 AM, Diego Biurrun <[email protected]> wrote: >>>> From: Kieran Kunhya <[email protected]> >>>> >>>> This fixes ADTS detection for at least one sample. >>>> >>>> Signed-off-by: Diego Biurrun <[email protected]> >>>> --- >>>> libavformat/aacdec.c | 2 +- >>>> 1 files changed, 1 insertions(+), 1 deletions(-) >>>> >>>> diff --git a/libavformat/aacdec.c b/libavformat/aacdec.c >>>> index 0dc1c5c..6a184c7 100644 >>>> --- a/libavformat/aacdec.c >>>> +++ b/libavformat/aacdec.c >>>> @@ -44,7 +44,7 @@ static int adts_aac_probe(AVProbeData *p) >>>> uint32_t header = AV_RB16(buf2); >>>> if((header&0xFFF6) != 0xFFF0) >>>> break; >>>> - fsize = (AV_RB32(buf2+3)>>13) & 0x8FFF; >>>> + fsize = (AV_RB32(buf2 + 3) >> 13) & 0x1FFF; >>>> if(fsize < 7) >>>> break; >>>> buf2 += fsize; >>>> -- >>>> 1.7.1 >>> >>> OK >> >> >> fate samples have been updated, but should this change wait until most >> of the fate systems run make fate-rsync? >> > > IMHO this change doesn't make the ADTS probe any more aggressive, it > just un-papers over a bug in the AC3 probe so can be pushed before any > tests are changed.
Why do you think there is a bug in AC3 probe? The scoring is essentially the same as raw aac and mp3, in that it scores higher if the frames start at the beginning of the probe data. The issue was the fate samples. One should expect probe issues with a raw file containing junk at the beginning. -Justin _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
