Improve handling of AAC PCE audio channels with segmented MPEG-TS

[Brendan McGrath]

Summary of the bug:
I had been happily transcoding from AC3 (5.1 side) to AAC with HLS muxing. But after a recompile from 'master' I discovered audio had stopped working.

A 'git bisect' indicated that this stopped working with commit fc9dcfe7d50d7f1b38fb287b4d92b5f3fc4bfb05.

This commit marked '5.1 side' as not "normal" for AAC and thus a PCE entry was now required.

The PCE entry seems to work fine for the first segment of a segmented MPEG-TS, but subsequent MPEG-TS files don't appear to have an ASC (AudioSpecificConfig data structure).

Running ffprobe against the first segment (for example 'ffprobe hls0.ts') works fine and returns:

Input #0, mpegts, from 'hls0.ts':
  Duration: 00:00:02.01, start: 1.400000, bitrate: 382 kb/s
  Program 1 
    Metadata:
      service_name    : Service01
      service_provider: FFmpeg
    Stream #0:0[0x100](eng): Audio: aac (LC) ([15][0][0][0] / 0x000F), 48000 Hz, 6 channels, fltp, 378 kb/s

But running it on the second segment (for example 'ffprobe hls1.ts') returns:

[mpegts @ 0x1476040] decoding for stream 0 failed
[mpegts @ 0x1476040] Could not find codec parameters for stream 0 (Audio: aac (LC) ([15][0][0][0] / 0x000F), 0 channels, fltp, 426 kb/s): unspecified sample rate
Consider increasing the value for the 'analyzeduration' and 'probesize' options
hls1.ts: End of file

I discovered the failure occurs at libavcodec/aacdec_template.c:3126 - which has this check:

        if (!avctx->channels && elem_type != TYPE_PCE) {
            err = AVERROR_INVALIDDATA;
            goto fail;
        }

because avctx->channels == 0 and elem_type == TYPE_CPE.

I'm not sure of the solution though. I figure either:
a) Add the ASC to beginning of each TS segment (if possible);
b) Encode each AAC frame with a TYPE_CPE (if possible);
c) Have HLS default to fMP4 when an AAC CPE is in use (for which CPE seems to work); or
d) Produce a warning

Although I think option 'b)' breaks compatibility with older decoders (if it is even possible to do).

How to reproduce:

% ffmpeg -loglevel info -i in.ts -map 0:a -c:0 aac -f hls hls.m3u8
% ffprobe hls0.ts # works
% ffprobe hls1.ts # doesn't

ffprobe version N-89870-gbda5ad3 Copyright (c) 2007-2018 the FFmpeg developers

[Carl Eugen Hoyos]

See also #6965.

[Hendrik]

This appears to be caused by the ADTS muxer which is used when muxing MPEG-TS. ADTS streams with PCE require the PCE to be in-band as TYPE_PCE elements, and the ADTS muxer does insert the PCE as an in-band element - except, it only does it once at the beginning - hence the first segment works, and any further segments do not.

For a fully compliant ADTS stream in MPEG-TS, the PCE should probably be repeated on regular intervals. How often this should happen I do not know, I'm sure there is some specification that defines such intervals. Perhaps even in every audio frame?

[elsiko]

I tried opening a ticket too before for this: ​https://trac.ffmpeg.org/ticket/6983

Even though I can successfully play the files on my 2.0 setup, friends with a 5.1 home theatre reported my encodings to be 1 sided as well.

I'm not sure what to do, except use a ffmpeg source prior to 9 Nov 2017, when that commit was made.

[Carl Eugen Hoyos]

Replying to elsiko:

I tried opening a ticket too before for this: ​https://trac.ffmpeg.org/ticket/6983

I'm not sure what to do

As said you could tell us which decoder(s) fail.

[Brendan McGrath]

Potential workarounds for those who need them are:

1. add the option -ac 2 (to output stereo); or
2. add the option -af channelmap=channel_layout=5.1 (to output 5.1 back)

Note that even though ffmpeg states the output is 5.1 back - mediainfo still says:

Channel positions                        : Front: L C R, Side: L R, LFE

So ffmpeg and mediainfo don't see eye to eye. But the commit comment in fc9dcfe7d50d7f1b38fb287b4d92b5f3fc4bfb05 says:

The [presumably AAC] spec ... does list these layouts as having rear speakers

But I haven't sighted the spec myself - so I can't say which is right.

[pkv]

Table 42 of ISO/IEC 13818-7:2004(E) (default channel mappings) has indeed for 6 channels:

center front speaker
left, right front speakers,
left surround, right surround rear speakers,
front low frequency effects speaker

This is AV_CH_LAYOUT_5POINT1_BACK = "5.1" and not AV_CH_LAYOUT_5POINT1 = "5.1(side)" (see channel_layout.c, channel_layout_map[] ).
A workaround to avoid PCE being invoked for a 5.1(side) source is to add the option channel_layout='5.1' on the source. This is similar to what redmcg mentions.

So commit fc9dcfe7d50d7f1b38fb287b4d92b5f3fc4bfb05 is in line with spec.

[Gyan]

Workaround for HLS/TS which will avert the probe error and report expected stream properties is to add -hls_ts_options mpegts_flags=latm