音视频开发技术（音视频软件开发）

本篇文章给大家谈谈音视频开发技术，以及音视频软件开发对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享音视频开发技术的知识，其中也会对音视频软件开发进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、如何快速学习音视频开发?
• 2、Flutter浪潮下的音视频研发探索
• 3、音视频开发三大就业方向
• 4、音视频技术发展
• 5、Android -- 音视频基础知识
• 6、音视频技术实务主要学什么？

如何快速学习音视频开发?

很多开发者都知道音视频开发这个概念，音视频开发不仅需要掌握图像、音频、视频音视频开发技术的基础知识，并且还需要掌握如何对它们进行采集、渲染、处理、传输等一系列音视频开发技术的开发和应用，因此，音视频开发是一门涉及到很多内容的领域。

Flutter浪潮下的音视频研发探索

文/陈炉军

整理/LiveVideoStack
大家好，我是阿里巴巴闲鱼事业部的陈炉军，本次分享的主题是Flutter浪潮下的音视频研发探索，主要内容是针对闲鱼APP在当下流行的跨平台框架Flutter的大规模实践，介绍其在音视频领域碰到的一些困难以及解决方案。
分享内容主要分为四个方面，首先会对Flutter有一个简单介绍以及选择Flutter作为跨平台框架的原因，其次会介绍Flutter中与音视频关系非常大的外接纹理概念，以及对它做出的一些优化。之后会对闲鱼在音视频实践过程中碰到的一些Flutter问题提出了一些解决方案——TPM音视频框架。最后是闲鱼Flutter多媒体开源组件的介绍。

Flutter
Flutter是一个跨平台框架，以往的做法是将音频、视频和网络这些模块都下沉到C++层或者ARM层，在其上封装成一个音视频的SDK，供UI层的PC、iOS和Android调用。

而Flutter做为一个UI层的跨平台框架，顾名思义就是在UI层也实现了一个跨平台开发。可以预想的是未Flutter发展的好的话，会逐渐变为一个从底层到UI层的一个全链路的跨平台开发，技术人员分别负责SDK和UI层的开发。
在Flutter之前已经有很多跨平台UI解决方案，那为什么选择Flutter呢？

我们主要考虑性能和跨平台的能力。

以往的跨平台方案比如Weex，ReactNative，Cordova等等因为架构的原因无法满足性能要求，尤其是在音视频这种性能要求几乎苛刻的场景。

而诸如Xamarin等，虽然性能可以和原生App一致，但是大部分逻辑还是需要分平台实现。
我们可以看一下，为什么Flutter可以实现高性能：

原生的native组件渲染以IOS为例，苹果的UIKit通过调用平台自己的绘制框架QuaztCore来实现UI的绘制，图形绘制也是调用底层的API,比如OpenGL、Metal等。

而Flutter也是和原生API逻辑一致，也是通过调用底层的绘制框架层SKIA实现UI层。这样相当于Flutter他自己实现了一套UI框架，提供了一种性能超越原生API的跨平台可能性。
但是我们说一个框架最终性能怎样，其实取决于设计者和开发者。至于现在到底是一个什么状况：

在闲鱼的实践中，我们发现在正常的开发没有特意的去优化UI代码的情况下，在一些低端机上，Flutter界面的流畅性是比Native界面要好的。

虽然现在闲鱼某些场景下会有卡顿闪退等情况，但是这是一个新事物发展过程中的必然问题，我们相信未来性能肯定不会成为限制Flutter发展的瓶颈的。
在闲鱼实践Flutter的过程中，混合栈和音视频是其中比较难解决的两个问题，混合栈是指一个APP在Flutter过程中不可能一口气将所有业务全部重写为Flutter，所以这是一个逐步迭代的过程，这期间原生native界面与Flutter界面共存的状态就称之为混合栈。闲鱼在混合栈上也有一些比较好的输出，例如FlutterBoost。

