近期，百家云 BRTC 实时音视频平台推出了针对华为 HarmonyOS NEXT 系统的原生 RTC SDK，进一步扩大和丰富了 BRTC 产品的产品矩阵，为广大需要 RTC 能力的个人、企业提供了更加丰富的选择，注入新的活力。

注：本文代码基于WebRTC 4472（对应Chromium 91），不保证适用于所有WebRTC版本。在Chrome的 webrtc-internals 里可以看到很多关于媒体流的度量指标。目前Chrome（我用的版本是94）保留了传统（legacy）和WebRTC标准（standard）两种体系的度量数据。其中legacy的数据已经不再更新，也许未来某个时间就会从Chrome中消失了。无论le

我们在WebRTC开发中，如果采用的是H.264来作为视频流编码类型，就会面临一个问题，那就是编码端和解码端需要进行协商各自的编解码能力。例如，如果编码端使用了高级别的profile和level，或使用了解码器不支持的编码特性，那么对解码端来说就是个灾难了。大家知道，H.264的Profile以及Level有好多种，而并不是每一种编码器或者解码器都支持每一个Profile和Level。实际应用当.

最近由于工作需要，需要使用ffmpeg，以前没有接触过，初学自然少不了先翻翻雷霄骅的原创文章，向雷霄骅致敬 & 怀念~雷霄骅的两篇文章中的代码，在ffmpeg3.3.x上有几个API已经被标记为deprecated了，所以直接下载例子代码，换成ffmpeg3.3.x的库会编译不过，当然，大多数根据header文件中的说明换一下即可。不过有几个变化稍微大一点的地方，还是需要先看看介绍再动手。这里

众所周知，Adobe Flash按照Google Chrome的计划（https://www.chromium.org/flash-roadmap），在已经release的Chrome 76开始默认禁用，在2020年12月将在Chrome 87中彻底移除。到那时，如果用户使用了最新版本的Chromium内核的浏览器，意味着将无法播放各种来自CDN推送的媒体流（rtmp、flv等）。当然也不排除人们

最近遇到一个比较有意思的问题，这里记录一下，免得日后忘记细节。事情的起因是因为我们的技术团队做了一个合流的功能，就是把来自各种设备的多个视频流进行解码、按照一定布局（可以简单理解为画中画）重新构造新的视频帧数据再编码，最后转推CDN。这个合流没什么可说的，是一种常见的处理多流的手段。那么遇到了什么问题呢？来自移动端设备视频画面的方向问题。大家知道，Android设备的取景器正向一般情况下是音量..