Add option to DefaultTrackSelector to enable cross-sampleRate audio adaptation

[0c6a183d]

Issue description

My .mpd file references 3 audio tracks (No Video).
3 qualities are available 24, 80 and 320Kbps.
The same track has been encoded to M4A using the same tool fdkAAC.exe, but with different output switches/codecs.

Track 1 24k(AAC-HEv2)(mp4a.40.29)(22050) - Codec required to make 24k sound satisfactory
Track 2 80k(AAC-HE)(mp4a.40.5)(22050) - Codec required as AAC-HEv2 only works up to 64K
Track 3 320k(AAC-LC)(mp4a.40.2)(41000) - Codec best for high bit rates, below 100k is starts getting poor

Note the different sample rates detected by the DASH media creation tool. (22050/44100)
This is correct apparently, as Wikipedia states:
"The HE-AAC and HE-AACv2 profiles encode audio using AAC-LC at one half the sample rate, relying on Spectral Band Replication (SBR) to attempt reconstruction of the missing higher frequencies"

When running my app on a physical device (LG G3 Android 5.0) and using a router to control bandwidth, tracks 1&2 are utilized as expected (Adaptive Track Selection Switching between them occurs). But the Adaptive Track Selection will not select track 3.

If I quickly edit the .mpd and change track 3 audioSampleRate from 44100 to 22050 and restart the audio, it works and switches between 1,2 & 3.

Using the same URL with the browser based DASH JavaScript player seems to work OK and all three tracks are utilized.

I am aware that the ability to adaptively switch between tracks encoded with different codecs is a recent feature so am curious to find out if this is a bug, a limitation of my device, or just my dodgy coding. Also I would like to know if editing the mpd sample rate as a work around affects the audio, as it seems to play OK.

Reproduction steps

1. Using Exoplayer - Attempt to play supplied manifest file 1.mpd (Original) Only tracks 1&2 should work
2. Using Exoplayer - Attempt to play supplied manifest file 2.mpd (Edited to force 44100 on track 3) Tracks 1&2&3 should be work.

Link to test content

Emailing in links to 2 x manifest files

Version of ExoPlayer being used

2.5.1 & 2.5.3

Device(s) and version(s) of Android being used

LG G3 Android 5.0

A full bug report captured from the device

Not sure if this is required at this state as it may be an non/known issue.

[ojw28]

We don't enable adaptation between different sample rates by default. Switching from one sample rate to another requires reconfiguration of the underlying AudioTrack, which I don't think can be performed in a completely seamless way.

[0c6a183d]

OK - Thank you for confirming so quickly.

Seems to play fine if I edit the mpd so all tracks to use 22050 or 44100. There is no mention of 22050 in the AudioTrack: logcat output at any point when any of the three tracks start playing so it does seem the mpd is not final decision as it seems to play them all at 44100 anyway. As long as all tracks are set at the same sample rate the Adaptive Switching Seems to work fine.

[ojw28]

There should be a small discontinuity when switching between tracks of different sample rates. We release and re-initialize the underlying platform AudioTrack when this occurs. This happens here because this.sampleRate == sampleRate in the check above should evaluate to false (this should be true even when you lie about it in the DASH manifest, since the values used in this part of the code are derived from the actual media stream). If you attach a debugger, you'll probably be able to see that reset is being called here.

Perhaps the discontinuity is small enough that you don't really notice (in which case great!). There's no particular reason why we couldn't add an option to DefaultTrackSelector that enables adapting across different sample rate audio tracks. We'd probably keep it defaulted to off, at least initially, and allow the application to enable it if desired. What do you think?

[0c6a183d]

I think that would be a good addition - And yes, disabled by default to keep the transition as seamless as possible, for those who may have inadvertently generated media tracks with different sample rates. They would then have the option to enable the automatic switching between tracks with differing sample rates and accept a possible minor "discontinuity", or chose to re-encode the media all at the same sample rate.

The switching at my end is near perfect gap-less on my old Lollipop S4 and G3 between the higher bit-rates with different sample rates (80-320Kbps) - Not noticeable when listening to fast dance music, probably a few ms at most. That would only improve I would guess on a high end phone. More noticeable when alternating with the super low 24Kbps but it is a very different quality codec (almost mono) so the majority of the transition effect is probably the loss in stereo effect and increase in the audio compression.

As a temporary workaround to enable the adaptive switching between all audio tracks with differing sample rates in my mpd file, I have removed the entire section audioSamplingRate="xxxxxx" - This seems to work OK and I have not had any issues... yet.

[tonihei]

Closing as all required new options have been added.