外接纹理
在讲音视频之前需要简要介绍一下外接纹理的概念，我们将它称之为是Flutter和Frame之间的桥梁。
Flutter渲染一帧屏幕数据首先要做的是，GPU发出的VC信号在Flutter的UI线程，通过AOT编译的机器码结合当前Dart Runtime，生成Layer Tree UI树，Layer Tree上每一个叶子节点都代表了当前屏幕上所需要渲染的每一个元素，包含了这些元素渲染所需要的内容。将Layer Tree抛给GPU线程，在GPU线程内调用Skia去完成整个UI的渲染过程。Layer Tree中有PictureLayer和TextureLayer两个比较重要的节点。PictureLayer主要负责屏幕图片的渲染，Flutter内部实现了一套图片解码逻辑，在IO线程将图片读取或者从网络上拉取之后，通过解码能够在IO线程上加载出纹理，交给GPU线程将图片渲染到屏幕上。但是由于音视频场景下系统API太过繁多，业务场景过于复杂。Flutter没有一套逻辑去实现跨平台的音视频组件，所以说Flutter提出了一种让第三方开发者来实现音视频组件的方式，而这些音视频组件的视频渲染出口，就是TextureLayer。

在整个Layer Tree渲染的过程中，TextureLayer的数据纹理需要由外部第三方开发者来指定，可以把视频数据和播放器数据送到TextureLayer里，由Flutter将这些数据渲染出来。
TextureLayer渲染过程：首先判断Layer是否已经初始化，如果没有就创建一个Texture，然后将Texture Attach到一个SufaceTexture上。

这个SufaceTexture是音视频的native代码可以获取到的对象，通过这个对象创建的Suface，我们可以将视频数据、摄像头数据解码放到Suface中，然后Flutter端通过监听SufaceTexture的数据更新就可以顺利把刚才创建的数据更新到它的纹理中，然后再将纹理交给SKIA渲染到屏幕上。
然而我们如果需要用Flutter实现美颜，滤镜，人脸贴图等等功能，就需要将视频数据读取出来，更新到纹理中，再将GPU纹理经过美颜滤镜处理后生成一个处理后的纹理。按Flutter提供的现有能力，必须先将纹理中的数据从GPU读出到CPU中，生成Bitmap后再写入Surface中，这样在Flutter中才能顺利的更新到视频数据，这样做对系统性能的消耗很大。
通过对Flutter渲染过程分析，我们知道Flutter底层需要渲染的数据就是GPU纹理，而我们经过美颜滤镜处理完成以后的结果也是GPU纹理，如果可以将它直接交给Flutter渲染，那就可以避免GPU-CPU-GPU这样的无用循环。这样的方法是可行的，但是需要一个条件，就是OpenGL上下文共享。

OpenGL
在说上下文之前，得提到一个和上线文息息相关的概念：线程。

Flutter引擎启动后会启动四个线程：

第一个线程是UI线程，这是Flutter自己定义的UI线程，主要负责GPU发出的VSync信号时候用当前Dart编译的机器码和当前运行环境创建出Layer Tree。

还有就是IO线程和GPU线程。和大部分OpenGL处理解决方案中一样，Flutter也采取一个线程责资源加载，一部分负责资源渲染这种思路。

两个线程之间纹理共享有两种方式。一种是EGLImage(IOS是 CVOpenGLESTextureCache)。一种是OpenGL Share Context。Flutter通过Share Context来实现纹理共享，将IO线程的Context和GPU线程的Context进行Share，放到同一个Share Group下面，这样两个线程下资源是互相可见可以共享的。

Platform线程是主线程，Flutter中有一个很奇怪的设定，GPU线程和主线程共用一个Context。并且在主线程也有很多OpenGL 操作。

这样的设计会给音视频开发带来很多问题，后面会详细说。
音视频端美颜处理完成的OpenGL纹理能够让Flutter直接使用的条件就是Flutter的上下文需要和平台音视频相关的OpenGL上下文处在一个Share Group下面。

由于Flutter主线程的Context就是GPU的Context，所以在音视频端主线程中有一些OpenGL操作的话，很有可能使Flutter整个OpenGL被破坏掉。所以需要将所有的OpenGL操作都限制在子线程中。

