1.从 ExoPlayer 源码分析视频无法播放问题
2.Android Media3 （一）— 简单播放视频
3.ijkPlayer SDK 源码导入到Android Studio中各种问题解决 第二篇
4.头条都在用的边下边播功能
5.集成响度均衡遇到播放卡顿问题研究

从 ExoPlayer 源码分析视频无法播放问题

       面对项目中出现的视频无法播放问题，我们在ExoPlayer三方库中发现了Decoder init failed的常见错误，即（ERROR_CODE_DECODER_INIT_FAILED）。在Google搜索未果后，我们决定深入源码以寻找问题根源。最终，opencv orb源码通过源码分析，我们找到了问题所在并找到了解决方案，希望能为遇到类似问题的读者提供帮助。

       对比应用，我们发现使用ExoPlayer播放动态壁纸在多个机型上均能正常工作，这有助于排除机型因素。随后，我们引入ExoPlayer库并创建了一个简单的Demo，测试对比后发现，虽然在特定机型上可以播放网络视频链接，但无法播放我们的视频链接。这提示我们可能是在视频格式上存在问题。

       在源码分析中，我们发现MediaCodecVideoRenderer抛出的ExoPlaybackException是问题的关键。从调用栈关系可以看出，jdk 源码目录问题最终归咎于MediaCodecRenderer的maybeInitCodecWithFallback()方法。深入源码分析后，我们发现initCodec()方法调用时出现了异常，进一步导致了DecoderInitializationException。异常信息与日志显示一致，我们继续追踪initCodec()的逻辑。

       通过断点调试，我们发现逻辑最终到达了DefaultMediaCodecAdapterFactory的createAdapter()方法，进一步跟进到SynchronousMediaCodecAdapter.Factory中的createAdapter()方法，最终调用了MediaCodec的configure()方法，导致异常。从源码中可以看出，无论逻辑是否执行到特定的if条件，最终都会调用到MediaCodec方法，因此无需关注if逻辑。

       我们意识到最终调用的是C/C++代码，通常在Android端遇到此类异常时似乎无能为力。然而，我们从另一个角度思考问题，即在能够播放视频的黄线源码机型和无法播放的机型之间是否存在参数差异。通过逐步回溯排查MediaCodecInfo对象的值，我们最终发现了关键逻辑代码。

       分析后，我们得知首先通过getAvailableCodecInfos()方法获取一组可用解码器列表，然后通过逻辑判断将列表中的所有解码器或第一个添加到队列availableCodecInfos中。接下来，通过while循环不断从availableCodecInfos队列中取出第一个解码器进行初始化尝试，直到找到成功初始化的解码器为止。

       从代码注释中，我们了解到enableDecoderFallback参数的含义，设置为true可能导致性能降低（软解性能不如硬解），但默认情况下优先初始化硬解。通过设置setEnableDecoderFallback(true)，问题得以解决，从而实现了视频的正常播放。

Android Media3 （一）— 简单播放视频

       在Android应用开发中，有时需要集成视频播放功能，JetPack Media3作为官方推荐的视频播放解决方案，以ExoPlayer为核心，极大地简化了开发者的-61的源码工作。本文将引导你快速入门Media3，实现视频播放。

       首先，要在项目中引入Media3库。在app模块的build.gradle文件中，添加以下依赖代码：

       // ...其他依赖

       implementation 'com.google.android.exoplayer:exoplayer:2..1' // 请根据最新版本替换

       implementation 'com.google.android.exoplayer:exoplayer-ui:2..1' // 用于PlayerView

       在布局文件中，引入PlayerView，它是视频播放的核心容器：

       <com.google.android.exoplayer2.ui.PlayerView

       android:id="@+id/player_view"

       android:layout_width="match_parent"

       android:layout_height="match_parent"

       android:layout_margin="dp"

       android:background="@android:color/black"

       />

       你可以根据需要调整PlayerView的一些参数，比如封面、控制器样式等。具体配置可以参考官方文档。

       接下来，创建一个ExoPlayer实例，并将其关联到PlayerView上，加载你想要播放的视频资源：

       Player player = ExoPlayerFactory.newSimpleInstance(new DefaultRenderersFactory(context));

       PlayerView playerView = findViewById(R.id.player_view);

       playerView.setPlayer(player);

       // 设置播放资源，例如通过MediaSource

       MediaSource mediaSource = ...;

       player.prepare(mediaSource);

       player.setPlayWhenReady(true);

       运行程序，你将看到视频播放效果。为了更直观的学习，示例代码已在名为ExampleDemo的项目中提供。你可以从GitHub或Gitee上获取源码：

       - 示例Demo GitHub: [链接]

       - 示例Demo Gitee: [链接]

       通过以上步骤，心源码意你已经掌握了使用Media3库进行视频播放的基础。后续可以探索更多高级功能，如视频缓存、播放控制等。祝你在视频播放开发中顺利！

