On 06/09/2011 01:30 PM, Alex Converse wrote: > On Thu, Jun 9, 2011 at 10:27 AM, Justin Ruggles > <[email protected]> wrote: >> 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 > > I agree that probes should have some trouble with files with junk at > the begging but unless this junk looks particularly like AAC or MP3 it > shouldn't get as confused as it is. MP3, ADTS AAC, and AC3 all have a > similar frame header, do they all handle junk at the beginning in a > consistent manner?
except for the number of consecutive frames (aac requires 3, mp3 and ac3 require 4), yes. In this case, it's not necessarily the junk that looks like AAC, but some arbitrary point in the probe data. But since the beginning doesn't look like E-AC3, the probe function doesn't know whether to favor the arbitrary point that looks like AAC or the arbitrary point that looks like E-AC3. -Justin _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