通过上述这两个条件的处理，我们就可以在没有增加GPU消耗的前提下实现美颜和滤镜等等功能。

TPM
在经过demo验证之后，我们将这个方案应用到闲鱼音视频组件中，但改造过程中发现了一些问题。

上图是摄像头采集数据转换为纹理的一段代码，其中有两个操作：首先是切进程，将后面的OpenGL操作都切到cameraQueue中。然后是设置一次上下文。然后这种限制条件或者说是潜规则往往在开发过程中容易被忽略的。而这个条件一旦忽略后果就是出现一些莫名其妙的诡异问题极难排查。因此我们就希望能抽象出一套框架，由框架本身实现线程的切换、上下文和模块生命周期等的管理，开发者接入框架以后只需要安心实现自己的算法，而不需要关心这些潜规则还有其他一些重复的逻辑操作。
在引入Flutter之前闲鱼的音视频架构与大部分音视频逻辑一样采用分层架构：

1：底层是一些独立模块

2：SDK层是对底层模块的封装

3：最上层是UI层。

引入Flutter之后，通过分析各个模块的使用场景，我们可以得出一个假设或者说是抽象：音视频应用在终端上可以归纳为视频帧解码之后视频数据帧在各个模块之间流动的过程，基于这种假设去做Flutter音视频框架的抽象。

咸鱼Flutter多媒体开源组件
整个Flutter音视频框架抽象分为管线和数据的抽象、模块的抽象、线程统一管理和上下文同一管理四部分。
管线，其实就是视频帧流动的管道。数据，音视频中涉及到的数据包括纹理、Bit Map以及时间戳等。结合现有的应用场景我们定义了管线流通数据以Texture为主数据，同时可以选择性的添加Bit Map等作为辅助数据。这样的数据定义方式，避免重复的创建和销毁纹理带来的性能开销以及多线程访问纹理带来的一些问题。也满足一些特殊模块对特殊数据的需求。同时也设计了纹理池来管理管线中的纹理数据。
模块：如果把管线和数据比喻成血管和血液，那框架音视频的场景就可以比喻成器官，我们根据模块所在管线的位置抽象出采集、处理和输出三个基类。这三个基类里实现了刚才说的线程切换，上下文切换，格式转换等等共同逻辑，各个功能模块通过集成自这些基类，可以避免很多重复劳动。
线程：每一个模块初始化的时候，初始化函数就会去线程管理的模块去获取自己的线程，线程管理模块可以决定给初始化函数分配新的线程或者已经分配过其他模块的线程。

这样有三个好处：

一是可以根据需要去决定一个线程可以挂载多少模块，做到线程间的负载均衡。第二，多线程并发式能够保证模块内的OpenGL操作是在当前线程内而不会跑到主线程去，彻底避免Flutter的OpenGL 环境被破坏。第三，多线程并行可以充分利用CPU多核架构，提升处理速度。
从Flutter端修改Flutter引擎将Context取出后，根据Context创建上下文的统一管理模块，每一个模块在初始化的时候会获取它的线程，获取之后会调用上下文管理模块获取自己的上下文。这样可以保证每一个模块的上下文都是与Flutter的上下文进行Share的，每个模块之间资源都是共享可见的，Flutter和音视频native之间也是互相共享可见的。
基于上述框架如果要实现一个简单的场景，比如画面实时预览和滤镜处理功能，

1：需要选择功能模块，功能模块包括摄像头模块、滤镜处理模块和Flutter画面渲染模块，

2：需要配置模块参数，比如采集分辨率、滤镜参数和前后摄像头设置等，

3：在创建视频管线后使用已配置的参数创建模块

4：最后管线搭载模块，开启管线就可以实现这样简单的功能。
上图为整个功能实现的代码和结构图。
结合上述音视频框架，闲鱼实现了Flutter多媒体开源组件。

组要包含四个基本组件分别是：

1：视频图像拍摄组件

2：播放器组件

3：视频图像编辑组件

4：相册选择组件

