On 03/06/15 07:40, nu774 wrote: > Let me explain on this patch. > > Issue: > ------ > AAC decoder incorectly decode this sample (taken from Japanese DVB): > https://dl.dropboxusercontent.com/u/76042064/5.1ch_PCE_issue.aac > Every once in 0.5 sec or so, glitches are generated. It is audible, and > also you can easily spot them on spectrogram of the decoded result. > It seems that quite many (all?) of 5.1ch DVB audio in Japan trigger > simular issue.
Is it ok to make a fate-test out of it? > Explanation: > ------------ > This ADTS file contains ordinary 5.1ch AAC with non-zero > channel_configuration(6). However, it also contains PCE every once in > 0.5 sec or so. > Channel elemnents and element_instance_tag(ID) are like this: > [SCE][0], [CPE][2], [CPE][4], [LFE][5] (*1) > > When AACdec sees ADTS frame header, it assigns channels using default > channel configuration for 5.1ch. It is like this: > [SCE][0], [CPE][0], [CPE][1], [LFE][0] (*2) > However, when PCE comes, it assigns channels using PCE configuration as > is describled at (*1). > As you can see, only IDs are different. However, due to this > discontinuity, glitches are generated. > > What this patch does: > --------------------- > When assign channels on ac->che[][], use internal ID starting from zero > instead of actual ID described in PCE. > This way, channels are always assigned like (*2). > Mapping between internal ID and actual ID is resolved by > ac->tag_che_map[][]. The patch seems fine, I assume that layout_map values are within the array boundaries (since it is what is used in the loop below) I'll just put your explanation in the patch message and push it tonight. lu _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
