播放器

Colibri反对所有风行的无损和有损音频格式的完满清晰的比特完满播放，并提供洁净和直观的用户体验。Colibri可能播放在无损音频方面最宽泛应用的文件格式范畴：FLAC，ALAC，WAV，AIFF，APE，TTA和WavPack - 以及这些风行的有损格局：Ogg Vorbis，MP1 / MP2 / MP3和AAC / M4A。如果须要，能够思考提供其余格局反对。 Colibri安装文件

AVAide Blu-ray Player是一款业余实用的蓝光播放器工具，能够轻轻松松播放许多 高清蓝光视频文件，并具备了优异的视频编解码作用，另外能够极致输入达到1080超清画面质量而不容易遗失。 下载：https://www.macz.com/mac/8744...

用户通过交互和产品对话，好的交互非常重要。“错误提醒”在产品交互中也是非常重要的一部分，所以某些情况下app的错误提醒不能只依赖框架的回调。如果错误提醒只依赖框架回调，在normandie中有一个设计会影响到错误提醒的交互。这个机制在底层拉取数据某些指定报错后(不是普通的重试，普通重试是没有数据返回但不报错)，且缓存中还有数据时，会去重试拉取数据，目的是防止网络非常不稳定的情况造成的播放断开。如果重试拉取数据持续报错就会将错误报告附加在缓存数据的末尾，待缓存数据消耗到末尾，错误被上报。这里的问题是，这个错误上报会有延迟，延迟的时间就是缓存数据播放的时间。在一些场景下需要app干预提早报告。比如同时开着wifi和4g，播放，然后断开wifi。这种情况下，播放当时选择的数据链路是wifi(系统里wifi优先)，虽然有4g alive但是播放仍然会断掉，但是因为框架的重试机制报错会延迟通知到用户。所以这里app要干预，监听到wifi断开，有所提示，并为用户做好在4g下重新发起播放的准备。

normandie是一套播放框架及其实现，并且90%的接口与android mediaplayer一致，包括生命周期状态机的实现等等。方便原来android框架的开发者迁移。在android上做音视频开发的同学应该比较清楚，除了mediaplayer，android还提供了其它播放音视频的类，比如视频播放的还有videoview。normandie在设计之初，就没有打算实现类似videoview这样的类。videoview的优点是接口更简单，但它的缺点也是接口太简单，这里简单的意思是不够灵活。音视频播放尤其是在线音视频播放的情况更为复杂，mediaplayer可以为开发者提供更为灵活的接口，更贴近底层框架的能力，让开发者去发挥，videoview大大的限制了开发者可以利用底层框架的能力。下图是mediaplayer的状态机，设计的比较灵活https://developer.android.com…android mediaplayerhttps://developer.android.com…android videoviewhttps://developer.android.com…1.开发者可以基于normandie的mediaplayer api自己根据需要定制，videoview,baseplayerview都可以。2.有开发者这么做了，并且将这个定制提供给其它业务使用，扩大了normandie的覆盖范围。但是之后随着一些业务的发展，这个定制就出现了之前提到的类似videoview不能满足业务需求的问题。举两个例子：（1）.类似videoview的定制不容易实现预加载，因为它提供的接口不能让开发者知道更多状态信息。预加载：同时多个palyer进行加载，但只有一个在前台播放。（2）.开发者想关心，拉取的内容的一些信息，比如分辨率等，类似videoview定制没有接口可以做。有时候少即是多。