现在这些组件正在走内部开源流程。预计9月份，相册和播放器会实现开源。

后续展望和规划
1：实现开头所说的从底层SDK到UI的全链路的跨端开发。目前底层框架层和模块层都是各个平台各自实现，反而是Flutter的UI端进行了跨平台的统一，所以后续会将底层也按照音视频常用做法把逻辑下沉到C++层，尽可能的实现全链路跨平台。

2：第二部分内容为开源共建，闲鱼开源的内容不仅包括拍摄、编辑组件，还包括了很多底层模块，希望有开发者在基于Flutter开发音视频应用时可以充分利用闲鱼开源出的音视频模块能力，搭建APP框架，开发者只要去负责实现特殊需求模块就可以，尽可能的减少重复劳动。

音视频开发三大就业方向

音视频开发，无论音视频开发技术你做iOS/Android/Qt客户端，还是嵌入式linux,服务器开发。最后可分为三大就业方向：

1 流媒体网络通讯开发
流媒体网络通讯开发岗位 占70%～ 80%，就业，集中在芯片，安防，数字电视，广告，行车记录仪，车载系统，智能家居，楼宇对讲，视频会议....大部分从业者吃饭靠这个领域。需要掌握音视频开发技术的是unix操作系统，网络socket通讯, 音视频基础,264/265基础，编解码,FFmpeg,常见音视频开发技术的网络通讯协议TCP/UDP/RTMP/RTSP/RTP/HLS,当然还有WebRTC. 为什么大部分就业岗位都在这个领域，因为这个领域百花齐放，大量的硬件公司，各行各业，光一个跟摄像头相关的安防产业年产值就是几万亿，只要有摄像头的地方，就需要软件开发者，而且薪水还不错，入门者大部分年薪30W+。年薪50W，百万级的程序员也有，主要研究音视频流媒体领域的应用。

2 数字图像处理
音视频图像处理岗位，占大约20%+。主要集中在视频剪辑，特效，医疗，教育领域. 最近几年新兴的VR/AR领域。需要掌握的主要是音视频开发基础，FFmpeg,  重点是OpenGL/ES，会大量使用OpenGL/ES去写一些轻量级的渲染引擎。你可以把它看作一个精简版的游戏渲染引擎。这个领域有些特殊，容易跟互联网结合，一些软件容易形成垄断，比如视频剪辑领域，就那么三四个玩家。垄断了80%以上的份额。Finalcut pro , premire, Davinci..  形成垄断的行业，绝大多数利润会向头部集中，也就不需要那么多就业，细分领域不多。

当然，这个领域也有自己的一些优势，比如比流媒体容易学习一些。未来十年前景也非常好。可以快速上手。c c++基础好，精通OpenGL/FFmpeg，可以轻松上年薪50W+.

3 AI 
小于5%  其实AI本来应该发展很迅猛的，但受限于MYZ，疫情，芯片严重缺货。终端，边缘计算领域，这几年还没发展起来。这个领域需要部分音视频基础 opencv，tensorflow，机器学习，深度学习...

总结

三大方向，基础都差不多。c/c++ unix操作系统，网络通讯.

最后每个人的发展侧重点不一样，有的做网络通讯比较多，有的做数字图像处理…  计算机领域的知识很庞大，就一个音视频这么小的一个领域，你就只能做其中一个点，比如专注网络通讯流媒体，专注图像处理。都是十年磨一剑的领域，想通吃，就准备花大量的时间研究学习，熬夜。甚至准备进ICU，腰椎间盘突出... 所以即使在音视频开发领域，最后选择一个自己喜欢的方向依然重要。

有的人在做iOS,有的人在做安卓，有的人在做嵌入式linux，还有的人在做PC/Qt开发。

到最后你发现都大同小异。

无论你做什么，人一辈子，要做到终身学习，每天学习。

每天进步一点点。日积月累，才能有所成就。

音视频技术发展

