After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 783583 - aacparse: wrong src caps profile for ADIF format aac clips
aacparse: wrong src caps profile for ADIF format aac clips
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
1.12.0
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2017-06-09 09:13 UTC by Lyon
Modified: 2018-11-03 15:19 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
ADIF sample clip (64.01 KB, audio/aac)
2017-06-09 09:13 UTC, Lyon
  Details
patch for fix adif profile issue (1.29 KB, patch)
2017-06-09 09:14 UTC, Lyon
none Details | Review

Description Lyon 2017-06-09 09:13:18 UTC
Created attachment 353443 [details]
ADIF sample clip

When I am trying to play some ADIF aac clips with LC profile, and the src caps output from aacparse is Main profile.

Checked the aacparse, for ADIF stream, the object_type is got as:

aacparse->object_type = ((adif[6 + skip_size] & 0x01) << 1) |
          ((adif[7 + skip_size] & 0x80) >> 7)

and in spec this object_type definition as below:
index    object_type
   0       AAC Main
   1       AAC LC
   2       AAC SSR
   3       AAC LTP

in aacparse to determine the profile, code as below:
  switch (profile) {
    case 1:
      return "main";
    case 2:
      return "lc";
    case 3:
      return "ssr";
    case 4:
      return "ltp";
    default:
      break;
  }

So actually here, aacparse->object_type need plus 1 to determine the profile (just as for ADTS stream.)
Comment 1 Lyon 2017-06-09 09:14:41 UTC
Created attachment 353444 [details] [review]
patch for fix adif profile issue
Comment 2 Arun Raghavan 2017-06-13 11:04:09 UTC
Hmm, I'm not sure this is the right thing to do. There seem to be 3 different things to consider:

  1. ADIF (and ADTS?) which signal the object type according to ISO/IEC 13818-7 (0 == "main")

  2. profileAndLevelIndication from DecoderSpecificConfig which is backwards compatible with 13818-7 (0 == "main")

  3. AudioSpecificConfig from ISO/IEC 14496-3 (1 == "main")

We likely should consolidate usages of gst_codec_utils_aac_*_profile to make sure it is consistent/correctly used as it was written to deal only with (3) above.
Comment 3 Lyon 2017-06-14 06:38:04 UTC
yes, I see in gstaacparse.c,  the channel / sample rate index / object type will be packaged as codec_data (AudioSpecificConfig) and then parse in gst_codec_uitls_aac_*_profile. (which deal with as above 3rd case)

Also for ADTS type file, in gst_aac_parse_parse_adts_header(above 1st case), the object_type got will convert to the 3rd case by plus 1 (*object = ((data[2] & 0xc0) >> 6) + 1;)

So similar as ADTS file format,  for ADIF format (above 1st case), the object_type got also need plus 1 to convert to above 3rd case:
      aacparse->object_type = (((adif[6 + skip_size] & 0x01) << 1) |
          ((adif[7 + skip_size] & 0x80) >> 7)) + 1;

That's what I suggested in the patch.

And in gst_codec_utils_aac_*_profile(), it can get the correct profile.
Comment 4 GStreamer system administrator 2018-11-03 15:19:42 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/issues/379.