I think there is open bug report about SEGV regarding this commit on trac.
Please revert or fix ASAP!
On 8/16/20, Michael Niedermayer <mich...@niedermayer.cc> wrote:
> On Sat, Aug 01, 2020 at 02:07:30PM +0300, Jan Ekström wrote:
>> ---
>> libavcodec/aacdec_template.c | 89 +++++++++++++++++++++++++++++++-----
>> 1 file changed, 78 insertions(+), 11 deletions(-)
>>
>> diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
>> index 21db12fdab..8c5048cc13 100644
>> --- a/libavcodec/aacdec_template.c
>> +++ b/libavcodec/aacdec_template.c
>> @@ -387,17 +387,77 @@ static uint64_t sniff_channel_order(uint8_t
>> (*layout_map)[3], int tags)
>> i++;
>> }
>>
>> - // Must choose a stable sort
>> + // The previous checks would end up at 8 at this point for 22.2
>> + if (tags == 16 && i == 8) {
>> + e2c_vec[i] = (struct elem_to_channel) {
>> + .av_position = AV_CH_TOP_FRONT_CENTER,
>> + .syn_ele = layout_map[i][0],
>> + .elem_id = layout_map[i][1],
>> + .aac_position = layout_map[i][2]
>> + }; i++;
>> + i += assign_pair(e2c_vec, layout_map, i,
>> + AV_CH_TOP_FRONT_LEFT,
>> + AV_CH_TOP_FRONT_RIGHT,
>> + AAC_CHANNEL_FRONT);
>> + i += assign_pair(e2c_vec, layout_map, i,
>> + AV_CH_TOP_SIDE_LEFT,
>> + AV_CH_TOP_SIDE_RIGHT,
>> + AAC_CHANNEL_SIDE);
>> + e2c_vec[i] = (struct elem_to_channel) {
>> + .av_position = AV_CH_TOP_CENTER,
>> + .syn_ele = layout_map[i][0],
>> + .elem_id = layout_map[i][1],
>> + .aac_position = layout_map[i][2]
>> + }; i++;
>> + i += assign_pair(e2c_vec, layout_map, i,
>> + AV_CH_TOP_BACK_LEFT,
>> + AV_CH_TOP_BACK_RIGHT,
>> + AAC_CHANNEL_BACK);
>> + e2c_vec[i] = (struct elem_to_channel) {
>> + .av_position = AV_CH_TOP_BACK_CENTER,
>> + .syn_ele = layout_map[i][0],
>
> Does this code assume all types are CPE ?
> because if thats not true i can exceed the tags
>
>
>> + .elem_id = layout_map[i][1],
>> + .aac_position = layout_map[i][2]
>> + }; i++;
>> + e2c_vec[i] = (struct elem_to_channel) {
>> + .av_position = AV_CH_BOTTOM_FRONT_CENTER,
>> + .syn_ele = layout_map[i][0],
>> + .elem_id = layout_map[i][1],
>> + .aac_position = layout_map[i][2]
>> + }; i++;
>> + i += assign_pair(e2c_vec, layout_map, i,
>> + AV_CH_BOTTOM_FRONT_LEFT,
>> + AV_CH_BOTTOM_FRONT_RIGHT,
>> + AAC_CHANNEL_FRONT);
>> + }
>> +
>> total_non_cc_elements = n = i;
>> - do {
>> - int next_n = 0;
>> - for (i = 1; i < n; i++)
>> - if (e2c_vec[i - 1].av_position > e2c_vec[i].av_position) {
>> - FFSWAP(struct elem_to_channel, e2c_vec[i - 1],
>> e2c_vec[i]);
>> - next_n = i;
>> - }
>> - n = next_n;
>> - } while (n > 0);
>> +
>> + if (tags == 16 && total_non_cc_elements == 16) {
>> + // For 22.2 reorder the result as needed
>> + FFSWAP(struct elem_to_channel, e2c_vec[2], e2c_vec[0]); // FL &
>> FR first (final), FC third
>> + FFSWAP(struct elem_to_channel, e2c_vec[2], e2c_vec[1]); // FC
>> second (final), FLc & FRc third
>> + FFSWAP(struct elem_to_channel, e2c_vec[6], e2c_vec[2]); // LFE1
>> third (final), FLc & FRc seventh
>> + FFSWAP(struct elem_to_channel, e2c_vec[4], e2c_vec[3]); // BL &
>> BR fourth (final), SiL & SiR fifth
>> + FFSWAP(struct elem_to_channel, e2c_vec[6], e2c_vec[4]); // FLc
>> & FRc fifth (final), SiL & SiR seventh
>> + FFSWAP(struct elem_to_channel, e2c_vec[7], e2c_vec[6]); // LFE2
>> seventh (final), SiL & SiR eight (final)
>> + FFSWAP(struct elem_to_channel, e2c_vec[9], e2c_vec[8]); // TpFL
>> & TpFR ninth (final), TFC tenth (final)
>> + FFSWAP(struct elem_to_channel, e2c_vec[11], e2c_vec[10]); // TC
>> eleventh (final), TpSiL & TpSiR twelth
>> + FFSWAP(struct elem_to_channel, e2c_vec[12], e2c_vec[11]); // TpBL
>> & TpBR twelth (final), TpSiL & TpSiR thirteenth (final)
>
> Does this not need to check the assumtations from the comments ?
>
> thx
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Awnsering whenever a program halts or runs forever is
> On a turing machine, in general impossible (turings halting problem).
> On any real computer, always possible as a real computer has a finite
> number
> of states N, and will either halt in less than N cycles or never halt.
>
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