音视频技术音视频开发技术的发展会越来越往云服务发展音视频开发技术，未来音视频直播云服务可能有两个趋势：
1）公共事业服务化：未来会更加趋向于接受由专业音视频开发技术的人做专业的事情音视频开发技术，音视频直播云服务会成为像自来水一样广泛而且中立的公共事业服务，就像今天的基础云服务一样，谁都可以很便利很放心地使用，没有人担心安全性，也没有必要重复发明轮子。
2）成为互联网主流互动方式： 音视频的流量占网络流量的比例越来越大，VR/AR音视频的信息量还会有数倍的提升，可以预测音视频通讯成为网络流量的主要贡献者。从用户的角度来说，要能听见看见，音视频互动是最直观最自然的互动方式。从商业的角度来说，网络运营商，基础云商还有CDN网络，都会特别喜欢这个趋势，毕竟音视频的流量比文本的流量大的多，流量多起来了，就意味着更大规模的基建，更大规模的收入流水。因此，网络运营商、基础云商、CDN网络和音视频直播云服务商都会把音视频技术作为标配能力。毕竟，控制主要流量的来源，就控制了未来发展的命脉。
当我们在展望未来，未来已经变成了现在。要能听见看见，这个自然而简单的需求，会让音视频直播云服务在未来跟随着智能终端深入到互联网生活的每一个环节中去，深刻地改变人们互动沟通的方式。

Android -- 音视频基础知识

帧音视频开发技术，是视频的一个基本概念音视频开发技术，表示一张画面，如上面的翻页动画书中的一页，就是一帧。一个视频就是由许许多多帧组成的。

帧率，即单位时间内帧的数量，单位为：帧/秒 或fps（frames per second）。一秒内包含多少张图片，图片越多，画面越顺滑，过渡越自然。 帧率的一般以下几个典型值：

24/25 fps：1秒 24/25 帧，一般的电影帧率。

30/60 fps：1秒 30/60 帧，游戏的帧率，30帧可以接受，60帧会感觉更加流畅逼真。

85 fps以上人眼基本无法察觉出来了，所以更高的帧率在视频里没有太大意义。

这里我们只讲常用到的两种色彩空间。

RGB的颜色模式应该是我们最熟悉的一种，在现在的电子设备中应用广泛。通过R G B三种基础色，可以混合出所有的颜色。

这里着重讲一下YUV，这种色彩空间并不是我们熟悉的。这是一种亮度与色度分离的色彩格式。

早期的电视都是黑白的，即只有亮度值，即Y。有了彩色电视以后，加入了UV两种色度，形成现在的YUV，也叫YCbCr。

Y：亮度，就是灰度值。除了表示亮度信号外，还含有较多的绿色通道量。

U：蓝色通道与亮度的差值。

V：红色通道与亮度的差值。

音频数据的承载方式最常用的是 脉冲编码调制 ，即 PCM 。

在自然界中，声音是连续不断的，是一种模拟信号，那怎样才能把声音保存下来呢？那就是把声音数字化，即转换为数字信号。

我们知道声音是一种波，有自己的振幅和频率，那么要保存声音，就要保存声音在各个时间点上的振幅。

而数字信号并不能连续保存所有时间点的振幅，事实上，并不需要保存连续的信号，就可以还原到人耳可接受的声音。

根据奈奎斯特采样定理：为了不失真地恢复模拟信号，采样频率应该不小于模拟信号频谱中最高频率的2倍。

根据以上分析，PCM的采集步骤分为以下步骤：

采样率，即采样的频率。

上面提到，采样率要大于原声波频率的2倍，人耳能听到的最高频率为20kHz，所以为了满足人耳的听觉要求，采样率至少为40kHz，通常为44.1kHz，更高的通常为48kHz。

采样位数，涉及到上面提到的振幅量化。波形振幅在模拟信号上也是连续的样本值，而在数字信号中，信号一般是不连续的，所以模拟信号量化以后，只能取一个近似的整数值，为了记录这些振幅值，采样器会采用一个固定的位数来记录这些振幅值，通常有8位、16位、32位。

位数越多，记录的值越准确，还原度越高。

