On Sun, Aug 16, 2020 at 2:15 AM 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
>
Sorry for responding late, I have been tired and didn't find a good
spot to write things down.
No, it should not assume that all types are CPE. 22.2 utilizes both
CPE, SCE as well as LFE. The full definition of 22.2 was added in
93a2913ac8a3aa25c05fd30036da89cb493e68ee with each coding element
being documented as it is in the spec.
OK, then I did misunderstand what exactly the `tags` variable means
and how it can go over (if that is a problem other than 22.2 with more
coding elements than in standard samples not hitting this logic).
>
> > + .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 ?
Technically, if the input is not standard 22.2 AAC coding order, it
would lead to incorrect output order. I did wish for comments on this,
since I was torn between this and just rewriting the checks to not be
like the rest of the function and instead utilizing a hard-coded order
if the elements seemed to be there.
Additionally, I did think if I should utilize the identifier (13) for
additional checks, but the function so far completely ignored that and
based on tags.
Thus, I just attempted to implement it in a similar way as the rest of
the code in the function, and did not receive comments about it.
Jan
>
> 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".
--
I'm human - no debug
_______________________________________________
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".
