通过fbo处理视频数据,通过samplerExternalOES纹理来创建SurfaceTexture,这样的话摄像头数据就和fbo相关联，具体可以看OpenGLES通过SurfaceTexture预览摄像头画面
音频录制 相关参考 MediaCodec硬编码pcm2aac 主要分为以下几步骤:
MediaCodec的相关数据时间单位为（纳秒/1000），类似610,729,613,772, 倒数第7位代表秒级
录音采用的是AudioRecord，通过MediaCodec进行编码，用MediaMuxer合成输出MP4文件。
最近在做类似小咖秀的视频录制功能，也就是俗称的对嘴型表演，录制视频我用的是三方SDK，但是视频合成就需要自己搞了，在网上搜了挺多资料，国内国外网站看了不少，踩了很多坑，总算整出来了，在此分享给大家，希望对以后要做类似功能的兄弟们有所帮助！
最近工作中遇到了音视频处理的需求，Android下音视频合成，在当前调研方案中主要有三大类方法：MediaMux硬解码，mp4parser，FFmepg。三种方法均可实现，但是也有不同的局限和问题，先将实现和问题记录于此，便于之后的总结学习。下面话不多说了，来一起看看详细的介绍吧。
MediaMuxer的使用比较简单，方法很少，就那么几个。但是需要注意的是我们添加音视频轨的时候，MediaMuxer.addTrack(MediaFormat)需要一个MediaFormat参数，而这个参数不是我们打开MediaCodec的时候简单构造的那个，这个MediaFormat必须是从MediaCodec.getOutputFormat()获取的，他们完全不一样。如果我们直接使用自己简单构造的MediaFormat，是无法写入音视频数据的。 说必须有点绝对了，这只是官方推荐用法而已。其实如果有必要，我们完全可以自己构造用于添加音视频轨道的MediaFormat，这个我会在第八章教大家怎么做。 我们先看一下MediaMuxer的主要方法：
一、短视频内容生产 优质短视频内容的产生依赖于短视频的采集和特效编辑，这就要求在进行短视频源码开发时，用到基础的美颜、混音、滤镜、变速、图片视频混剪、字幕等功能，在这些功能基础上，进行预处理，结合OpenGL、AI、AR技术，产生很多有趣的动态贴纸玩法，使得短视频内容更具创意。
优质短视频内容的产生依赖于短视频的采集和特效编辑，这就要求在进行抖音APP开发时，用到基础的美颜、混音、滤镜、变速、图片视频混剪、字幕等功能，在这些功能基础上，进行预处理，结合OpenGL、AI、AR技术，产生很多有趣的动态贴纸玩法，使得短视频内容更具创意。
YUV是为了解决彩色电视与黑白电视的兼容性。黑白视频只有Y值，也就是灰度。而彩色电视则有YUV3个分量，如果只读取Y值，就只能显示黑白画面了。YUV最大的优点在于只需占用极少的带宽。
这是MediaCodeC系列的第三章，主题是如何使用MediaCodeC将图片集编码为视频文件。在Android多媒体的处理上，MediaCodeC是一套非常有用的API。此次实验中，所使用的图片集正是MediaCodeC硬解码视频，并将视频帧存储为图片文件文章中，对视频解码出来的图片文件集，总共332张图片帧。 若是对MediaCodeC视频解码感兴趣的话，也可以浏览之前的文章：MediaCodeC解码视频指定帧，迅捷、精确
做转码服务的原型时，看了看MCU的实现，考虑到如果不做转码，可以将多路rtp流直接合成为一路rtmp流输出，这样就相当于实现了多人连麦，并将多人连麦的视频转发直播了，所以做了这个简单的原型实现！
随着Android 4.4及以上版本的逐渐普及，Android 4.1引入的MediaExtractor类，以及Android 4.3引入的MediaMuxer类，终于可以开始正式地“发光发热”了。 MediaMuxer类主要用于将音频和视频数据进行混合生成多媒体文件（如：mp4文件），而MediaExtractor则刚好相反，主要用于多媒体文件的音视频数据的分离。 本文将介绍如何利用Android SDK提供的MediaExtractor和MediaMuxer类来完成mp4文件的提取和生成，指出开发过程中
硬编码：使用非CPU进行编码，如显卡GPU、专用的DSP、FPGA、ASIC芯片等
x264是目前使用最广泛、效率最高的h264编码库，著名的音视频处理库ffmpeg也支持x264的扩展。如果你的项目用于商业用途，建议选用免费的openh264。 相比x264，可能著名的ffmpeg更广为人知。但是我们为什么不使用ffmpeg呢。正如本系列文章的序章所说，如果你只是打算用于h264编码，完全没必要使用庞大复杂ffmpeg，反而选择短小精悍的x264更适合你。不仅可以使用更小的so库（这在移动平台很有必要），而且也不需要再去啃ffmpeg枯燥复杂的代码。我是前前后后看了五遍才勉强看懂，一直处于看了又忘，忘了又看的状态，似会非会的叠加状态。相比之下x264的流程更为短小清晰，使用更为简单。
在本篇章的第二篇文章【音视频硬解码流程】，已经讲过，Android使用的是MediaExtractor对音视频数据流进行解封。这里，我们简单再过一遍。
adb shell命令screenrecord MediaRecorder， MediaProjection MediaProjection , MediaCodec和MediaMuxer
其实这一两年关于Android 平台的视频编解码学习资料已经很多了，包括书籍和网上的一些公开教程。书籍讲得详细一点，所以推荐大家去买些书籍看看。而网上的资料的话，大多是零星点点，新手学习起来并不是很轻松，包括我。所以这也是促使本人对这一块知识做记录的原因。 我打算开几个章节来分享一下相关的知识点，因为想详细展开，内容可能有点多，也算是做一些个人笔记。
近年来短视频的火爆，让内容创作类的APP获得了巨大的流量。用户通过这类工具编辑自己的短视频，添加各式各样的炫酷特效，从而呈现出更加丰富多彩的视频内容。本文将会介绍如何使用移动端原生API，将图片添加转场特效并且最终合成为视频的基本流程。
Android5.0之后开放了屏幕捕捉的API，因此开发者便可以直接通过代码进行截图与录屏，而无需操作系统底层了。屏幕捕捉的功能由MediaProjectionManager媒体投影管理器实现，该管理器的对象从系统服务MEDIA_PROJECTION_SERVICE中获得。注意MediaProjectionManager是Android5.0之后新增的工具，故代码中要补充判断系统版本，如果是4.*及以下版本，则不可处理屏幕捕捉操作。 具体的屏幕捕捉，还要调用媒体投影管理器对象的getMediaProjection方法，获取MediaProjection媒体投影对象。MediaProjection主要有两个方法，说明如下： createVirtualDisplay : 创建虚拟显示层。可分别指定显示层的名称、宽度、高度、密度、标志、渲染表面等等。其中标志通常取值DisplayManager.VIRTUAL_DISPLAY_FLAG_AUTO_MIRROR，渲染表面则按照截图和录屏两种方式分别取值。 stop : 停止投影。 屏幕捕捉的用途主要是截图和录屏，这有点像摄像头的功能，截图对应拍照，而录屏对应录像。对于拍照和录像，我们知道需要创建一个SurfaceView表面视图做为画面预览层，那么就屏幕捕捉而言，也需要创建一个虚拟显示对象做为投影预览层。这个投影预览层即前面createVirtualDisplay方法返回的VirtualDisplay对象，具体的表面对象则为createVirtualDisplay方法中的渲染表面参数，也就是一个Surface对象。如果当前为截图操作，那么调用ImageReader对象的getSurface方法获得渲染表面；如果当前为录屏操作，那么调用MediaCodec对象的createInputSurface方法获得渲染表面。
毕业至今，之前一直从事Android开发的工作，今年5月份开始接触音视频开发相关工作，于是打算写一个音视频相关专栏，让移动端的同学，能通过这个专栏快速掌握音视频相关知识，首先带来第一篇，主要讲讲移动端的音视频技术涉及哪些？
最近开发的新版程序初版基本差不多了，所以抽空需要研究一下针对运维方便的辅助工具，其中就有需要做一个WIndows服务器可以远程控制Android客户端的工具，实现的原理大概已经有了个思路了，拆解后每个细节就需要去做技术验证，远程控制首先就需要做到看到对面的图像，预览图像就要使用录屏的功能，所以就有了这个小Demo，当然最终要做的东西是不需要保存本地视频的，这里是为了验证一下是否成功。
我录屏的方式是分别录制音频和视频，最后合并成mp4格式，比较麻烦，因为网上完整的教程比较少，所以我打算写一个完整版的，照着我的代码写完之后，至少是能够实现功能的，而不是简单的介绍下用法。
在上一章我们讲到了MediaCodec的工作流程，以及如何利用MediaCodec进行H264编码。这一章的内容同样是MediaCodec，只不过是编码音频为AAC，整个流程大同小异。 上一章我们利用MediaCodec编码视频时，使用了Surface，所以可以不直接操作输入缓冲区队列。但是编码音频的时候，由于无法使用Surface，所以需要直接操作输入缓冲区队列。 这里我们需要通过AudioRecord采集PCM数据，然后把采集到的数据送进编码器进行编码。所以首先我们要初始化一个AudioRecord对象。 要使用录音，需要申请录音权限。
本文主要讲一下笔者计划在音视频方向的学习路线计划，主要以Android开发为例，让我们一起进步。
MediaCodec类Android提供的用于访问低层多媒体编/解码器接口，它是Android低层多媒体架构的一部分，通常与MediaExtractor、MediaMuxer、AudioTrack结合使用，能够编解码诸如H.264、H.265、AAC、3gp等常见的音视频格式。广义而言，MediaCodec的工作原理就是处理输入数据以产生输出数据。具体来说，MediaCodec在编解码的过程中使用了一组输入/输出缓存区来同步或异步处理数据：首先，客户端向获取到的编解码器输入缓存区写入要编解码的数据并将其提交给编解码器，待编解码器处理完毕后将其转存到编码器的输出缓存区，同时收回客户端对输入缓存区的所有权；然后，客户端从获取到编解码输出缓存区读取编码好的数据进行处理，待处理完毕后编解码器收回客户端对输出缓存区的所有权。不断重复整个过程，直至编码器停止工作或者异常退出。
上一篇《Android制作带悬浮窗控制的录屏程序Demo》我自己用的虚拟机是Android8的版本，后来用自己的手机无法使用，原因是在Android 10之后录屏等功能要求在前台Service中进行，所以如果你的设备是Android 10以上的 ，上一篇中的录屏就不能用了，所以这篇是专门针对Android 10录屏做的改动。
iOS/Android 客户端开发同学如果想要开始学习音视频开发，最丝滑的方式是对音视频基础概念知识有一定了解后，再借助 iOS/Android 平台的音视频能力上手去实践音视频的采集 → 编码 → 封装 → 解封装 → 解码 → 渲染过程，并借助音视频工具来分析和理解对应的音视频数据。
继抖音、快手、微视等一众短视频豪强并起以来，2018年的短视频市场可谓一片火热，而国内很多短视频平台运营商也开始纷纷布局海外短视频市场。面对眼前的场景，短视频app开发也逐渐引发了创投者的兴趣，生怕自己错过眼下的短视频红海。
目前，市面上关于音视频学习的相关书籍并不多，而且即使看了书籍学了理论，最终还是要回归到代码上来。
MediaRecorder类是Android sdk提供的一个专门用于音视频录制，一般利用手机麦克风采集音频，摄像头采集图片信息。
说到Android的视频硬编码，很多新人首先会想到MediaRecorder，这可以说是Android早期版本视频硬编码的唯一选择。这个类的使用很简单，只需要给定一个Surface（输入）和一个File（输出），它就给你生成一个标准的mp4文件。 但越是简单的东西便意味着越难以控制，MediaRecorder的缺点很明显。相信很多人在接触到断点视频录制这个需求的时候，首先会想到使用MediaRecorder，很遗憾，这个东西并不能给你很多期待，就像一开始的我一样。 首先，MediaRecorder并没有断点录制的API，当然你可以使用一些“小技巧”，每次录制的时候，都把MediaRecorder stop掉，然后再次初始化，这样就会生成一系列的视频，最后把它们拼接起来。然而问题在于，每次初始化MediaRecorder都需要消耗很长时间，这意味着，当用户快速点击录制按钮的时候可能会出现问题。对于这个问题，你可以等到MediaRecorder初始化完成才让用户点击开始录制，但是这样往往会因为等待时间过长，导致用户体验极差。 这种情况下，一个可控的视频编码器是必须的。虽然在Android 4.4以前我们没得选择，但是在Android 4.4之后，我们有了MediaCodec，一个完全可控的视频编码器，虽然无法直接输出mp4（需要配合MediaMuxer来对音视频进行混合，最终输出mp4，或者其它封装格式）。如今的Android生态，大部分手机都已经是Android 5.0系统，完全可以使用MediaCodec来进行音视频编码的开发，而MediaRecorder则降级作为一个提高兼容性的备选方案。 废话不多说，我们直接步入正题。要想正确的使用MediaCodec，我们首先得先了解它的工作流程，关于这个，强烈大家去看一下Android文档。呃呃，相信在这个快速开发为王道的环境，没几个人会去看，所以还是在这里简单介绍一下。
大家好，本文是 iOS/Android 音视频开发专题 的第三篇，从本篇开始进入 Android 音视频专题实战篇。如果你对 iOS/Android 音视频开发感兴趣可通过关注本公众号 GeekDev 第一时间获取推送。
原文：https://engineering.linkedin.com/blog/2019/litr-a-lightweight-video-audio-transcoder-for-android
最近做一个Android开发的项目用到了录屏的功能，开始查阅了一些资料和博客，基本上都是在讨论ROOT的。直到后来在github上看到一个比较新的代码，才恍然发现，Android 5.0时候开放了一个新的接口—android.media.projection，一下子让这个问题变得简单了。所以说查阅资料也该注意实时性，现在很多技术推陈出新速度很快，一些新的包，接口，方法会让问题更好更快的解决。不过自己还是决定总结了下之前的一些想法，也算是一个学习吧。
https://engineering.linkedin.com/blog/2019/litr-a-lightweight-video-audio-transcoder-for-android
自安卓4.4开始，系统提供了内置的录屏功能，用户可以在adb下执行screenrecord命令，以指定码率、帧率、分辨率和时长来录制屏幕。但这个方案有缺点，普通用户无法直接执行adb命令，只能要么求助于adb终端，比如pc端的android-sdk，又或者在安卓设备上获取root权限，再执行录屏命令。幸而从5.1开始，系统又提供了MediaProjection API，通过再组合MediaRecorder或者MediaCodec API，开发者可以十分轻松地实现一个免root的全系统录屏工具，而ShareREC的全系统录屏功能，正是基于这种组合。
本文实例为大家分享了Android实现屏幕录制功能的具体代码，供大家参考，具体内容如下
播放一个音视频文件的时候，我们知道需要经过解协议->解封装->解码音频/视频->音频/视频同步->渲染播放这几个步骤，其中解码音频/视频是整个流程中最核心的一个环节.每个步骤的详细解释可以参考上篇文章Android中如何使用OpenGL播放视频 Android平台下解码音视频可以采用软件解码如ffmpeg，或使用硬件解码如MediaCodec来实现软件解码：利用CPU进行解码处理，这种方式会加大CPU负担并增加功耗，它的优点则是具有更强的适配性；硬件解码：调用GPU的专门解码音视频的模块来处理，减少CPU运算，降低功耗．由于Android机型碎片化比较严重，硬件解码的实现又依赖于具体的厂商，所以硬件解码的适配性并不是那么友好一般而言，在Android设备支持硬解的情况下优先使用Android设备的硬件解码，减少CPU占用，降低功耗；在硬解不支持的情况下选择使用软解码，至少让音视频能正常播放. 软硬结合，才是王道->_-> 当然，本篇文章所描述的是使用硬件解码MediaCodec的方式来解码一个视频文件. MediaCodec简介 android.media.MediaCodec是从API16开始由Android提供的供开发者能更加灵活的处理音视频的编解码组件，与MediaPlayer/MediaRecorder等high-level组件相比，MediaCodec能让开发者直接处理具体的音视频数据，所以它是low-level API它通常与MediaExtractor, MediaSync, MediaMuxer, MediaCrypto, MediaDrm, Image, Surface和AudioTrack一起使用. 基本架构
每周一期，纵览音视频技术领域的干货。 新闻投稿：contribute@livevideostack.com。 ✦ 一周简讯 ✦ MPAI-MMC将被IEEE采纳为技术标准 在 MPAI Multimodal Conversation (MPAI-MMC) 获得批准满 6 个月的当天，IEEE 主持了 P3300 工作组的启动会议，任务是采用 MPAI 技术规范作为 IEEE 标准。早些时候，MPAI 和 IEEE 签署了一项协议，MPAI 授予 IEEE 将 MPAI-MMC 作为 IEEE 标准发布的
教科书般的教程、课程中对视频文件结构的描述非常详细，此处不赘述，简单地说，视频文件也是一种文件，是文件，就是一堆二进制数的集合，而且是一个一维的二进制数的集合。因此，视频文件中的视频流、音频流，甚至可能包含的字幕流是如何存放的呢？
Android的视频相关的开发，大概一直是整个Android生态，以及Android API中，最为分裂以及兼容性问题最为突出的一部分。摄像头，以及视频编码相关的API，Google一直对这方面的控制力非常差，导致不同厂商对这两个API的实现有不少差异，而且从API的设计来看，一直以来优化也相当有限，甚至有人认为这是“Android上最难用的API之一” 以微信为例，我们录制一个540p的mp4文件，对于Android来说，大体上是遵循这么一个流程： ---- ---- 大体上就是从摄像头输出的YUV帧
📷 『音视频技术开发周刊』由LiveVideoStack团队出品，专注在音视频技术领域，纵览相关技术领域的干货和新闻投稿，每周一期。 架构 刘歧：FFmpeg Filter深度应用 本文来自OnVideo视频创作云平台联合创始人刘歧在LiveVideoStackCon的讲师热身分享，刘歧分享了FFmpeg的基本原理、使用方法及开发方法。在10月19-20日的LiveVideoStackCon 2018上，刘歧还将分享如何通过FFmpeg实现视频版权保护的方法。 快手QoE指标设计的分析初探 全链路的数据
每周一期，纵览音视频技术领域的干货。 新闻投稿：contribute@livevideostack.com。 ✦ 一周简讯 ✦ LiveKit 1.0版发布 我们使用LiveKit的目标是构建一个所有人都可以访问的端到端的开源 WebRTC 堆栈。经过 20 个月和近 1000 次提交后，LiveKit 1.0 版发布了。在这篇文章中，我们将深入探讨端到端流优化，这是 LiveKit 1.0 的一个特别令人兴奋的方面。基于 WebRTC 的会议软件通常难以应付只有少数参与者的会议。详情：https://b
1对1直播源码开发，Android获取实时屏幕画面是如何实现的呢？因为VirtualDisplay可以获取当前屏幕的视频流，创建VirtualDisplay只需通过MediaProjectionManager获取MediaProjection，然后通过MediaProjection创建VirtualDisplay即可。
本文将利用 FFmpeg+ MediaCodec 做一个播放器，实现视频的硬解码和音视频同步等功能。
1. Android O 新特性 前段时间解决了几个 QQ 音乐多窗口屏幕显示的 bug，虽然这个问题最终不是 Android O 版本的问题，多窗口是 Android 7.1 之后引入的，但是趁此机会了解一下 Android O 版本的新特性也不错。 在 Google IO 大会上介绍到的 Android O 新版本更新和优化主要集中在两个方面：Fluid Experiences 和 Vitals，Fluid Experience 主要包含了四个显著特性：Notification Dots, Pictur
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
