Fix playback of AAC in TS files

[lawadr]

When the channel config is 0 in the ADTS header, delay the submission of the format to the output until a Program Config Element (PCE) is found and appended to the format's initialization data.

This reproduces the initialization data payload that is submitted by the same AAC stream when inside other containers such as MP4 or MKV.

Fixes issue #695

[google-cla[bot]]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[rohitjoins]

Hi @lawadr,

Can we also please add a test for this in AdtsReaderTest.java?

[lawadr]

Hi @lawadr,

Can we also please add a test for this in AdtsReaderTest.java?

No problem. I've just pushed a couple.

It needed a second test because the first would succeed with the old behaviour (pre-this PR) as we can't easily assert the submitted format's initializationData. The second ensures that the format is withheld until the PCE is found, so it's a test for failure. This second test would "succeed" with the old code where as it shouldn't now.

[rohitjoins]

I'm going to send this for internal review now. You may see some more commits being added as I make changes in response to review feedback. Please refrain from pushing any more substantive changes as it will complicate the internal review - thanks!

[rohitjoins]

Hi @lawadr,

I created the HLS file using the command stated above. Here are my observations:

when -aac_pce 1 is used, PCE data is only appended to the first ADTS frame

• using ffprobe for first ts file, produces output without any error: but doing the same for the second ts file produced gives an error:
• similarly you can use mediainfo on these ts files and can see that the channel layout is only shown for the first file but not the second file.
• if you remove the -aac_pce 1 when encoding all ts files contains the channel layout information

Found a similar issue reported on FFmpeg: https://trac.ffmpeg.org/ticket/6974

Is there a use case where media files are encoded using the command above?

I'll try and discuss internally if it is fine to not throw an error when a PCE data is already read before as it is may not be mandatory to send PCE data in each frame. Although that will still mean starting the stream from middle (not start) would still fail the playback.

[lawadr]

Is there a use case where media files are encoded using the command above?

Not really, because the example command above is to force a PCE for a standard 2.1 audio stream for testing/reproduction purposes. Typically you would see a PCE when the standard 7 channel types enumerated in the ADTS header aren't sufficient. In the original sample stream I provided, the channel setup was:

• 1x front SCE
• 1x front CPE
• 2x back CPE
• 1x LFE

I've no idea why the second CPE isn't a side CPE (and therefore standard 7.1) as I didn't author the sample, but nevertheless, the likes of VLC handles it fine, and with the fix in this PR so does ExoPlayer+MediaCodec.

Although that will still mean starting the stream from middle (not start) would still fail the playback.

Yes. This would unfortunately be the case. Perhaps this could be for later enhancement.

For my use case, being able to play from the beginning of the stream is vital. Being able to jump 10s back when you miss something is almost as vital. Being able to start from the middle isn't the most important thing as you can just start from the beginning and skip ahead to where you were.

[ArpadK]

is there any update on this issue?

[FongMi]

@lawadr @rohitjoins is there any update on this issue? Test url http://125.69.183.125:666/udp/239.132.1.87:5000