整个短视频的市场规模一直在增长，网络数据显示2018年已经突破100亿大关，在2019年预测将超过200亿。纵观行业，在生活资讯、美食、搞笑、游戏、美妆等领域，短视频流量巨大但竞争激烈，但是在教育、财经、军事、旅游等行业还存在较大的机会。那么在这些垂直行业里，我们如何结合短视频能力，实现业务突破？近期的云栖TechDay音视频技术专场中，阿里云视频云高级技术专家王海华现场分享了《高清极速-全面提升短视频应用体验》议题。他表示，作为短视频SDK服务提供方，视频云一直和客户同样关注如何把短视频的产品和体验做得更极致。本次分享讲从端到云再到端，探讨如何进行思考与优化，实现视频体验的全面提升。短视频的业务特征短视频可以随时随地进行拍摄、分享与浏览，所以它存在着海量的上传和播放用户在移动端消费短视频的机型和网络情况十分复杂用户对短视频体验的追求是清晰和流畅，而作为开发者，也需要考虑到流量与用户体验的平衡关于视频云全链路优化的技术实践阿里云视频云提供一站式短视频解决方案，并从整个链路上进行技术优化。在生产端，短视频SDK支持视频拍摄、导入编辑和视频上传的能力；当视频传到云端，支持媒体转码、存储、视频AI分析处理功能。在分发环节，通过全球节点、智能调度和热门视频预热资源，将视频内容更稳定极速的分发至消费端；最终在播放端，播放器SDK可以实现快速启播、播放缓存、无缝循环播放和多清晰度切换。一、视频生产端-帧率与低端机型体验优化在视频拍摄阶段，用户最关注视频的清晰度和流畅度。这其中的优化包括几个环节：1. 预览帧率的提升摄像头采集到数据直到呈现到屏幕上，采用GPU驱动渲染，保证渲染的实时性，减少延迟和丢帧的情况。同时，针对人脸特效的渲染，采集3buffer的CPU回调方案，减少buffer资源等待造成的帧率下降。2. 录制帧率的提升录制是把视频帧编码的过程。整体采用GPU直接渲染到硬编Surface的方案，同时保留了之前的buffer方案作为软编的适配，在编码的延迟和丢帧缩短到最小。3. 针对低端机型 定义最优适配移动终端机型复杂度极高，硬件能力、性能、屏幕分辨率等等指标千差万别，如果想要最大限度保证低端机上的视频质量，就要在提升清晰度和流畅度的时候，降低分辨率。那么问题又来了，在什么机型上降低？怎么降低？到底降低多少合适？阿里云短视频SDK又多往前走了一步，多做了一点点。经过大量的数据分析和适配测试完成了在不同性能手机的适配。要提升整个视频的清晰度视频编码是永远绕不开的一个话题，在阿里云除了在编码器算法的优化以外，也从更加贴近业务场景的角度进一步优化。在如此多的业务场景，一种编码技术和编码参数是解决不了所有问题，所以针对不同场景，需要完成相应的编码优化。比如以质量优先的场景，会适当牺牲转码速度或者压缩率，以保证清晰度最佳；以转码速度优先的场景，会调整质量，以适实现更高的转码速度。这样更有针对性的编码调优，就可以根据需求实现场景化的平衡。除此之外，还从更加上层的用户体验上做了很多细节的优化。王海华表示：“从相册选择资源进入编辑界面，从点击合成按钮进入发布界面，从点击发布界面回到APP的主界面等这些环节的交互流畅度也直接影响用户体验。这其中的优化点：首先是当从相册选择多个图片或者视频合成视频时，我们底层支持图片视频混编的能力从而缩短loading时间，减少等待时间；其次支持后台合成和后台上传，点击合成按钮和发布按钮的时候我们直接进入后台进行合成和上传，让APP可以更快的进入到下一个界面，从而提升用户体验。”“在视频生产端经过了以上的优化后，看起来我们可以根据对应的场景拿到自己需要的视频，所有的问题都解决了。但是面临着海量上传和播放，以及复杂的网络，我们怎么保证上传速率和上传功率？在播放环节上又怎样去保证播放流畅度？作为开发者（我们的客户）又怎么控制带宽成本呢？”接下来，王海华带我们了解了在上传、云端处理和分发以及播放几个环节中的优化点以及带来的效果。二、视频上传链路优化在视频上传链路，需要核心关注速度和上传成功率两个指标。视频云支持动态加速，选择最优路径来就近上传数据，保证极速上传。同时，采用分片、断点续传技术，针对不同地域和场景决定分片大小，确保上传成功率在99.2%以上。三、云端处理&分发当视频上传到云端，就需要对其进行转码等处理，并进行内容分发。这其中我们针对三个指标进行关注和优化：1. 视频发布速度不同的场景，需要的视频发布速度是不同的。对于聊天场景下的视频发布，直接在端上进行转码，把原视频直接访问，最大限度提升速度。对于对实时性要求并没有那么高的视频社交APP等场景往往在上传的时候会上传一个码率相对较高的高清视频，为了视频快速启播，我们推荐可以先运用低复杂度转码来加快转码速度；在未来，也会将视频端上合成、上传和云端转码并行处理，大幅度缩短处理时间。2. 转码成本 vs. 带宽成本在很多社区里面当一个视频变成热门视频的时候，这时候带宽会带来更大的成本，这个时候建议对热门视频重新转码，提升转码复杂度，将视频文件变小，降低带宽成本。3. 提升播放体验因为用户的终端和网络情况不同，所以需要进行多清晰度转码，并采用推荐视频预热方案，提升启播速度和流畅度四、视频播放优化播放端直接影响着用户体验，这里我们需要关注几个指标：打开速度的快慢影响着用户对产品的第一印象，启播环节用到协议优化、解码渲染优化、视频列表预加载等方案，实现极速启播。短视频通常比较短小，通常会采用循环播放的方式来吸引用户重复观看，避免流失。那无缝地循环播放、同时边播放边缓存就十分必要，可以节省流量。终端网络情况复杂，但播放流畅度依然是用户十分在意的指标。当用户出现网络环境的变更，需要快速切换多种清晰度的视频，保证视频播放的流畅。如何进行产品快速落地一、客户端短视频SDK将最新最流行的功能、交互集成到产品级Demo中，并开放了源码，开发者拿到以后可以直接集成到应用中，或者基于源代码进行业务的适配，快速开发出一款短视频APP。Demo提供了拍摄、编辑、播放等模块，同时提供相册管理、音乐、动图、字体等资源的下载和管理，也提供了异步上传发布功能、AppServer业务服务器的SampleCode。二、服务端在云端，短视频SDK与视频点播服务打通，提供了丰富的媒体管理和媒体处理能力，开发者通过简单的配合和API调用就可以将以下功能集成到业务当中。媒资存储：音频，视频，图片，字幕等丰富的存储能力；媒资管理：提供了分类，打标，搜索，审核能能力等；数据统计：存储，流量/带宽，播放量等数据统计；感兴趣的用户，可以扫描上方二维码体验demo，点击访问阿里云官网短视频解决方案页面，了解详情，或者点击浏览趣视频解决方案文档，更快上手本文作者：樰篱阅读原文本文为云栖社区原创内容，未经允许不得转载。