ijkPlayer SDK 源码导入到Android Studio中各种问题解决 第二篇

       在将ijkPlayer SDK导入Android Studio并进行编译过程中，我遇到了多个问题。这些问题在前篇博客《ijkPlayer SDK 源码导入Android Studio中各种问题解决 第一篇》中已经部分探讨过，zinyan.com。

       问题与解决

       问题一：Flavors错误

       在代码无误的情况下，运行时出现Flavors错误。原因在于ijkplayer项目的build.gradle版本过低，需添加一个维度名称到flavorDimensions。只需定义任意维度名即可解决问题。

       问题二：exoplayer库缺失

       找不到com.google.android.exoplayer:exoplayer:r1.5.，可能由于网络问题或仓库不稳定。在ijkplayer-exo模块的build.gradle中，将依赖库切换至国内镜像如阿里云，添加相应配置后重新build即可。

       问题三：UnsatisfiedLinkError

       编译后的apk在运行视频时崩溃，原因是找不到本地的libijkffmpeg.so。检查发现项目中未包含so文件，需将本地依赖改为远程依赖或自行编译导入。

       问题四：NDK版本不匹配

       依赖的NDK版本与要求版本不一致，只需在Android Studio的SDK管理面板中下载.0.版本的NDK并安装，下载速度受网络影响。

       成功解决了这些问题后，ijkplayer-example项目可以运行，但so库仍需进一步处理。后续将有更多关于so库编译的内容，敬请关注。

头条都在用的边下边播功能

       边下边播功能是当前视频播放器中的一项关键特性，它旨在提高播放效率和节省网络流量。其核心原理是当用户观看网络视频时，播放器会下载视频数据到本地，这样在下一次播放时可以直接利用本地文件，无需再次从网络获取，从而减少重复请求，提升播放速度和稳定性。

       定制优化是边下边播的一大优势，普通开发者可能不熟悉播放器底层的复杂网络请求流程。例如，使用Exoplayer时，网络请求通常在DataSource模块，这对于进行网络层优化非常不便。通过本地代理，开发者可以将网络请求模块从播放器中分离出来，独立进行优化，如复用链接、DNS优化等，无需修改播放器源码。

       边下边播还有助于节省流量和播放速度。视频数据被请求并存储后，再次播放时，只需读取本地文件，避免了重复请求流量。此外，通过预加载优化，可以减少MediaCodec资源的占用，防止因过多实例导致的内存问题和播放异常。

       然而，边下边播也存在一些挑战。例如，MP4格式的视频结构问题可能导致边下边播无法处理某些特殊格式。此外，处理拖动播放进度时，需要有效管理缓存，确保在用户操作下能无缝衔接。M3U8视频由于其特殊的分片结构，需要对索引文件进行改造才能实现边下边播。

       最后，关于网络请求的位置，虽然播放器通常扮演客户端角色，但在边下边播中，请求实际可能在客户端或本地代理服务器进行，这取决于如何设计架构来分离网络请求和播放逻辑。使用JeffVideoCache时，开发者可以根据需求灵活配置，同时欢迎提出反馈以优化这一功能。

集成响度均衡遇到播放卡顿问题研究

       集成响度均衡后，虽然整体效果显著，但在灰度测试阶段遇到了播放卡顿的问题，尤其是在低配置设备上。用户反馈切换音量大差异的节目时，播放会出现间歇性卡顿，尤其是在倍速播放时更为明显。问题核心在于AudioProcessor处理音频数据的速度超过了设备能实时播放的速率，特别是在处理时间限制下，如0.s或0.s的音频块。

       为解决这个问题，尝试了以下策略：

       提前处理音频数据，但ExoPlayer的源码表明MediaCodec解码后数据直接输入AudioSink，无法缓冲。

       在解码前处理数据，考虑重编码，但会增加处理时间，且涉及重编码、缓存管理和切换响度均衡的数据处理，复杂且不优先考虑。

       移除java层的1s缓冲，以为能解决卡顿，但实际并未解决问题，因为卡顿与AudioTrack的缓冲大小有关。

       进一步的分析揭示了卡顿的根源在于AudioProcessor处理数据的耗时超过了AudioTrack的实际缓冲限制，这导致了播放时的阻塞。为防止卡顿，关键在于：

       在java层设置足够的缓冲，例如1s，以适应不同设备的处理速度差异。

       调整AudioTrack的缓冲大小，提高数据处理的上限，如将其设置为1s，以降低卡顿概率。

       因此，解决播放卡顿的关键在于优化数据处理流程和缓冲策略，以适应设备性能和音频处理需求。