最后就是编码了。由于数字信号是由0，1组成的，因此，需要将幅度值转换为一系列0和1进行存储，也就是编码，最后得到的数据就是数字信号：一串0和1组成的数据。

整个过程如下：

声道数，是指支持能不同发声（注意是不同声音）的音响的个数。 单声道：1个声道
双声道：2个声道
立体声道：默认为2个声道
立体声道（4声道）：4个声道

码率，是指一个数据流中每秒钟能通过的信息量，单位bps（bit per second）

码率 = 采样率 * 采样位数 * 声道数

这里的编码和上面音频中提到的编码不是同个概念，而是指压缩编码。

我们知道，在计算机的世界中，一切都是0和1组成的，音频和视频数据也不例外。由于音视频的数据量庞大，如果按照裸流数据存储的话，那将需要耗费非常大的存储空间，也不利于传送。而音视频中，其实包含了大量0和1的重复数据，因此可以通过一定的算法来压缩这些0和1的数据。

特别在视频中，由于画面是逐渐过渡的，因此整个视频中，包含了大量画面/像素的重复，这正好提供了非常大的压缩空间。

因此，编码可以大大减小音视频数据的大小，让音视频更容易存储和传送。

视频编码格式有很多，比如H26x系列和MPEG系列的编码，这些编码格式都是为了适应时代发展而出现的。

其中，H26x（1/2/3/4/5）系列由ITU（International Telecommunication Union）国际电传视讯联盟主导

MPEG（1/2/3/4）系列由MPEG（Moving Picture Experts Group, ISO旗下的组织）主导。

当然，他们也有联合制定的编码标准，那就是现在主流的编码格式H264，当然还有下一代更先进的压缩编码标准H265。

H264是目前最主流的视频编码标准，所以我们后续的文章中主要以该编码格式为基准。

H264由ITU和MPEG共同定制，属于MPEG-4第十部分内容。

我们已经知道，视频是由一帧一帧画面构成的，但是在视频的数据中，并不是真正按照一帧一帧原始数据保存下来的（如果这样，压缩编码就没有意义了）。

H264会根据一段时间内，画面的变化情况，选取一帧画面作为完整编码，下一帧只记录与上一帧完整数据的差别，是一个动态压缩的过程。

在H264中，三种类型的帧数据分别为

I帧：帧内编码帧。就是一个完整帧。

P帧：前向预测编码帧。是一个非完整帧，通过参考前面的I帧或P帧生成。

B帧：双向预测内插编码帧。参考前后图像帧编码生成。B帧依赖其前最近的一个I帧或P帧及其后最近的一个P帧。

全称：Group of picture。指一组变化不大的视频帧。

GOP的第一帧成为关键帧：IDR

IDR都是I帧，可以防止一帧解码出错，导致后面所有帧解码出错的问题。当解码器在解码到IDR的时候，会将之前的参考帧清空，重新开始一个新的序列，这样，即便前面一帧解码出现重大错误，也不会蔓延到后面的数据中。

DTS全称：Decoding Time Stamp。标示读入内存中数据流在什么时候开始送入解码器中进行解码。也就是解码顺序的时间戳。

PTS全称：Presentation Time Stamp。用于标示解码后的视频帧什么时候被显示出来。

前面我们介绍了RGB和YUV两种图像色彩空间。H264采用的是YUV。

YUV存储方式分为两大类：planar 和 packed。

planar如下：

packed如下：

上面说过，由于人眼对色度敏感度低，所以可以通过省略一些色度信息，即亮度共用一些色度信息，进而节省存储空间。因此，planar又区分了以下几种格式：YUV444、 YUV422、YUV420。

YUV 4:4:4采样，每一个Y对应一组UV分量。

YUV 4:2:2采样，每两个Y共用一组UV分量。

YUV 4:2:0采样，每四个Y共用一组UV分量。

其中，最常用的就是YUV420。

YUV420属于planar存储方式，但是又分两种类型：

YUV420P：三平面存储。数据组成为YYYYYYYYUUVV（如I420）或YYYYYYYYVVUU（如YV12）。