欢迎大家前往腾讯云+社区，获取更多腾讯海量技术实践干货哦~本文由QQ音乐技术团队发表于云+社区专栏一、问题背景与分析不久前，团队发现其Android平台App在播放MV视频《凤凰花开的路口》时，会带有如电流声一般的杂音，这影响了用户体验。 研发同学在初步定位时，发现有如下特征：Android平台杂音问题必现；iOS、PC平台能正常播放，没有噪音。然而，各平台都是统一用HLS格式播放，即源头都是一样的。对于该问题，我们的定位思路如下：梳理视频播放流程；找到切入点排查。二、播放流程概览分析播放流程如上图（图中内容从左往右），概括其关键步骤如下：播放器初始化：创建读数据线程：read_thread；创建存放audio解码前数据的队列：audioq；创建存放audio解码后数据的队列：sampq。数据读取：①创建context；②探测协议类型：avformat_open_input；③探测媒体类型：avformat_find_stream_info；④获取音视频流：av_find_best_stream；⑤打开媒体解码器：stream_component_open；⑥读取媒体数据，获得AVPacket：av_read_frame(ic, pkt)；⑦音视频数据分别送入audioq中；重复⑥、⑦步骤到数据完毕。音频解码：在audio_thread中对audioq中的数据进行decoder_decode_frame解码；解码后的帧AVFrame存放到sampq中；音频播放：aout_thread_n中，通过调用回调接口sdl_audio_callback，对sampq中的音频帧数据进行解码成PCM数据；写入PCM数据到buffer数组，并由AudioTrack播放。三、问题分解与切入在梳理出播放流程后，标记出找到有可能出错的环节，方便进行“分层定位”（图中黄色标记）播放下载文件是否有问题；数据读取是否有问题；音频解码逻辑是否有问题；AudioTrack的设置是否有问题；接下来，根据难易程度，对上述环节逐个验证。1、播放下载文件是否正常把Android平台播放的ts文件与各平台的进行比对，发现两者一样，该环节正常。2、AudioTrack设置是否正常通过日志检查AudioTrack以下配置参数：采样率位深频道以上参数设置的值与音频流的相符合，该环节正常。3、音频解码逻辑是否有问题验证解码逻辑是否有问题，可以通过对PCM数据进行分析来确认。 对aout_thread_n进行修改，将PCM数据额外输出到本地，并与正常的PCM数据进行对比。正常PCM数据频谱图：异常PCM数据频谱图：正常PCM数据波形图：异常PCM数据波形图：对比分析可得出：从频谱图中看出，异常的PCM在人耳十分敏感的频响（1000～8000Hz ）区域内的音频数据严重缺失，导致“杂音问题”从波形图中看出，异常的与正常的无声区和有声区都吻合，若解封装、解码逻辑出现异常，极大几率是呈现无波动（一条直线的形式）情况。因此可以先大胆假设解码、解封装逻辑是符合预期的若解码逻辑正常，再结合之前已经验证文件下载正常。可以推测是数据读取环节出现异常。4、数据读取是否有问题通过对数据读取的各步骤增加日志后，发现在av_find_best_stream音频流选择时出现异常： ffmpeg -i 发现，该视频ts分片有2个音频流 通过强制分别读取两条音频流数据播放，发现：第一条正常播放（PCM数据正常）第二条播放杂音（PCM数据异常）Android平台选择了第二条进行播放基于此，也就验证了在第3步中的假设是正确的。由上分析，可以得出结论：Android平台选择了第二条数据有问题的流进行播放。四、问题根源：音频流选择1、选择方式分析代码，大致如下所列，av_find_best_stream函数选择音频流，该函数会根据2个主要参数进行选择：各音频流的在探测媒体类型（avformat_find_stream_info）时，额外解码出来的帧数（选择多的）各音频流的比特率（选择高的）int av_find_best_stream(AVFormatContext *ic, enum AVMediaType type, int wanted_stream_nb, int related_stream, AVCodec **decoder_ret, int flags){ for (i = 0; i < nb_streams; i++) { count = st->codec_info_nb_frames; //音频流探测中解码的帧数 bitrate = avctx->bit_rate;//音频流的比特率 multiframe = FFMIN(5, count); //先比较解码帧数，再比较音频流比特率，谁大谁选 if ((best_multiframe > multiframe) || (best_multiframe == multiframe && best_bitrate > bitrate) || (best_multiframe == multiframe && best_bitrate == bitrate && best_count >= count)) continue; best_count = count; best_bitrate = bitrate; best_multiframe = multiframe; ret = real_stream_index;//最后选择的流index best_decoder = decoder; } return ret;}在该视频中，我们可以看到： codec_info_nb_framesbit_rateaudio_stream 138122625audio_stream 239126375第二条流的解码帧数和比特率要比第一条高，因此选择了第二条流播放2、对比同类方案分析了以上选择规则后，我们对各平台、框架进行了选择规则的对比：备注：ExoPlayer对多音频流的ts分片支持不完善（issue），因此测试时需要调整相关接口。但选择规则依然以上述所示（DefaultTrackSelector）iOS和PC平台采用闭源组件，因此测试时使用了“互换两条音频流顺序”的方法进行测试。互换后，两平台都播放了杂音音频流 ffmpeg -i INPUT_FILE -map 0:0 -map 0:2 -map 0:1 -c copy -y OUTPUT_FILEQuickTime同样是闭源，互换音频流后无法明显差别，通过合成第三条音频流，来验证是它是对所有音频流全播放 ffmpeg -i INPUT_FILE_1 -i INPUT_FILE_2 -map 0:0 -map 0:1 -map 0:2 -map 1:0 -c copy OUTPUT_FILE3、总结从以上数据看到，iOS和PC平台会默认选择第一条流，而在Android平台的FFmpeg和ExoPlayer会根据音频流属性来选择数值更好的一条。“默认选择第一条”方案能更容易地把音源问题暴露。“比较音频流属性”方案能更大几率地选择质量更好的流来提升用户体验。但以上2个选择方案都无法识别“内容异常”的音频流。五、问题解决方案因此，处理该问题，需要从音源上进行修复和规避，我们的建议是从源头杜绝，从终端规避：编辑重新上架正常音源；短期内增加双音频流的检测上报，帮助后台、编辑进行复查；长远看由后台开发工具，分别对存量视频进行双音频流检测和对增量视频保证只转码单音频流；参考资料https://ffmpeg.org/doxygen/2.8/https://github.com/google/Exo…https://www.jianshu.com/p/daf...https://www.jianshu.com/p/a6a...http://km.oa.com/articles/sho...https://codeday.me/bug/201707…相关阅读wamp2.0配置Zend Optimizer藏匿在邮件里的“坏小子”打造一个个人阅读追踪系统 【每日课程推荐】机器学习实战！快速入门在线广告业务及CTR相应知识 ...