Project

General

Profile

Bug #5887

AAC Audio Tracks Tagged Incorrectly

Added by Adam W 2 months ago. Updated 6 days ago.

Status:
Fixed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
2020-05-02
Due date:
% Done:

0%

Estimated time:
Found in version:
4.3-1857~g221c29b40
Affected Versions:

Description

This is leading on from another issue (#5697) regarding streaming raw AAC audio (using the raw audio profile) from programmes that use it in TVHeadend.

The stream types for AAC audio in TVHeadend are flagged incorrectly in the GUI (and I think internally too).

ADTS AAC audio (the norm for channels using AAC-LC stereo in MPEG-TS) is flagged incorrectly as 'AAC-LATM' in the stream type by TVHeadend. (e.g. in attached image for the Radio station Radio Regenbogen on Astra 1 12633H).

On the flipside, actual AAC LATM audio (usually used for HE-AAC tracks in MPEG-TS) is being flagged as just 'AAC' (e.g. attached image for TV channel BBC ONE HD on DVB-T2).

These are the wrong way round, AAC LATM should be flagging as AAC-LATM (as you'd expect!), and I think ADTS being flagged as 'AAC' would be correct too (this is how ADTS gets flagged by ffmpeg/avconv).

I'm not sure if this is just a labelling issue or it's causing other confusion in TVH too, but it's definitely the wrong way round.

As an aside, for the raw audio stream filter, it would be great if the AVConv/FFMPEG bitstream filter (-bsf:a aac_adtstoasc) could be applied to ADTS (AAC) streams to repackage them as LATM (without re-encoding the actual AAC audio data) - AAC LATM is the format that is supported for 'regular' AAC web streams, in internet radios and speakers. ADTS isn't so widely supported (it won't play on my Sonos devices or my internet radio for example). I guess this could be done either automatically or as a tickbox in the raw audio stream filter settings. Basically I think raw AAC audio output should be with LATM headers as standard for maximum compatibility.


Files

Radio_Regenbogen_ADTS.png (90.3 KB) Radio_Regenbogen_ADTS.png ADTS being flagged as AAC-LATM Adam W, 2020-05-02 00:31
BBC_ONE_HD_LATM.png (146 KB) BBC_ONE_HD_LATM.png LATM being flagged as AAC (ADTS) Adam W, 2020-05-02 00:31

History

#1

Updated by Adam W 2 months ago

Further investigation of this -

Because of the wrong way round tagging (ADTS as LATM and vice versa), TVHeadend in-built transcoding for these audio tracks does not work for either type. No audio is delivered when trying to transcode.

Raw audio (without transcoding) does work in VLC, because the raw ADTS or LATM is just passed without having to be parsed by AVConv in TVH.

I don't understand the code very well, but I did find something that looks like a mix-up of the two!

In the esstream.h file we have -

SCT_AAC,     /* AAC-LATM in MPEG-TS, ADTS + AAC in packet form */

SCT_MP4A,    /* ADTS + AAC in MPEG-TS and packet form */

So ADTS as SCT_MP4A and LATM as SCT_AAC.

Whereas in streaming.c we have the opposite -

{ "AAC",        SCT_AAC },

{ "AAC-LATM",   SCT_MP4A },

I think one of these is the wrong way round which I guess could be causing the mix-up!

I also found in libav.c -

  case SCT_MP4A:
  case SCT_AAC:
    codec_id = AV_CODEC_ID_AAC;
    break;

I think whichever of them is the AAC LATM one should be mapped to 'AV_CODEC_ID_AAC_LATM'.

In the rest of the code, 'AV_CODEC_ID_AAC' is just being treated as ADTS, even though both types of AAC are mapped to it, with a function for transcoding to remove the ADTS header - this will never work for LATM!

src/muxer/muxer_libav.c -

} else if (codec_id == AV_CODEC_ID_AAC) {
      /* remove ADTS header */
      packet.data = pktbuf_ptr(pkt->pkt_payload) + 7;
      packet.size = pktbuf_len(pkt->pkt_payload) - 7;
#2

Updated by Adam W 2 months ago

Did some more investigation and finally got to the bottom/fixed these issues.

What I hadn't fully realised is that TVHeadend re-packages LATM audio with ADTS headers internally before outputting a raw stream (in parser_latm.c).

So the issue is actually - why does raw ADTS audio that TVHeadend creates itself from an AAC-LATM source work with my Sonos speaker/Internet radio, but raw ADTS audio that was already ADTS in the MPEG-TS not work?

The answer is in the content type/MIME headers! In src/muxer.c -

{ "audio/aac",                MC_AAC },
{ "audio/mp4",                MC_MP4A },

MC_AAC (which maps to AAC-LATM streams), is output with the MIME type of 'audio/aac', whereas MC_MP4A (which maps to AAC - ADTS in MPEG-TS) is output with the MIME type of 'audio/mp4'.

As both are being output as ADTS in the end, this doesn't make sense as they are the same stream structure!

So, I changed the MC_MP4A line to be 'audio/aac' (the same as MC_AAC) -

{ "audio/aac",                MC_MP4A },

And... bingo! MPEG-TS ADTS raw audio streams now work perfectly with my internet radios!

I also swapped the mapping in streaming.c which fixes the web interface flagging in the display of AAC and AAC-LATM -

{ "AAC-LATM",   SCT_AAC },
{ "AAC",        SCT_MP4A },

I've never contributed before, but I can commit these changes for review on GitHub if that would be helpful?

#3

Updated by Adam W 2 months ago

Changing the streaming.c labels also then requires this change in htsp_server.c so that AAC-LATM gets reported as 'AAC' in HTSP. (Otherwise there's no sound in Kodi on channels with AAC-LATM audio, such as UK DVB-T2 HD channels) -

-if (ssc->es_type == SCT_MP4A)
+if (ssc->es_type == SCT_AAC)
      type = "AAC"; /* override */
#4

Updated by Flole Systems 6 days ago

  • Status changed from New to Fixed

Also available in: Atom PDF