YUV420SP：两平面存储。分为两种类型YYYYYYYYUVUV（如NV12）或YYYYYYYYVUVU（如NV21）

原始的PCM音频数据也是非常大的数据量，因此也需要对其进行压缩编码。

和视频编码一样，音频也有许多的编码格式，如：WAV、MP3、WMA、APE、FLAC等等，音乐发烧友应该对这些格式非常熟悉，特别是后两种无损压缩格式。

但是，我们今天的主角不是他们，而是另外一个叫AAC的压缩格式。

AAC是新一代的音频有损压缩技术，一种高压缩比的音频压缩算法。在MP4视频中的音频数据，大多数时候都是采用AAC压缩格式。

AAC格式主要分为两种：ADIF、ADTS。

ADIF：Audio Data Interchange Format。音频数据交换格式。这种格式的特征是可以确定的找到这个音频数据的开始，不需进行在音频数据流中间开始的解码，即它的解码必须在明确定义的开始处进行。这种格式常用在磁盘文件中。

ADTS：Audio Data Transport Stream。音频数据传输流。这种格式的特征是它是一个有同步字的比特流，解码可以在这个流中任何位置开始。它的特征类似于mp3数据流格式。

ADIF数据格式：

ADTS 一帧 数据格式（中间部分，左右省略号为前后数据帧）：

AAC内部结构也不再赘述，可以参考AAC 文件解析及解码流程

细心的读者可能已经发现，前面我们介绍的各种音视频的编码格式，没有一种是我们平时使用到的视频格式，比如：mp4、rmvb、avi、mkv、mov...

没错，这些我们熟悉的视频格式，其实是包裹了音视频编码数据的容器，用来把以特定编码标准编码的视频流和音频流混在一起，成为一个文件。

例如：mp4支持H264、H265等视频编码和AAC、MP3等音频编码。

我们在一些播放器中会看到，有硬解码和软解码两种播放形式给我们选择，但是我们大部分时候并不能感觉出他们的区别，对于普通用户来说，只要能播放就行了。

那么他们内部究竟有什么区别呢？

在手机或者PC上，都会有CPU、GPU或者解码器等硬件。通常，我们的计算都是在CPU上进行的，也就是我们软件的执行芯片，而GPU主要负责画面的显示（是一种硬件加速）。

所谓软解码，就是指利用CPU的计算能力来解码，通常如果CPU的能力不是很强的时候，一则解码速度会比较慢，二则手机可能出现发热现象。但是，由于使用统一的算法，兼容性会很好。

硬解码，指的是利用手机上专门的解码芯片来加速解码。通常硬解码的解码速度会快很多，但是由于硬解码由各个厂家实现，质量参差不齐，非常容易出现兼容性问题。

MediaCodec 是Android 4.1(api 16)版本引入的编解码接口，是所有想在Android上开发音视频的开发人员绕不开的坑。

由于Android碎片化严重，虽然经过多年的发展，Android硬解已经有了很大改观，但实际上各个厂家实现不同， 还是会有一些意想不到的坑。

相对于FFmpeg，Android原生硬解码还是相对容易入门一些，所以接下来，我将会从MediaCodec入手，讲解如何实现视频的编解码，以及引入OpenGL实现对视频的编辑，最后才引入FFmpeg来实现软解，算是一个比较常规的音视频开发入门流程吧。

音视频技术实务主要学什么？

音视频技术实务主要学习的是音频音视频开发技术，视频的录制。处理。剪辑。发布。主要处理的是音频和视频的内容以及在制作过程当中的相映剪辑工作。如音频音视频开发技术，视频的杂志音量音视频开发技术，或者说视频信息的。清晰度等情况需要做处理。让一段音质并不完美音视频开发技术，视频图像并不清晰的作品能够通过不停的剪辑。修整或者说一定的修复，达到一种是音频清晰。视频清晰的效果。 关于音视频开发技术和音视频软件开发的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 音视频开发技术的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于音视频软件开发、音视频开发技术的信息别忘了在本站进行查找喔。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。