一、前言
自适应流切换属于多路流切换的方式中的一种，ExoPlayer作为MediaCodec使用的集大成者，不仅具备通过MergingMediaSource实现不同流的组合切换，同样也具备基于MGEG-DASH、HLS、smoothing-stream 协议的的自适应流切换。当然，在项目中每种方案的选型都要充分考虑团队条件。
主要区别如下：
- MergingMediaSource 方式更适合团队人力有限，后台服务支持有限的情况，不需要在资源传输和编码上做更多的考虑，普通的CDN部署就可以，相比更加节省成本。而自适应流相对要求比较专业，对服务器的部署、资源分片、资源编码也是有一定要求的。
- MergingMediaSource 方式可实现不同编码的流合并，而自适应流方面部分协议如HLS有较严格的要求，主要要求是ts分片的编码尽可能保持一致，这样做的目的是为尽可能实现MediaCODEc的重复利用。当然，MergingMediaSource方式如果每路流的Format差别不大，视频解码器完全可以通过PPS、SPS或flush buffer 的方式实现MediaCodec利用，音频解码器也是可以通过输入特定字节特征实现MediaCodec复用。
- 在ExoPlayer中，MergingMediaSource 中的同一类型（视频类型、音频类型、字幕类型等）的数据，由于缺乏必要的码率参数， 无法将相似Format的Track数据合并为一组，因此使用的FixedTrackSelection对同一类型的资源，自然而然也不支持多路流的自动切换。而自适应流完成可以实现Format分组，最终创建AdaptiveTrackSelection 动态管理各路流。
二、基础知识点
前言的内容对于初学ExoPlayer开发者而言还是有些抽象，下面我们梳理一下ExoPlayer的关键类，方便理解本篇内容。
- Renderer渲染器：负责解码器的Format支持能力检测、解码器的注册、解码器的销毁、解码器的复用、采样数据读取、数据渲染或输出、丢帧、跳帧以及音画同步等工作。ExoPlayer支持Renderer的拆解、组合、关闭和启用，也支持自定义的解码器接入，比如通过SimpleDecoder实现FFMPEG对视频和音频的解码渲染。
- MediaClock媒体时钟：负责音画同步、播放进度管理等工作。在ExoPlayer中国存在两种时钟，一种是独立时钟StandaloneMediaClock，另一种是通过音频Renderer实现的Audio Master模式的时钟。
- Extractor 解封装器：负责将媒体资源中的每一路流的Moov信息、采样表、Format、采样数据（如SPS、PPS、各种帧数据）拆解出来，同时会对一些数据，便于Track和Format的选择以及码流切换。ExoPlayer内置了大量的解封装器，同样也支持自定义的Extractor来实现特定目的。当然，自适应流Format的解析一般是通过MediaSource去解析的，只有视频容器需要通过Extractor去解析。
- Decoder解码器：负责解码采样数据，其中MediaCodec具备使用硬解和软解的能力的同时，而且支持渲染。
- TrackSelector：多路流切换的核心类，负责通过Format检测实现TrackSelection的分组、以及TrackGroup和Renderer、TrackGroup和TrackSelection的配对工作。
- DataSource 数据源：负责提供数据。
- MediaSource 媒体源：在ExoPlayer中，得益于对从DataSource中抽象出了MediaSource，使得ExoPlayer在多路流管理方面更加灵活方便。
- SeekPoint：在ExoPlayer中，SeekPoint 往往是IDR帧即将开始的位置。
- FixedTrackSelection：固定流选择器，播放过程中TrackSelection保持固定，普通协议默认的TrackSelection，但也因为这个原因，使得其适用于MergingMediaSource方式的多路流切换。
- AdptiveTrackSelection: 自适应流选择器，可以根据bandwidth实现动态选择分片。当然，可以通过一些策略，实现用户自行的切换，类似bilibili的码流切换。
- TrackGroup : 同一类型资源的Track Format 分组。
- MapTrackInfo : 这个类实际上是一个Renderer和TrackGroup相关信息的集合类，主要保存Renderer能力信息和TrackGroup信息，某种程度上可以看到数据格式和Renderer全局信息。
- selection分组原理：TrackSelector会通过SELECTION_ELIGIBILITY_FIXED、SELECTION_ELIGIBILITY_ADAPTIVE对资源进行分组，当然前提是各个Format之间能够相互兼容，具体兼容逻辑参考VideoTrackInfo类和AudioTrackInfo类。
- Bandwidth：ExoPlayer中对网速检测的重要工具，检测结果用于AdaptiveTrackSelection进行分片选择。
- DefaultMediaSourceFactory 用于实现DataSource转换为MediaSource的路由工厂，通过mineType和URI后缀识别出创建那种MediaSource。
三、自适应流切换分析
3.1 原理图
在不同网速时自动切换为兼容当前bitrate的媒体流，匹配条件一般在自适应流的清单文件中就已经提前设定了，保证当前网络的bitrate大于清单协议中媒体流的最低bandWidth，就可以切换到指定的媒体流Track。
通过原理图我们可以了解到以下信息：
- 默认情况下，自适应流的切换不需要查找SeekPoint，而是通过选择下一个分片实现。
- 默认情况下，自适应流通过网速检测实现了分片切换。
- 从图上可知，每个分片的的播放时间和I帧的开始位置也需要做到严格对齐。
注意：之所以强调默认情况，一个重要的原因是ExopPlayer具备高度可扩展性，我们可以通过修改部分代码实现其他行为。
3.2 核心逻辑
核心逻辑主要为：
- 清单文件解析
- 建立Renderer与TrackGroup、Selection之间的映射关系
- 开始分片加载
- 网速带宽检测 与 AdaptiveTrackSelection 选择合适的分片
- 解码器复用或重启
- 完成切换
3.2.1 自适应流清单文件解析
ExoPlayer中支持DASH、HLS、Smoothing-Stream协议，我们这里以HLS和DASH协议进行流程分析，毕竟目前使用Smoothing-Stream也就微软自己为主。接下来先看看HLS和DASH的清单文件，方便我们后续测试。
3.2.1.1 hls 协议清单文件
#EXTM3U
#EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID="bipbop_audio",LANGUAGE="eng",NAME="BipBop Audio 1",AUTOSELECT=YES,DEFAULT=YES
#EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID="bipbop_audio",LANGUAGE="eng",NAME="BipBop Audio 2",AUTOSELECT=NO,DEFAULT=NO,URI="alternate_audio_aac/prog_index.m3u8"
#EXT-X-MEDIA:TYPE=SUBTITLES,GROUP-ID="subs",NAME="English",DEFAULT=YES,AUTOSELECT=YES,FORCED=NO,LANGUAGE="en",CHARACTERISTICS="public.accessibility.transcribes-spoken-dialog, public.accessibility.describes-music-and-sound",URI="subtitles/eng/prog_index.m3u8"
#EXT-X-MEDIA:TYPE=SUBTITLES,GROUP-ID="subs",NAME="English (Forced)",DEFAULT=NO,AUTOSELECT=NO,FORCED=YES,LANGUAGE="en",URI="subtitles/eng_forced/prog_index.m3u8"
#EXT-X-MEDIA:TYPE=SUBTITLES,GROUP-ID="subs",NAME="Français",DEFAULT=NO,AUTOSELECT=YES,FORCED=NO,LANGUAGE="fr",CHARACTERISTICS="public.accessibility.transcribes-spoken-dialog, public.accessibility.describes-music-and-sound",URI="subtitles/fra/prog_index.m3u8"
#EXT-X-MEDIA:TYPE=SUBTITLES,GROUP-ID="subs",NAME="Français (Forced)",DEFAULT=NO,AUTOSELECT=NO,FORCED=YES,LANGUAGE="fr",URI="subtitles/fra_forced/prog_index.m3u8"
#EXT-X-MEDIA:TYPE=SUBTITLES,GROUP-ID="subs",NAME="Español",DEFAULT=NO,AUTOSELECT=YES,FORCED=NO,LANGUAGE="es",CHARACTERISTICS="public.accessibility.transcribes-spoken-dialog, public.accessibility.describes-music-and-sound",URI="subtitles/spa/prog_index.m3u8"
#EXT-X-MEDIA:TYPE=SUBTITLES,GROUP-ID="subs",NAME="Español (Forced)",DEFAULT=NO,AUTOSELECT=NO,FORCED=YES,LANGUAGE="es",URI="subtitles/spa_forced/prog_index.m3u8"
#EXT-X-MEDIA:TYPE=SUBTITLES,GROUP-ID="subs",NAME="日本語",DEFAULT=NO,AUTOSELECT=YES,FORCED=NO,LANGUAGE="ja",CHARACTERISTICS="public.accessibility.transcribes-spoken-dialog, public.accessibility.describes-music-and-sound",URI="subtitles/jpn/prog_index.m3u8"
#EXT-X-MEDIA:TYPE=SUBTITLES,GROUP-ID="subs",NAME="日本語 (Forced)",DEFAULT=NO,AUTOSELECT=NO,FORCED=YES,LANGUAGE="ja",URI="subtitles/jpn_forced/prog_index.m3u8"
#EXT-X-STREAM-INF:BANDWIDTH=263851,CODECS="mp4a.40.2, avc1.4d400d",RESOLUTION=416x234,AUDIO="bipbop_audio",SUBTITLES="subs"
gear1/prog_index.m3u8
#EXT-X-I-FRAME-STREAM-INF:BANDWIDTH=28451,CODECS="avc1.4d400d",URI="gear1/iframe_index.m3u8"
#EXT-X-STREAM-INF:BANDWIDTH=577610,CODECS="mp4a.40.2, avc1.4d401e",RESOLUTION=640x360,AUDIO="bipbop_audio",SUBTITLES="subs"
gear2/prog_index.m3u8
#EXT-X-I-FRAME-STREAM-INF:BANDWIDTH=181534,CODECS="avc1.4d401e",URI="gear2/iframe_index.m3u8"
#EXT-X-STREAM-INF:BANDWIDTH=915905,CODECS="mp4a.40.2, avc1.4d401f",RESOLUTION=960x540,AUDIO="bipbop_audio",SUBTITLES="subs"
gear3/prog_index.m3u8
#EXT-X-I-FRAME-STREAM-INF:BANDWIDTH=297056,CODECS="avc1.4d401f",URI="gear3/iframe_index.m3u8"
#EXT-X-STREAM-INF:BANDWIDTH=1030138,CODECS="mp4a.40.2, avc1.4d401f",RESOLUTION=1280x720,AUDIO="bipbop_audio",SUBTITLES="subs"
gear4/prog_index.m3u8
#EXT-X-I-FRAME-STREAM-INF:BANDWIDTH=339492,CODECS="avc1.4d401f",URI="gear4/iframe_index.m3u8"
#EXT-X-STREAM-INF:BANDWIDTH=1924009,CODECS="mp4a.40.2, avc1.4d401f",RESOLUTION=1920x1080,AUDIO="bipbop_audio",SUBTITLES="subs"
gear5/prog_index.m3u8
#EXT-X-I-FRAME-STREAM-INF:BANDWIDTH=669554,CODECS="avc1.4d401f",URI="gear5/iframe_index.m3u8"
#EXT-X-STREAM-INF:BANDWIDTH=41457,CODECS="mp4a.40.2",AUDIO="bipbop_audio",SUBTITLES="subs"
gear0/prog_index.m3u8
3.2.1.2 DASH协议清单文件
<?xml version="1.0" encoding="UTF-8"?>
<!--Generated with https://github.com/google/shaka-packager version 97fc982-release-->
<MPD xmlns="urn:mpeg:dash:schema:mpd:2011" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xlink="http://www.w3.org/1999/xlink" xsi:schemaLocation="urn:mpeg:dash:schema:mpd:2011 DASH-MPD.xsd" xmlns:cenc="urn:mpeg:cenc:2013" minBufferTime="PT2S" type="static" profiles="urn:mpeg:dash:profile:isoff-on-demand:2011" mediaPresentationDuration="PT734S">
<Period id="0">
<AdaptationSet id="0" contentType="audio" lang="en">
<Representation id="0" bandwidth="131596" codecs="mp4a.40.2" mimeType="audio/mp4" audioSamplingRate="44100">
<AudioChannelConfiguration schemeIdUri="urn:mpeg:dash:23003:3:audio_channel_configuration:2011" value="2"/>
<BaseURL>tears_audio_eng.mp4</BaseURL>
<SegmentBase indexRange="745-1664" timescale="44100">
<Initialization range="0-744"/>
</SegmentBase>
</Representation>
</AdaptationSet>
<AdaptationSet id="1" contentType="video" maxWidth="1920" maxHeight="856" frameRate="12288/512" par="38:17">
<Representation id="1" bandwidth="769255" codecs="avc1.42c01e" mimeType="video/mp4" sar="852:857" width="320" height="142">
<BaseURL>tears_h264_baseline_240p_800.mp4</BaseURL>
<SegmentBase indexRange="827-1602" timescale="12288">
<Initialization range="0-826"/>
</SegmentBase>
</Representation>
<Representation id="2" bandwidth="1774254" codecs="avc1.4d401f" mimeType="video/mp4" sar="2242:2249" width="854" height="380">
<BaseURL>tears_h264_main_480p_2000.mp4</BaseURL>
<SegmentBase indexRange="829-1604" timescale="12288">
<Initialization range="0-828"/>
</SegmentBase>
</Representation>
<Representation id="3" bandwidth="7203938" codecs="avc1.4d4028" mimeType="video/mp4" sar="855:857" width="1280" height="570">
<BaseURL>tears_h264_main_720p_8000.mp4</BaseURL>
<SegmentBase indexRange="830-1605" timescale="12288">
<Initialization range="0-829"/>
</SegmentBase>
</Representation>
<Representation id="4" bandwidth="18316946" codecs="avc1.64002a" mimeType="video/mp4" sar="856:857" width="1920" height="856">
<BaseURL>tears_h264_high_1080p_20000.mp4</BaseURL>
<SegmentBase indexRange="832-1607" timescale="12288">
<Initialization range="0-831"/>
</SegmentBase>
</Representation>
</AdaptationSet>
</Period>
</MPD>
两种协议的共同点中我们可以明确的发现又很多共同点：
- bandWidth: 网络带宽，也就是下载的速率，但是在清单文件中一般表示的是支持该数据流的最低下载速率。
- mimeType : 资源类型
- codecs: 资源编码类型
- width: 视频宽度
- height: 视频高度
和其他协议的资源不同的是，由于使用清单文件的原因，基本可以实现在解封装之前就能获取到必要的Format信息。
解析时清单文件时，如果使用的是HLS协议，ExoPlayer内部利用HlsPlaylistParser类作为清单文件解析工具，如果是DASH则使用DashManifestParser解析清单，依次类推，smoothing-stream 使用SsmanifestParser进行将进行清单文件解析。
解析的流程主要如下
- 使用DefaultMediaSourceFactory创建对应的自适应流MediaSource，如HlsMediaSource、DashMediaSource、SsMediaSource。
- 自适应流MediaSource创建Parser解析工具，当然HlsMediaSource比较特殊，不直接持有Parser，而是通过DefaultHlsPlaylistTracker时线对Parser的调度。
- 创建Loader和ParsingLoadable，ParsingLoadable类似于Runnable，属于加载任务，在ParsingLoadable中可以实现边加载边解析。
- 对每组Track Format进行分组，使用TrackGroup保存分组信息。
3.2.2 Renderer与TrackGroup、Selection选择
在ExoPlayer中，DefaultTrackSelector主要负责这项工作，核心逻辑如下
@Override
protected final Pair<@NullableType RendererConfiguration[], @NullableType ExoTrackSelection[]>
selectTracks(
MappedTrackInfo mappedTrackInfo,
@Capabilities int[][][] rendererFormatSupports,
@AdaptiveSupport int[] rendererMixedMimeTypeAdaptationSupport,
MediaPeriodId mediaPeriodId,
Timeline timeline)
throws ExoPlaybackException {
Parameters parameters;
synchronized (lock) {
parameters = this.parameters;
if (parameters.constrainAudioChannelCountToDeviceCapabilities
&& Util.SDK_INT >= 32
&& spatializer != null) {
// Initialize the spatializer now so we can get a reference to the playback looper with
// Looper.myLooper().
spatializer.ensureInitialized(this, checkStateNotNull(Looper.myLooper()));
}
}
int rendererCount = mappedTrackInfo.getRendererCount();
// 建立Renderers 与 TrackGroup 映射，注意，我们前面提到的MappedTrackInfo，保存有Renderer和TrackGroup的相关信息
// 这里也会尝试对不同TrackGroup Format进行依据兼容性进行合并分组到definition中
ExoTrackSelection.@NullableType Definition[] definitions =
selectAllTracks(
mappedTrackInfo,
rendererFormatSupports,
rendererMixedMimeTypeAdaptationSupport,
parameters);
//对筛选出来的defintions 二次过滤
applyTrackSelectionOverrides(mappedTrackInfo, parameters, definitions);
applyLegacyRendererOverrides(mappedTrackInfo, parameters, definitions);
//三次过滤，对Renderer不能使用解除映关系
// Disable renderers if needed.
for (int i = 0; i < rendererCount; i ) {
@C.TrackType int rendererType = mappedTrackInfo.getRendererType(i);
if (parameters.getRendererDisabled(i)
|| parameters.disabledTrackTypes.contains(rendererType)) {
definitions[i] = null;
}
}
//建立TrackGroup与Selection之间的映射关系，并且传入BandwidthMeter用于获取网速策略的数据
@NullableType
ExoTrackSelection[] rendererTrackSelections =
trackSelectionFactory.createTrackSelections(
definitions, getBandwidthMeter(), mediaPeriodId, timeline);
// Initialize the renderer configurations to the default configuration for all renderers with
// selections, and null otherwise.
//创建Renderer初始化配置
@NullableType
RendererConfiguration[] rendererConfigurations = new RendererConfiguration[rendererCount];
for (int i = 0; i < rendererCount; i ) {
@C.TrackType int rendererType = mappedTrackInfo.getRendererType(i);
boolean forceRendererDisabled =
parameters.getRendererDisabled(i) || parameters.disabledTrackTypes.contains(rendererType);
boolean rendererEnabled =
!forceRendererDisabled
&& (mappedTrackInfo.getRendererType(i) == C.TRACK_TYPE_NONE
|| rendererTrackSelections[i] != null);
rendererConfigurations[i] = rendererEnabled ? RendererConfiguration.DEFAULT : null;
}
// Configure audio and video renderers to use tunneling if appropriate.
if (parameters.tunnelingEnabled) {
//这种属于隧道渲染，具体流程好像是MediaCodec不负责解码，可以将未解码的数据输出到驱动层，由驱动层处理，如ac3音频数据直接输出到AudioTrack中，这方面资料太少，后续在研究。
maybeConfigureRenderersForTunneling(
mappedTrackInfo, rendererFormatSupports, rendererConfigurations, rendererTrackSelections);
}
return Pair.create(rendererConfigurations, rendererTrackSelections);
}
这部分逻辑相对很复杂，但是我们com.google.android.exoplayer2.trackselection.AdaptiveTrackSelection.Factory#createTrackSelections要做必要的分析。
在ExoPlayer中默认使用改工厂适配Selection，具体逻辑如下
@Override
public final @NullableType ExoTrackSelection[] createTrackSelections(
@NullableType Definition[] definitions,
BandwidthMeter bandwidthMeter,
MediaPeriodId mediaPeriodId,
Timeline timeline) {
ImmutableList<ImmutableList<AdaptationCheckpoint>> adaptationCheckpoints =
getAdaptationCheckpoints(definitions);
ExoTrackSelection[] selections = new ExoTrackSelection[definitions.length];
for (int i = 0; i < definitions.length; i ) {
@Nullable Definition definition = definitions[i];
if (definition == null || definition.tracks.length == 0) {
continue;
}
//遍历所有的definition，对分组中tracks 数量为1的创建FixedTrackSelection，对存在多个的创建AdaptiveTrackSeletion
selections[i] =
definition.tracks.length == 1
? new FixedTrackSelection(
definition.group,
/* track= */ definition.tracks[0],
/* type= */ definition.type)
: createAdaptiveTrackSelection(
definition.group,
definition.tracks,
definition.type,
bandwidthMeter,
adaptationCheckpoints.get(i));
}
return selections;
}
至此，Renderer 、TrackGroup、selection的映射关系建立完成。
那么这里有个疑问，如果利用MergingMediaSource合并多路流并修改参数，能否也实现AdaptiveTrackSelection，进入试下自适应能力？答案是否定的，因为MergingMediaSource合并的是完整的资源，在使用过程中并不会调用TrackSelection相关方法，当然ExoPlayer也没有实现资源的动态分片。
3.2.3 分片加载
DASH、HLS、Smoothing-Stream 加载分片的时候，单个分片都是用各自的实现的ChunkSource类，但是对于存在多个分片情况，ExoPlayer利用ChunkSampleStream和HlsSampleStreamWrapper将分片队列管理起来，核心方法是continueLoading中的实现，大致相同，这里以HlsSampleStreamWrapper的为参考。
public boolean continueLoading(long positionUs) {
if (loadingFinished || loader.isLoading() || loader.hasFatalError()) {
return false;
}
boolean pendingReset = isPendingReset();
//获取资源队列
List<BaseMediaChunk> chunkQueue;
//获取上次加载资源时间位置
long loadPositionUs;
if (pendingReset) {
chunkQueue = Collections.emptyList();
loadPositionUs = pendingResetPositionUs;
} else {
chunkQueue = readOnlyMediaChunks;
loadPositionUs = getLastMediaChunk().endTimeUs;
}
//获取下一个分片
chunkSource.getNextChunk(positionUs, loadPositionUs, chunkQueue, nextChunkHolder);
boolean endOfStream = nextChunkHolder.endOfStream;
@Nullable Chunk loadable = nextChunkHolder.chunk;
nextChunkHolder.clear();
if (endOfStream) {
// 如果没有资源可以加载了，标记加载结束
pendingResetPositionUs = C.TIME_UNSET;
loadingFinished = true;
return true;
}
if (loadable == null) {
return false;
}
//下面逻辑是加载状态直接的判断
loadingChunk = loadable;
if (isMediaChunk(loadable)) {
BaseMediaChunk mediaChunk = (BaseMediaChunk) loadable;
if (pendingReset) {
// Only set the queue start times if we're not seeking to a chunk boundary. If we are
// seeking to a chunk boundary then we want the queue to pass through all of the samples in
// the chunk. Doing this ensures we'll always output the keyframe at the start of the chunk,
// even if its timestamp is slightly earlier than the advertised chunk start time.
if (mediaChunk.startTimeUs != pendingResetPositionUs) {
primarySampleQueue.setStartTimeUs(pendingResetPositionUs);
for (SampleQueue embeddedSampleQueue : embeddedSampleQueues) {
embeddedSampleQueue.setStartTimeUs(pendingResetPositionUs);
}
}
pendingResetPositionUs = C.TIME_UNSET;
}
mediaChunk.init(chunkOutput);
mediaChunks.add(mediaChunk);
} else if (loadable instanceof InitializationChunk) {
((InitializationChunk) loadable).init(chunkOutput);
}
long elapsedRealtimeMs =
loader.startLoading(
loadable, this, loadErrorHandlingPolicy.getMinimumLoadableRetryCount(loadable.type));
mediaSourceEventDispatcher.loadStarted(
new LoadEventInfo(loadable.loadTaskId, loadable.dataSpec, elapsedRealtimeMs),
loadable.type,
primaryTrackType,
loadable.trackFormat,
loadable.trackSelectionReason,
loadable.trackSelectionData,
loadable.startTimeUs,
loadable.endTimeUs);
return true;
}
getNextChunk是continueLoading中的核心方法，继续看代码。
public final void getNextChunk(
long playbackPositionUs,
long loadPositionUs,
List<? extends MediaChunk> queue,
ChunkHolder out) {
if (fatalError != null) {
return;
}
StreamElement streamElement = manifest.streamElements[streamElementIndex];
if (streamElement.chunkCount == 0) {
// There aren't any chunks for us to load.
//没有分片可以加载了
out.endOfStream = !manifest.isLive;
return;
}
int chunkIndex; //获取最后一次加载片段的索引
if (queue.isEmpty()) {
chunkIndex = streamElement.getChunkIndex(loadPositionUs);
} else {
chunkIndex =
(int) (queue.get(queue.size() - 1).getNextChunkIndex() - currentManifestChunkOffset);
if (chunkIndex < 0) {
//这个片段不存在，说明加载片段不完整
// This is before the first chunk in the current manifest.
fatalError = new BehindLiveWindowException();
return;
}
}
if (chunkIndex >= streamElement.chunkCount) {
// This is beyond the last chunk in the current manifest.
//这个索引不合法，直接停止加载
out.endOfStream = !manifest.isLive;
return;
}
long bufferedDurationUs = loadPositionUs - playbackPositionUs;
long timeToLiveEdgeUs = resolveTimeToLiveEdgeUs(playbackPositionUs);
MediaChunkIterator[] chunkIterators = new MediaChunkIterator[trackSelection.length()];
for (int i = 0; i < chunkIterators.length; i ) {
int trackIndex = trackSelection.getIndexInTrackGroup(i);
chunkIterators[i] = new StreamElementIterator(streamElement, trackIndex, chunkIndex);
}
//最关键的地方，这里会根据网速，筛选出下一个分片
trackSelection.updateSelectedTrack(
playbackPositionUs, bufferedDurationUs, timeToLiveEdgeUs, queue, chunkIterators);
long chunkStartTimeUs = streamElement.getStartTimeUs(chunkIndex);
long chunkEndTimeUs = chunkStartTimeUs streamElement.getChunkDurationUs(chunkIndex);
long chunkSeekTimeUs = queue.isEmpty() ? loadPositionUs : C.TIME_UNSET;
int currentAbsoluteChunkIndex = chunkIndex currentManifestChunkOffset;
//这里是重点，获取选下一个需要加载的分片
int trackSelectionIndex = trackSelection.getSelectedIndex();
//获取分片解封装器
ChunkExtractor chunkExtractor = chunkExtractors[trackSelectionIndex];
int manifestTrackIndex = trackSelection.getIndexInTrackGroup(trackSelectionIndex);
Uri uri = streamElement.buildRequestUri(manifestTrackIndex, chunkIndex);
//绑定要加载的片段信息
out.chunk =
newMediaChunk(
trackSelection.getSelectedFormat(),
dataSource,
uri,
currentAbsoluteChunkIndex,
chunkStartTimeUs,
chunkEndTimeUs,
chunkSeekTimeUs,
trackSelection.getSelectionReason(),
trackSelection.getSelectionData(),
chunkExtractor);
}
3.2.4 网速检测和AdaptiveTrackSelection分片选择
网速检测使用的默认的DefaultBandWidthMeter进行测试，具体原理是监控数据的某一段时间的下载流量，计算出平均网速。AdaptiveTrack Selection#updateSelectedTrack中会利用选择测量数据，重新计算使用哪个队列的数据。
int newSelectedIndex = determineIdealSelectedIndex(nowMs, chunkDurationUs);
核心逻辑就是通过bitrate去做比较
@Override
public void updateSelectedTrack(
long playbackPositionUs,
long bufferedDurationUs,
long availableDurationUs,
List<? extends MediaChunk> queue,
MediaChunkIterator[] mediaChunkIterators) {
long nowMs = clock.elapsedRealtime();
long chunkDurationUs = getNextChunkDurationUs(mediaChunkIterators, queue);
// Make initial selection
if (reason == C.SELECTION_REASON_UNKNOWN) {
reason = C.SELECTION_REASON_INITIAL;
//初始化或者还没有选择过则直接一次性选择，不走兼容流程
selectedIndex = determineIdealSelectedIndex(nowMs, chunkDurationUs);
return;
}
int previousSelectedIndex = selectedIndex;
@C.SelectionReason int previousReason = reason;
int formatIndexOfPreviousChunk =
queue.isEmpty() ? C.INDEX_UNSET : indexOf(Iterables.getLast(queue).trackFormat);
if (formatIndexOfPreviousChunk != C.INDEX_UNSET) {
previousSelectedIndex = formatIndexOfPreviousChunk;
previousReason = Iterables.getLast(queue).trackSelectionReason;
}
//选择匹配bitrate的format
int newSelectedIndex = determineIdealSelectedIndex(nowMs, chunkDurationUs);
//判断如果该format所在的Track不在黑名单中，则走兼容逻辑
if (!isBlacklisted(previousSelectedIndex, nowMs)) {
// Revert back to the previous selection if conditions are not suitable for switching.
Format currentFormat = getFormat(previousSelectedIndex);
Format selectedFormat = getFormat(newSelectedIndex);
//注意：进入这个地方就是一个坑点，如果切码流失败，原因是这里通过一些条件又给重置回去了
long minDurationForQualityIncreaseUs =
minDurationForQualityIncreaseUs(availableDurationUs, chunkDurationUs);
if (selectedFormat.bitrate > currentFormat.bitrate
&& bufferedDurationUs < minDurationForQualityIncreaseUs) {
// The selected track is a higher quality, but we have insufficient buffer to safely switch
// up. Defer switching up for now.
//如果选择的码流大于当前的，但是buffering的数据不够去安全的切换，因此还是选择当前Track
newSelectedIndex = previousSelectedIndex;
} else if (selectedFormat.bitrate < currentFormat.bitrate
&& bufferedDurationUs >= maxDurationForQualityDecreaseUs) {
// The selected track is a lower quality, but we have sufficient buffer to defer switching
// down for now.
//选择的码流小于当前的，但是buffer数据是足够，不至于去切换
newSelectedIndex = previousSelectedIndex;
}
}
// If we adapted, update the trigger.
//触发选择条件
reason =
newSelectedIndex == previousSelectedIndex ? previousReason : C.SELECTION_REASON_ADAPTIVE;
selectedIndex = newSelectedIndex;
}
上面提到2个坑点，bufferedDurationUs 大小影响切换，因此在项目中有必要规避此问题。
核心点determineIdealSelectedIndex，这里的逻辑就是获取当前带宽，然后匹配Selection中的采样队列
private int determineIdealSelectedIndex(long nowMs, long chunkDurationUs) {
//获取带宽数据
long effectiveBitrate = getAllocatedBandwidth(chunkDurationUs);
int lowestBitrateAllowedIndex = 0;
for (int i = 0; i < length; i ) {
if (nowMs == Long.MIN_VALUE || !isBlacklisted(i, nowMs)) {
Format format = getFormat(i);
//获取小于当前网速的Format
if (canSelectFormat(format, format.bitrate, effectiveBitrate)) {
return i;
} else {
lowestBitrateAllowedIndex = i;
}
}
}
return lowestBitrateAllowedIndex;
}
带宽数据获取
private long getTotalAllocatableBandwidth(long chunkDurationUs) {
//注意这里将带宽x0.7f，实际上比实际值偏小了，因此设置网速时一定要除以0.7f
long cautiousBandwidthEstimate =
(long) (bandwidthMeter.getBitrateEstimate() * bandwidthFraction);
long timeToFirstByteEstimateUs = bandwidthMeter.getTimeToFirstByteEstimateUs();
if (timeToFirstByteEstimateUs == C.TIME_UNSET || chunkDurationUs == C.TIME_UNSET) {
//默认情况下回到这里，带宽除以当前播放的速度 （倍速）
return (long) (cautiousBandwidthEstimate / playbackSpeed);
}
float availableTimeToLoadUs =
max(chunkDurationUs / playbackSpeed - timeToFirstByteEstimateUs, 0);
return (long) (cautiousBandwidthEstimate * availableTimeToLoadUs / chunkDurationUs);
}
3.2.5 解码器的复用和重启
由于每种采样队列的分片Format有一些差别，可能需要解码器检测到格式变化。这个时候解码器可能需要重启，当然重启是多路流切换的最基本的做法，但是这种往往会出现卡顿或者短暂的黑屏，体验反而比较差。ExoPlayer对于无论是MergingMediaSource方式的多路流切换还是自适应流的切换导致onInputFormatChanged被调用做了相当多的优化，从而实现解码器的重复利用。
核心逻辑如下：
protected DecoderReuseEvaluation onInputFormatChanged(FormatHolder formatHolder)
throws ExoPlaybackException {
waitingForFirstSampleInFormat = true;
Format newFormat = checkNotNull(formatHolder.format);
if (newFormat.sampleMimeType == null) {
// If the new format is invalid, it is either a media bug or it is not intended to be played.
// See also https://github.com/google/ExoPlayer/issues/8283.
throw createRendererException(
new IllegalArgumentException(),
newFormat,
PlaybackException.ERROR_CODE_DECODING_FORMAT_UNSUPPORTED);
}
setSourceDrmSession(formatHolder.drmSession);
inputFormat = newFormat;
if (bypassEnabled) {
//等到队列数据被清空后初始化
bypassDrainAndReinitialize = true;
return null; // Need to drain batch buffer first.
}
//如果Codec已经被释放或者还没有创建的情况下，重新初始化
if (codec == null) {
availableCodecInfos = null;
maybeInitCodecOrBypass();
return null;
}
// We have an existing codec that we may need to reconfigure, re-initialize, or release to
// switch to bypass. If the existing codec instance is kept then its operating rate and DRM
// session may need to be updated.
// Copy the current codec and codecInfo to local variables so they remain accessible if the
// member variables are updated during the logic below.
MediaCodecAdapter codec = this.codec;
MediaCodecInfo codecInfo = this.codecInfo;
Format oldFormat = codecInputFormat;
if (drmNeedsCodecReinitialization(codecInfo, newFormat, codecDrmSession, sourceDrmSession)) {
drainAndReinitializeCodec();
return new DecoderReuseEvaluation(
codecInfo.name,
oldFormat,
newFormat,
REUSE_RESULT_NO,
DISCARD_REASON_DRM_SESSION_CHANGED);
}
boolean drainAndUpdateCodecDrmSession = sourceDrmSession != codecDrmSession;
Assertions.checkState(!drainAndUpdateCodecDrmSession || Util.SDK_INT >= 23);
//对比新旧解码器的重用的条件，这里代码太多，不在深入讨论。
DecoderReuseEvaluation evaluation = canReuseCodec(codecInfo, oldFormat, newFormat);
@DecoderDiscardReasons int overridingDiscardReasons = 0;
switch (evaluation.result) {
case REUSE_RESULT_NO:
//不重用，直接重启
drainAndReinitializeCodec();
break;
case REUSE_RESULT_YES_WITH_FLUSH:
//可以重复使用，但需要清除队列，这种情况下需要调用MediaCodec.flush
if (!updateCodecOperatingRate(newFormat)) {
overridingDiscardReasons |= DISCARD_REASON_OPERATING_RATE_CHANGED;
} else {
codecInputFormat = newFormat;
if (drainAndUpdateCodecDrmSession) {
if (!drainAndUpdateCodecDrmSessionV23()) {
overridingDiscardReasons |= DISCARD_REASON_WORKAROUND;
}
} else if (!drainAndFlushCodec()) {
overridingDiscardReasons |= DISCARD_REASON_WORKAROUND;
}
}
break;
case REUSE_RESULT_YES_WITH_RECONFIGURATION:
//可以重用，但是需要重新注册信息，如果是视频，需要重新注册SPS、PPS信息，具体信息在
//com.google.android.exoplayer2.Format.Builder#initializationData 中，如果音频一般是资源类型
if (!updateCodecOperatingRate(newFormat)) {
overridingDiscardReasons |= DISCARD_REASON_OPERATING_RATE_CHANGED;
} else {
codecReconfigured = true;
codecReconfigurationState = RECONFIGURATION_STATE_WRITE_PENDING;
codecNeedsAdaptationWorkaroundBuffer =
codecAdaptationWorkaroundMode == ADAPTATION_WORKAROUND_MODE_ALWAYS
|| (codecAdaptationWorkaroundMode == ADAPTATION_WORKAROUND_MODE_SAME_RESOLUTION
&& newFormat.width == oldFormat.width
&& newFormat.height == oldFormat.height);
codecInputFormat = newFormat;
if (drainAndUpdateCodecDrmSession && !drainAndUpdateCodecDrmSessionV23()) {
overridingDiscardReasons |= DISCARD_REASON_WORKAROUND;
}
}
break;
case REUSE_RESULT_YES_WITHOUT_RECONFIGURATION:
//直接重用解码器，无需注册任何信息
if (!updateCodecOperatingRate(newFormat)) {
overridingDiscardReasons |= DISCARD_REASON_OPERATING_RATE_CHANGED;
} else {
codecInputFormat = newFormat;
if (drainAndUpdateCodecDrmSession && !drainAndUpdateCodecDrmSessionV23()) {
overridingDiscardReasons |= DISCARD_REASON_WORKAROUND;
}
}
break;
default:
throw new IllegalStateException(); // Never happens.
}
if (evaluation.result != REUSE_RESULT_NO
&& (this.codec != codec || codecDrainAction == DRAIN_ACTION_REINITIALIZE)) {
// Initial evaluation indicated reuse was possible, but codec re-initialization was triggered.
// The reasons are indicated by overridingDiscardReasons.
return new DecoderReuseEvaluation(
codecInfo.name, oldFormat, newFormat, REUSE_RESULT_NO, overridingDiscardReasons);
}
return evaluation;
}
3.2.6 完成切换
通过上述必要的逻辑，就能实现分片的切换，当然，每个部分代码量实在太多包括，资源加载部分也是一个核心环节，这里就不在继续分析了。
但是如何验证切换完成了，实际上是有回调的，参考下面接口实现。
com.google.android.exoplayer2.audio.AudioRendererEventListener#onAudioInputFormatChanged(com.google.android.exoplayer2.Format)
com.google.android.exoplayer2.video.VideoRendererEventListener#onVideoInputFormatChanged(com.google.android.exoplayer2.Format)
四、实验
4.1 实验目的：
实现手动切换分片
4.2 实验方法：
自动以AdaptiveTrackSelection#Factory或者自定义BandwidthMeter，这里我们选择后者，因为改动较小。
4.2.1实现QmBandwidthMeter
private long bitrateEstimate;
private long specificBitrate = C.TIME_UNSET;
@Override
public synchronized long getBitrateEstimate() {
//如果用户没有指定比特率，则使用默认的，如果指定了，则使用用户的设备
if(specificBitrate == C.RATE_UNSET_INT) {
return bitrateEstimate;
}
return specificBitrate;
}
4.2.2 设置到Builder中
//创建带宽测量类
bandwidthMeter = new QmBandwidthMeter
.Builder(getApplicationContext())
.build();
//缓冲控制类
DefaultLoadControl loadControl = new DefaultLoadControl.Builder()
.setAllocator(new DefaultAllocator(true,C.DEFAULT_BUFFER_SEGMENT_SIZE / 2))
.setBufferDurationsMs(
10_000, //低于20秒的缓冲就开始加载数据，不一定会buffer
20_000, //一次加载最多加载20秒的数据
DefaultLoadControl.DEFAULT_BUFFER_FOR_PLAYBACK_MS,
DefaultLoadControl.DEFAULT_BUFFER_FOR_PLAYBACK_AFTER_REBUFFER_MS)
.build();
ExoPlayer.Builder playerBuilder =
new ExoPlayer.Builder(/* context= */ this)
.setLoadControl(loadControl)
.setBandwidthMeter(bandwidthMeter)
.setMediaSourceFactory(createMediaSourceFactory());
setRenderersFactory(
playerBuilder, intent.getBooleanExtra(IntentUtil.PREFER_EXTENSION_DECODERS_EXTRA, false));
player = playerBuilder.build();
注意：这里设置缓冲控制类的前文已经说过， 分片选择存在坑点，由于bufferedDurationUs值过大，可能造成降码流失效， AdaptiveTrackSelection可能会重置会原来的selectionIndex为上一个分片Track，导致降码流失败，有必要做以下兼容。
4.2.3 以切换为下面的Hls分片为例子，实现从1920x1080 -> 640x360的切换
链接地址：https://devstreaming-cdn.apple.com/videos/streaming/examples/bipbop_4x3/bipbop_4x3_variant.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=1924009,CODECS="mp4a.40.2, avc1.4d401f",RESOLUTION=1920x1080,AUDIO="bipbop_audio",SUBTITLES="subs"gear5/prog_index.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=577610,CODECS="mp4a.40.2, avc1.4d401e",RESOLUTION=640x360,AUDIO="bipbop_audio",SUBTITLES="subs"gear2/prog_index.m3u8
在起播后5s后设置带宽
【1】起播时设置带宽1924009/0.7f
【2】起播10s后设置带宽577610/0.7f
//起播时
bandwidthMeter.setSpecificBitrate((long) Math.ceil(1924009/0.7f));
//播放一段时间后
bandwidthMeter.setSpecificBitrate((long) Math.ceil(577610/0.7f));
注意: 这里除以0.7f上面也说了，是因为带宽冗余机制造成的。
验证方法，实现下面的回调
com.google.android.exoplayer2.audio.AudioRendererEventListener#onAudioInputFormatChanged(com.google.android.exoplayer2.Format)
com.google.android.exoplayer2.video.VideoRendererEventListener#onVideoInputFormatChanged(com.google.android.exoplayer2.Format)
4.3 实验结果
符合预期，成功实现了降码流
五、总结
ExoPlayer不仅支持多路流合并方式切换，也支持自适应流切换，具备高度可定制化的能力，因此，对于体验要求较高的场景，可完全通过修改自适应流相关接口实现更加顺滑的多路流切换。
ExoPlayer自适应流切换如果要改造的为用户所能选择的方式，需要修改BandwidthMeter和AdaptiveTrackSelection的一些参数。还有就是分片长度、分片IDR帧对齐、编码格式一致（尽可能解码器复用）是需要考虑的因素，另外分片可能切换等待时间较长，也是需要注意的问题。
作者:winterstian
来源:微信公众号:腾讯音乐技术团队
出处:https://mp.weixin.qq.com/s/624xdCpZmioFZlfAhwvxxg
