前言

周五由于开了一下午会议,开完会就快下班了。就没来及更新内容,罪过罪过今日来更新下最终一篇。附带一些面试内容

10.19-24音视频中高档52部+面试
10.25-26高档Android组件化强化实战(一二)
10.27-11.3高档Android组件化强化实战(大厂架构演化20章)
中心一切的周六周日都歇息

重视大众号:Android苦做舟 解锁 《Android十二大板块PDF》
音视频大合集,从初中高到面试包罗万象;让学习更靠近未来实战。已形成PDF版

十二个模块PDF内容如下

1.2022最新Android11位大厂面试专题,128道附答案
2.音视频大合集,从初中高到面试包罗万象
3.Android车载使用大合集,从零开端一同学
4.功能优化大合集,告别优化烦恼
5.Framework大合集,从里到外剖析的明明白白
6.Flutter大合集,进阶Flutter高档工程师
7.compose大合集,拥抱新技能
8.Jetpack大合集,全家桶一次吃个够
9.架构大合集,轻松应对作业需求
10.Android根底篇大合集,根基安定高楼平地起
11.Flutter番外篇:Flutter面试+项目实战+电子书
12.大厂高档Android组件化强化实战

整理不易,重视一下吧。开端进入正题,ღ( ・ᴗ・` )

一丶音视频面试题

1.为什么巨大的原始视频能够编码成很小的视频呢?这其间的技能是什么呢?

参考答案
  • 1)空间冗余:图画相邻像素之间有较强的相关性
  • 2)时刻冗余:视频序列的相邻图画之间内容相似
  • 3)编码冗余:不同像素值呈现的概率不同
  • 4)视觉冗余:人的视觉体系对某些细节不敏感
  • 5)常识冗余:规律性的结构可由先验常识和背景常识得到

2.怎样做到直播秒开优化?

参考答案
  • DNS 解析慢 为了有用下降 DNS 解析对首开的影响,咱们能够提早完结播映域名->IP 地址的解析, 并缓存起来,播映的时分,直接传入带 IP 地址的播映地址,然后省去了 DNS 解析的耗时。 假如要支撑用 IP 地址播映,是需求修正底层 ffmpeg 源码的。
  • 播映战略 很多偏重点播的播映器,为了削减卡顿,会有一些缓冲战略,当缓冲足够多的数据之后 ,再送入解码播映。

而为了加快首开效果,需求对播映的缓冲战略做一些调整,假如榜首帧还没有烘托出来的状况下, 不要做任何缓冲,直接送入解码器解码播映,这样就能够确保没有任何由于「主动」缓冲带来的首开延时。

  • 播映参数设置 一切依据 ffmpeg 的播映器,都会遇到avformat_find_stream_info这个函数耗时比较久, 然后增大了首开时刻,该函数首要作用是经过读取必定字节的码流数据, 来剖析码流的根本信息,如编码信息、时长、码率、帧率等等,它由两个参数来操控其读取的数据量巨细和时长, 一个是 probesize,一个是 analyzeduration。

削减 probesize 和 analyzeduration 能够有用地削减avformat_find_stream_info的函数耗时, 然后加快首开,可是需求留意的是,设置地太小或许会导致读取的数据量不足,然后无法解分出码流信息,导致播映失败, 或许呈现只要音频没有视频,只要视频没有音频的问题。

  • 服务端优化
  • 服务器关键帧缓冲
  • CDN最近战略

3.图画能够提取的特征有哪些?

参考答案

颜色、纹路(粗糙度、方向度、对比度)、形状(曲率、离心率、主轴方向)、颜色等。

4.AAC和PCM的差异?

参考答案

AAC在数据开端时分加了一些参数:采样率、声道、采样巨细

5.H264存储的两个形状?

参考答案
  • a. Annex B :

StartCode :NALU单元,开头一般是0001或许001 防竞赛字节:为了差异 0 0 0 1,它选用0 0 0 0x3 1作为差异 多用于网络流媒体中:rtmp、rtp格局

  • b. AVCC :

表明NALU长度的前缀,不定长用4、2、1来存储这个NALU的长度 防竞赛字节 多用于文件存储中mp4的格局

6.FFMPEG:图片怎么合成视频

参考答案

编码流程:

  1. av_register_all
  2. 为AVFormatContext 分配内存
  3. 翻开文件
  4. 创立输出码流AVSream
  5. 找到编码器
  6. 翻开编码器
  7. 写文件头,没有的就不写入
  8. 循环编码视频像素数据->视频紧缩数据
  • 循环编码音频采样数据->音频紧缩数据 ———>AVFrame转化为AVPacket
  1. 将编码后的视频码流写入文件 ——>AVPacket转化为AVFormat函数
  2. 关闭编码器
  3. 写文件尾
  4. 关闭资源文件

解码流程:

  1. av_register_all
  2. 创立AVFormatContext的对象上下文
  3. 翻开文件
  4. avformat_find_stream_info
  5. 找到解码器
  6. 翻开解码器
  7. 创立AVCodecContext上下文
  8. av_read_frame :将avPacket数据转化为avFrame数据

glUniform1i() ——>这个能够设置对应纹路的第几层 glTexSubImage2D() 和glTexImage2D差异————>替换纹路的内容

7.常见的音视频格局有哪些?

参考答案
  1. MPEG(运动图画专家组)是Motion Picture Experts Group 的缩写。这类格局包括了MPEG-1,MPEG-2和MPEG-4在内的多种视频格局。
  2. AVI,音频视频交错(Audio Video Interleaved)的英文缩写。AVI这个由微软公司发布的视频格局,在视频范畴能够说是最悠长的格局之一。
  3. MOV,运用过Mac机的朋友应该多少触摸过QuickTime。QuickTime原本是Apple公司用于Mac核算机上的一种图画视频处理软件。
  4. ASF(Advanced Streaming format高档流格局)。ASF 是MICROSOFT 为了和的Real player 竞赛而发展出来的一种能够直接在网上观看视频节意图文件紧缩格局。
  5. WMV,一种独立于编码办法的在Internet上实时传达多媒体的技能规范,Microsoft公司期望用其替代QuickTime之类的技能规范以及WAV、AVI之类的文件扩展名。
  6. NAVI,假如发现本来的播映软件突然打不开此类格局的AVI文件,那你就要考虑是不是碰到了n AVI。n AVI是New AVI 的缩写,是一个名为Shadow Realm 的地下组织发展起来的一种新视频格局。
  7. 3GP是一种3G流媒体的视频编码格局,首要是为了配合3G网络的高传输速度而开发的,也是现在手机中最为常见的一种视频格局。
  8. REAL VIDEO(RA、RAM)格局由一开端便是定位在视频流使用方面的,也能够说是视频流技能的始创者。
  9. MKV,一种后缀为MKV的视频文件一再呈现在网络上,它可在一个文件中集成多条不同类型的音轨和字幕轨,而且其视频编码的自由度也十分大,能够是常见的DivX、XviD、3IVX,乃至能够是RealVideo、QuickTime、WMV 这类流式视频。
  10. FLV是FLASH VIDEO的简称,FLV流媒体格局是一种新的视频格局。由于它形成的文件极小、加载速度极快,使得网络观看视频文件成为或许,它的呈现有用地处理了视频文件导入Flash后,使导出的SWF文件体积庞大,不能在网络上很好的运用等缺陷。
  11. F4V,作为一种更小更明晰,更利于在网络传达的格局,F4V现已逐渐替代了传统FLV,也现已被大多数干流播映器兼容播映,而不需求经过转化等复杂的办法。

8.在MPEG规范中图画类型有哪些?

参考答案

I帧图画, P帧图画, B帧图画

9.列举一些音频编解码常用的完结计划?

参考答案
  • 榜首种计划:便是选用专用的音频芯片对 语音信号进行收集和处理,音频编解码算法集成在硬件内部,如 MP3 编解码芯片、语音合成 剖析芯片等。运用这种计划的长处便是处理速度块,规划周期短;缺陷是局限性比较大,不灵敏,难以进行体系晋级。
  • 第二种计划:便是运用 A/D 收集卡加上核算机组成硬件渠道,音频编解码算法由核算机上的软件来完结。运用这种计划的长处是价格便 宜,开发灵敏而且利于体系的晋级;缺陷是处理速度较慢,开发难度较大。
  • 第三种计划:是运用高精度、高速度 的 A/D 收集芯片来完结语音信号的收集,运用可编程的数据处理能力强的芯片来完结语音信号处理的算法,然后 用 ARM 进行操控。选用这种计划的长处是体系晋级能力强,能够兼容多种音频紧缩格局乃至未来的音频紧缩格 式,体系本钱较低;缺陷是开发难度较大,规划者需求移植音频的解码算法到相应的 ARM 芯 片中去。

10.请叙说MPEG视频根本码流结构?

参考答案
  1. Sequence Header
  2. Sequence Extention
  3. Group of picture Header
  4. Picture Header
  5. Picture coding extension

11.说一说ffmpeg的数据结构?

参考答案

ffmpeg的数据结构能够分为以下几类:

  • (1)解协议(http,rtsp,rtmp,mms) AVIOContext,URLProtocol,URLContext首要存储视音频运用的协议的类型以及状况。 URLProtocol存储输入音视频运用的封装格局。每种协议都对应一个URLProtocol结构。(留意:FFMPEG中文件也被作为一种协议“file”)

  • (2)解封装(flv,avi,rmvb,mp4) AVFormatContext首要存储视音频封装格局中包括的信息 ffmpeg支撑各式各样的音视频输入和输出文件格局(例如FLV, MKV, MP4, AVI),而 AVInputFormat和AVOutputFormat 结构体则保存了这些格局的信息和一些惯例设置。

  • (3)解码(h264,mpeg2,aac,mp3) AVStream是存储每一个视频/音频流信息的结构体。 AVCodecContext: 编解码器上下文结构体,存储该视频/音频流运用解码办法的相关数据。 AVCodec: 每种视频(音频)编解码器(例如H.264解码器)对应一 个该结构体。 三者的联系如下图:

音视频大合集最终篇;学废了

  • (4)存数据 关于视频,每个结构一般是存一帧;音频或许有好几帧

    • 解码前数据:AVPacket

    • 解码后数据:AVFrame

12.说一说AVFormatContext 和 AVInputFormat之间的联系?

参考答案

音视频大合集最终篇;学废了

  • AVInputFormat被封装在AVFormatContext里

  • AVFormatContext 作为API被外界调用

  • AVInputFormat 首要是FFmpeg内部调用

  • AVFormatContext里保存了视频文件封装格局相关信息,它是担任储存数据的结构体。而AVInputFormat代表了各个封装格局,归于办法,这是一种面向对象的封装。

经过 int avformat_open_input(AVFormatContext **ps, const char filename,AVInputFormat fmt, AVDictionary options)函数装载解封装器. AVFormatContext 和 AVInputFormat之间的联系

13.说一说AVFormatContext, AVStream和AVCodecContext之间的联系?

参考答案

音视频大合集最终篇;学废了
AVStream和AVpacket中都有index字段用于差异不同的码流(视频、音频、字幕等),AVFormatContext中包括输入的AVStream数组用于记载各个码流,nb_streams记载输入码流的数量。AVCodecContext记载着AVStream需求用那种解码器来进行解码。

14.说一说视频拼接处理进程?(细节处理,比方分辨率巨细不一,时刻处理等等)

参考答案

解封装、解码、决议分辨率巨细、编码、时刻处理、封装。

15.编解码处理时遇到什么困难?

参考答案

ffmpeg 在编解码的进程:

  • 运用 ffmpeg 的 libavcoder,libavformat 的库及或许性编解码
  • 编码进程:
    • 收集出来的视频、音频数据运用 ffmpeg 进行紧缩
    • 进行按接连的视频,音频进行分组打包,为了差异各种包,也要包加上包头,包头写上显现时刻戳 PTS,解码时刻戳 DTS,经过网络传输到播映端
  • 解码进程:
    • 经过 TCP 协议接纳到媒体流,FFmpeg 解封装,解码
    • 终究获取到原始视频 YUV,音频 PCM 格局,运用播映器进行播映

16.怎么秒开视频?什么是秒开视频?

参考答案
  • 1.什么是秒开视频? 秒开是指用户点击播映到看到画面的时刻十分短,在 1 秒之内。

  • 2.为什么需求秒开? 现在干流的直播协议是 RTMP,HTTP-FLV 和 HLS,都是依据 TCP 的长衔接。在播映的进程中,若播映端所处的网络环境在一个较佳的状况,此刻播映会很流通。若网络环境不是很稳定,常常会产生颤动,假如播映端没有特殊处理,或许会常常产生卡顿,严峻的乃至会呈现黑屏。而移动直播由于其快捷性,用户能够随时随地建议和观看直播,咱们无法确保用户的网络一向处于十分好的状况,所以,在网络不稳定的状况下确保播映的流通度是十分重要的。

  • 3.处理思路

    • 获取关键帧后显现 改写播映器逻辑让播映器拿到榜首个关键帧后就给予显现。 GOP 的榜首个帧通常都是关键帧,由于加载的数据较少,能够到达 “首帧秒开”。假如直播服务器支撑 GOP 缓存,意味着播映器在和服务器树立衔接后可当即拿到数据,然后省却跨地域和跨运营商的回源传输时刻。 GOP 体现了关键帧的周期,也便是两个关键帧之间的距离,即一个帧组的最大帧数。假设一个视频的稳定帧率是 24fps(即 1 秒 24 帧图画),关键帧周期为 2s,那么一个 GOP 便是 48 张图画。一般而言,每一秒视频至少需求运用一个关键帧。 添加关键帧个数可改善画质(GOP通常为 FPS 的倍数),可是一同添加了带宽和网络负载。这意味着,客户端播映器下载一个 GOP,究竟该 GOP 存在必定的数据体积,假如播映端网络不佳,有或许不是能够快速在秒级以内下载完该 GOP,进而影响观感体会。 假如不能更改播映器行为逻辑为首帧秒开,直播服务器也能够做一些取巧处理,比方从缓存 GOP 改成缓存双关键帧(削减图画数量),这样能够极大程度地削减播映器加载 GOP 要传输的内容体积。
    • app 事务逻辑层面优化 比方提早做好 DNS 解析(省却几十毫秒),和提早做好测速选线(择取最优线路)。经过这样的预处理之后,在点击播映按钮时,将极大进步下载功能。

一方面,能够环绕传输层面做功能优化;另一方面,能够环绕客户播映行为做事务逻辑优化。两者能够有用的互为补充,作为秒开的优化空间。

  • 4.秒开视频计划

    • 优化服务器战略 播映器接入服务器恳求数据的时刻点的视频不必定是关键帧,那么需求比及下一个关键帧的到来,假如关键帧的周期是 2s 的话,那么等候的时刻或许会在 0~2s 的范围内,这段等候的时刻会影响首屏的加载时刻。假如服务器有缓存,则播映端在接入的时分,服务器能够向前找最近的关键帧发给播映端,这样就能够省去等候的时刻,能够大大的削减首屏的加载时刻。
    • 优化播映端战略 播映端恳求到的榜首帧数据肯定是关键帧,关键帧能够经过帧内参考进行解码。这样播映端就能够在接纳到榜首个关键帧的时分就当即开端解码显现,而不需求比及缓存必定数量的视频帧才开端解码,这样也能削减首屏画面显现的时刻。
  • 5.播映端首屏时长的优化 播映器的首屏进程中的几个进程

    • 首屏时刻,指的是从进入直播间开端到榜首次看到直播画面的时刻。首屏时刻过长极易导致用户失去对直播的耐心,下降用户的留存。但游戏直播对画面质量和连贯性的要求高,对应推流端编码后的数据量和其他类型直播相比大的多,怎么下降首屏时刻是一个不小的难题。

    • 在播映端的首屏进程中,首要有以下三个操作需求进行:加载直播间 UI(包括播映器自身)、下载直播数据流(未解码)宽和码数据播映。其间数据解码播映又细分为以下几个进程:

    • 检测传输协议类型(RTMP、RTSP、HTTP 等)并与服务器树立衔接接纳数据; 视频流解复用得到音视频编码数据(H.264/H.265、AAC 等);

    • 音视频数据解码,音频数据同步至外设,视频数据烘托都屏幕,至此,视频开端播映,首屏时刻完毕。

总结: 首要,加载 UI 能够以单例的办法进行,能够必定程度地进步首屏展现速度;其次,能够预设解码类型,削减数据类型检测时刻;再次,设定合理的下载缓冲区巨细,尽或许削减下载的数据量,当检测到 I 帧数据,当即开端解码单帧画面进行播映,进步首屏展现时刻。

17.怎么下降延迟?怎么确保流通性?怎么处理卡顿?处理网络颤动?

参考答案
  • 产生原因: 确保直播的流通性是指在直播进程中确保播映不产生卡顿,卡顿是指在播映进程中声响和画面呈现停滞,十分影响用户体会。形成卡顿的原因有几种状况:

推流端网络颤动导致数据无法发送到服务器,形成播映端卡顿; 播映端网络颤动导致数据累计在服务器上拉不下来,形成博凡卡顿。 由于从服务器到播映器的网络状况复杂,尤其是在 3G 和带宽较差的 WIFI 环境下,颤动和延迟常常产生,导致播映不流通,播映不流通带来的负面影响便是延时增大。怎么在网络颤动的状况下确保播映的流通性和实时性是确保直播功能的难点。

  • 流通度优化: 现在干流的直播协议是 RTMP、HTTP-FLV 和 HLS,都是依据 TCP 的长衔接。在播映的进程中,若播映端所处的网络环境在一个较佳的状况,此刻播映会很流通。若网络环境不是很稳定,常常会产生颤动,假如播映端没有做特殊处理,或许会常常产生卡顿,严峻的乃至会呈现黑屏。而移动直播由于其快捷性,用户能够随时随地建议和观看直播,咱们无法确保用户的网络一向处于一个十分好的状况,所以,在网络不稳定的状况下确保播映的流通度是十分重要的。

为了处理这个问题,首要播映器需求将拉流线程宽和码线程分隔,并树立一个缓冲行列用于缓冲音视频数据。拉流线程将从服务器上获取到的音视频流放入行列,解码线程从行列中获取音视频数据进行解码播映,行列的长度能够调整。当网络产生颤动时,播映器无法从服务器上获取到数据或获取数据的速度较慢,此刻行列中缓存的数据能够起到一个过渡的作用,让用户感觉不到网络产生了颤动。

当然这是关于网络产生颤动的状况所采取的战略,假如播映端的网络迟迟不能康复或服务器的边际结点呈现宕机,则需求使用层进行重连或调度。

18.H264/H265有什么差异?

参考答案

相同的画质和相同的码率,H.265比H2.64 占用的存储空间要少理论50%。假如存储空间相同大,那么意味着,在相同的码率下H.265会比H.264 画质要高一些理论值是30%~40%。

比起H.264,H.265供给了更多不同的东西来下降码率,以编码单位来说,最小的8×8到最大的64×64。信息量不多的区域(颜色变化不明显)区分的宏块较大,编码后的码字较少,而细节多的地方区分的宏块就相应的小和多一些,编码后的码字较多,这样就相当于对图画进行了有重点的编码,然后下降了整体的码率,编码功率就相应进步了。

H.265规范首要是环绕着现有的视频编码规范H.264,在保留了原有的某些技能外,添加了能够改善码流、编码质量、延时及算法复杂度之间的联系等相关的技能。H.265研讨的首要内容包括,进步紧缩功率、进步鲁棒性和错误康复能力、削减实时的时延、削减信道获取时刻和随机接入时延、下降复杂度。

19.视频或许音频传输,你会挑选TCP协议还是UDP协议?为什么?

参考答案

挑选UDP协议,UDP实时性好。TCP要确保丢掉的package会被再次重发,确保对方能够收到。 而在视频播映中,假如有一秒钟的信号确实,导致画面呈现了一点瑕疵,那么最合适的办法是把这点瑕疵用随意哪些信号补充上,这样尽管画面有一点点瑕疵可是不影响观看。假如用的TCP的话,这点缺失的信号会被一遍又一遍的发送过来直到接纳端承认收到。这不是音视频播映所期待的。而UDP就很适合这种状况。UDP不会一遍遍发送丢掉的package。

20.平常说的软解和硬解,详细是什么?

参考答案

硬解便是硬件解码,指运用GPU来部分替代CPU进行解码,软解便是软件解码,指运用软件让CPU来进行解码。两者的详细差异如下所示:

硬解码:是将本来全部交由CPU来处理的视频数据的一部分交由GPU来做,而GPU的并行运算能力要远远高于CPU,这样能够大大的下降对CPU的负载,CPU的占用率较低了之后就能够一同运转一些其他的程序了,当然,关于较好的处理器来说,比方i5 2320,或许AMD 任何一款四核心处理器来说,硬解和软件的差异只是个人偏好问题了吧。  

软解码:即经过软件让CPU来对视频进行解码处理;而硬解码:指不借助于CPU,而经过专用的子卡设备来独立完结视频解码使命。从前的VCD/DVD解压卡、视频紧缩卡等都隶归于硬解码这个范畴。而现如今,要完结高清解码现已不再需求额外的子卡,由于硬解码的模块现已被整合到显卡GPU的内部,所以现在的干流显卡(集显)都能够支撑硬解码技能。

21.何为直播?何为点播?

参考答案

直播:是一个三方交互(主播、服务器、观众),这个交互式实时的!尽管会依据挑选的协议不同而有一些延迟,但咱们仍以为它直播是实时的!—>主播在本地发送音视频给服务器(推流),观众从服务器实时解码(拉流)收看收听主播发送给服务器的音视频(直播内容)。直播是不能快进的

点播:首要必定要清晰的一点,点播不存在推流这一进程,你自身你的流现已早就推给服务器了,或许这么说也不对,应该是你的音视频早就上传到了服务器,观众只需求在线收看即可,由于你的音视频上传到了服务器,观众则能够经过快进,快退,调整进度条等办法进行收看!

22.简述推流、拉流的作业流程?

参考答案

推流:在直播中,一方向服务器发送恳求,向服务器推送自己正在实时直播的数据,而这些内容在推送到服务器的这一进程中是以 “流” 的方式传递的,这便是“推流”,把音视频数据以流的办法推送(或上传)到服务器的进程便是“推流”! 推流方的音视频往往会很大,在推流的进程中首要按照 aac音频-编码 和 h264视【大众渠道不能呈现视频这两个字,真是坑】频-编码的规范把推过来的音视频紧缩 ,然后合并成 MP4或许 FLV格局,然后依据直播的封装协议,最终传给服务器完结推流进程。

拉流:与推流正好相反,拉流是用户从服务器获取推流方给服务器的音视频的进程,这便是“拉流”!拉流首要aac音频-解码 和 h.264视频-解码的内部把推过来的音视频解紧缩,然后合成 MP4或许 FLV 格局,再解封装,最终到咱们的客户端与观众进行交互。

23.音频测验的测验点,音频时延怎么测验?

参考答案

测验点:功能,功能,兼容性,耗电量,安全性,压力测验,客观音质POLQA分,音质主观体会,主播到观众时延,观众到观众时延,3A效果 音频时延:经过音频线将2个被测对象衔接在电脑,用PESQ脚本算出音频时延

24.什么是GOP?

参考答案

GOP ( Group of Pictures ) 是一组接连的画面,由一张 I 帧和数张 B / P 帧组成,是视频图画编码器宽和码器存取的根本单位。 也便是说GOP组是指一个关键帧I帧地点的组的长度,每个 GOP 组只要 1 个 I 帧。 GOP 组的长度格局也决议了码流的巨细。 GOP越大,中心的P帧和B帧的数量就越多,所以解码出来的视频质量就越高,可是会影响编码功率。

25.为什么要有YUV这种数据出来?(YUV相比RGB来说的长处)

参考答案

RGB是指光学三原色红、绿和蓝,经过这3种的数值(0-255)改变能够组成其他颜色,全0时为黑色,全255时为白色。RGB是一种依赖于设备的颜色空间:不同设备对特定RGB值的检测和重现都不相同,由于颜色物质(荧光剂或许染料)和它们对红、绿和蓝的独自呼应水平跟着制造商的不同而不同,乃至是相同的设备不同的时刻也不同。

YUV,是一种颜色编码办法。常运用在各个视频处理组件中。三个字母别离表明亮度信号Y和两个色差信号R-Y(即U)、B-Y(即V),作用是描绘影像颜色及饱和度,用于指定像素的颜色。Y’UV的发明是由于彩色电视与是非电视的过渡时期。是非视频只要Y视频,也便是灰阶值。与咱们熟知的RGB相似,YUV也是一种颜色编码办法,首要用于电视体系以及模仿视频范畴,它将亮度信息(Y)与颜色信息(UV)分离,没有UV信息相同能够显现完整的图画,只不过是是非的,这样的规划很好地处理了彩色电视机与是非电视的兼容问题。而且,YUV不像RGB那样要求三个独立的视频信号一同传输,所以用YUV办法传送占用很少的频宽。

YUV和RGB是能够彼此转化的,根本上一切图画算法都是依据YUV的,一切显现面板都是接纳RGB数据。

26.猜测编码的根本原理是什么?

参考答案

猜测编码是数据紧缩理论的一个重要分支。依据离散信号之间存在必定相关性特点,运用前面的一个或多个信号对下一个信号进行猜测,然后对实践值和预值的差(猜测差错)进行编码。假如猜测比较精确,那么差错信号就会很小,就能够用较少的码位进行编码,以到达数据紧缩的意图。

原理:运用以往的样本值对新样本值进行猜测,将新样本值的实践值与其猜测值相减,得到差错值,对该差错值进行编码,传送此编码即可。理论上数据源能够精确地用一个数学模型表明,使其输出数据总是与模型的输出共同,因而能够精确地猜测数据,可是实践上猜测器不或许找到如此完美的数学模型;猜测自身不会形成失真。差错值的編码能够选用无失真压縮法或失真压縮法。

27.DTS与PTS共同点?

参考答案
  • PTS便是Presentation Time Stamp也就说这个帧什么时分会放在显现器上;
  • DTS便是Decode Time Stamp,便是说这个帧什么时分被放在编码器去解。 在没有B帧的状况下,DTS和PTS的输出顺序是相同的。

28.请叙说AMR根本码流结构?

参考答案

AMR文件由文件头和数据帧组成,文件头标识占6个字节,后面紧跟着便是音频帧;

格局如下所示:

文件头(占 6 字节)| :— | 语音帧1 | 语音帧2 | … |

  • 文件头: 单声道和多声道状况下文件的头部是不共同的,单声道状况下的文件头只包括一个Magic number,而多声道状况下文件头既包括Magic number,在其之后还包括一个32位的Chanel description field。多声道状况下的32位通道描绘字符,前28位都是保留字符,有必要设置成0,最终4位说明运用的声道个数。
  • 语音数据: 文件头之后便是时刻上接连的语音帧块了,每个帧块包括若干个8位组对齐的语音帧,相关于若干个声道,从榜首个声道开端依次排列。每一个语音帧都是从一个8位的帧头开端:其间P为填充位有必要设为0,每个帧都是8位组对齐的。

29.sps和pps的差异?

参考答案

SPS是序列参数集 0x67 PPS是图画参数集 0x68 在SPS序列参数集中能够解分出图画的宽,高和帧率等信息。而在h264文件中,最开端的两帧数据便是SPS和PPS,这个h264文件只存在一个SPS帧和一个PPS帧。

30.讨论区

何为音视频同步,音视频同步怎么同步?
说说你平常在播映进程中做的优化作业?
常见的直播协议有哪些?之间有什么差异?
美颜的完结原理,详细完结进程?
怎么测验一个美颜挂件?

二丶x264和NDK在Centos7上穿插编译

目标: 运用Centos 7编译出Android运用的X264的so库和头文件

预备: 不熟悉的能够看上一篇文章:Centos编译ffmpeg Android NDK: 本文示例用的是版别android-ndk-r20b,挑选对应版别的下载就行。 留意:ndk18及以下用的是gcc编译的,ndk19及以上是用clang编译的,版别不相同编译脚本是不相同的。

下载x264

在根目录进入要下载到目录,我的是usr/ffmpeg/

下载x264源码(条件是现已安装git并存在环境变量)

git clone https://code.videolan.org/videolan/x264.git

下载完进入x264目录:

cd x264

修正x264源码,不然之后编译的时分会报错。

在x264目录进入common文件夹,找到cpu.c文件并修正:

cd common
ls

音视频大合集最终篇;学废了

修正代码cpu.c的442行:改为1,不然在编译时获取cpu数量会报错;

音视频大合集最终篇;学废了

配置文件

留意:是在x264目录下新建shell脚本文件:build_android.sh

vim build_android.sh

按“i”进入修正形式,将以下脚本内容粘贴在build_android.sh中

#!/bin/bash
# 修正为自己的NDK的解压途径
NDK=/usr/ffmpeg/android-ndk-r20b
export TOOLCHAIN=$NDK/toolchains/llvm/prebuilt/linux-x86_64
export API=21
function build
{
  ./configure \
    --prefix=$PREFIX \
    --disable-cli \
    --disable-static \
    --disable-asm \
    --enable-shared \
    --enable-pic \
    --host=$HOST \
    --cross-prefix=$CROSS_PREFIX \
    --sysroot=$SYSROOT \
    --extra-cflags="-Os -fpic $OPTIMIZE_CFLAGS" \
        make clean
        make 
        make install
}
CPU=armv8-a
HOST=aarch64-linux-android
export CC=$TOOLCHAIN/bin/aarch64-linux-android$API-clang
export CXX=$TOOLCHAIN/bin/aarch64-linux-android$API-clang++
SYSROOT=$NDK/toolchains/llvm/prebuilt/linux-x86_64/sysroot
export CROSS_PREFIX=$TOOLCHAIN/bin/aarch64-linux-android-
PREFIX=$(pwd)/android/$CPU
OPTIMIZE_CFLAGS="-march=$CPU"
build
CPU=armv7-a
HOST=armv7a-linux-android
export CC=$TOOLCHAIN/bin/armv7a-linux-androideabi$API-clang
export CXX=$TOOLCHAIN/bin/armv7a-linux-androideabi$API-clang++
SYSROOT=$NDK/toolchains/llvm/prebuilt/linux-x86_64/sysroot
export CROSS_PREFIX=$TOOLCHAIN/bin/arm-linux-androideabi-
PREFIX=$(pwd)/android/$CPU
OPTIMIZE_CFLAGS="-mfloat-abi=softfp -mfpu=vfp -marm -march=$CPU"
build
CPU=x86-64
HOST=x86_64-linux-android
export CC=$TOOLCHAIN/bin/x86_64-linux-android$API-clang
export CXX=$TOOLCHAIN/bin/x86_64-linux-android$API-clang++
SYSROOT=$NDK/toolchains/llvm/prebuilt/linux-x86_64/sysroot
export CROSS_PREFIX=$TOOLCHAIN/bin/x86_64-linux-android-
PREFIX=$(pwd)/android/$CPU
OPTIMIZE_CFLAGS="-march=$CPU -msse4.2 -mpopcnt -m64 -mtune=intel"
build

留意:记住修正自己的NDK途径

保存并退出:按esc退出修正形式,输入“:wq” 保存退出,给build_android.sh添加履行权限:

chmod +x build_android.sh

至此配置完结。

编译so文件

履行命令:

./build_android.sh

编译完结后会在faac-1.29.9.2下生成android文件夹,里面有三个渠道的so库。

音视频大合集最终篇;学废了

将对应cpu的so和头文件拷贝到项目中,就能够愉快运用了,留意运用.so结束的,不要运用.164版别号结束的;

音视频大合集最终篇;学废了

三丶faac和NDK在Centos7上穿插编译

目标

运用Centos 7编译出Android运用的faac的so库和头文件

下载faac

在根目录进入要下载到目录,我的是usr/ffmpeg/

cd usr/ffmpeg

下载

wget --no-check-certificate 'https://nchc.dl.sourceforge.net/project/faac/faac-src/faac-1.29/faac-1.29.9.2.tar.gz'

解压:

tar xvf faac-1.29.9.2.tar.gz

进入facc目录:

cd faac-1.29.9.2

配置文件

新建shell脚本文件:build_android.sh

vim build_android.sh

按“i”进入修正形式,将以下脚本内容粘贴在build_android.sh中

#!/bin/bash
# 修正为自己的NDK的解压途径
NDK=/usr/ffmpeg/android-ndk-r20b
# macOS需求修正linux-x86_64为arch什么的,linux-x86_64是centos上用的
TOOLCHAIN=$NDK/toolchains/llvm/prebuilt/linux-x86_64
API=21
function build_android
{
echo "Compiling faac for $CPU"
./configure \
--prefix=$PREFIX \
--with-pic=yes \
--host=$HOST \
--enable-shared=yes \
--enable-static=no  \
--with-sysroot=$SYSROOT
make clean
make -j8
make install
echo "The Compilation of faac for $CPU is completed"
}
#armv8-a
CPU=armv8-a
HOST=aarch64-linux-android
export CC=$TOOLCHAIN/bin/aarch64-linux-android$API-clang
export CXX=$TOOLCHAIN/bin/aarch64-linux-android$API-clang++
export CFLAGS="-march=$CPU"
SYSROOT=$NDK/toolchains/llvm/prebuilt/linux-x86_64/sysroot
PREFIX=$(pwd)/android/$CPU
build_android
#armv7-a
CPU=armv7-a
HOST=arm-linux-androideabi
export CC=$TOOLCHAIN/bin/armv7a-linux-androideabi$API-clang
export CXX=$TOOLCHAIN/bin/armv7a-linux-androideabi$API-clang++
export CFLAGS="-mfloat-abi=softfp -mfpu=vfp -marm -march=$CPU"
SYSROOT=$NDK/toolchains/llvm/prebuilt/linux-x86_64/sysroot
PREFIX=$(pwd)/android/$CPU
build_android
#x86
# CPU=x86
# HOST=i686-linux-android
# export CC=$TOOLCHAIN/bin/i686-linux-android$API-clang
# export CXX=$TOOLCHAIN/bin/i686-linux-android$API-clang++
# SYSROOT=$NDK/toolchains/llvm/prebuilt/linux-x86_64/sysroot
# PREFIX=$(pwd)/android/$CPU
# export CFLAGS="-march=i686 -mtune=intel -mssse3 -mfpmath=sse -m32"
# build_android
#x86_64
CPU=x86-64
HOST=x86_64-linux-android
export CC=$TOOLCHAIN/bin/x86_64-linux-android$API-clang
export CXX=$TOOLCHAIN/bin/x86_64-linux-android$API-clang++
export CFLAGS="-march=$CPU -msse4.2 -mpopcnt -m64 -mtune=intel"
SYSROOT=$NDK/toolchains/llvm/prebuilt/linux-x86_64/sysroot
PREFIX=$(pwd)/android/$CPU
build_android

留意:记住修正自己的NDK途径

保存并退出:按esc退出修正形式,输入“:wq” 保存退出,给build_android.sh添加履行权限:

chmod +x build_android.sh

至此配置完结。

编译so文件

履行命令:

./build_android.sh

编译进程比较快的,上边配置文件编译3个渠道,大约30秒左右。

编译完结后会在faac-1.29.9.2下生成android文件夹,里面有三个渠道的so库。

音视频大合集最终篇;学废了

四丶Webrtc音视频通话

音视频通话难点:

  1. 音视频编解码原理
  2. IP4中,设备在各自的内网,需求p2p打洞
  3. 音频降噪和回声消除

信号服务器:

  1. 设备衔接的socket服务器
  2. 传递各个设备之间的信息:传递各个节点的sdp信息,传递ice信息
  3. 包括事务功能:如加入、脱离房间等

打洞服务器:

为什么打洞:IP4中,设备在各自的内网,各自的内网不能通讯,而想要通讯,就需求打破内网约束;

假如用服务器中转,则会加大服务器开支和添加延时;若不用中转,就需求点对点(p2p)打洞,来完结通讯;

NAT:

  1. 网络地址转化
  2. 设备若想链接公网,需求经过路由转化,将私有IP转化为公网IP
  3. 在设备和路由中存在IP端口映射表NAPT

如:

1.设备A的某个使用私有IP端口为:192.168.1.10:9000; 2.设备A衔接的路由器L的公网IP为:200.180.190.11; 3.那么在路由器L中会有一个端口映射设备A: 200.180.190.11:21111; 4.200.180.190.11:21111便是设备A的某个使用的公网IP地址和端口的映射;

**SDP:**描绘了客服端到服务端通讯的各个网络地址及端口等信息;

ps:一段文本,就像一个列表,记载了客户端到服务端,中转次数及各个中转点的路由信息;

两个设备完结通讯要求:

设备A、设备A的路由AL、设备B、设备B的路由BL;

设备A若想给设备B发音讯,AL需求知道B在BL中的IP和端口映射;

同理,设备B若想给设备A发音讯,BL需求知道A在AL中的IP和端口映射;

打洞流程: 人物:信令服务器、打洞服务器、设备A、设备A的路由AL、设备B、设备B的路由BL;

  1. 经过信令服务器(socket服务器)将设备A到打洞服务器的各个sdp发送给设备B;
  2. 经过信令服务器(socket服务器)将设备B到打洞服务器的各个sdp发送给设备A;
  3. 设备A尝试发送一条音讯到设备B,这条音讯是发送不过去的;由于BL里没有A和AL的映射IP和端口;
  4. 可是此刻AL会在自己的NAPT表中记载B和BL的映射IP和端口;
  5. 设备B发送一条音讯给设备A,这条音讯时能够发送到的。由于AL的NAPT表中有B和BL的映射IP和端口;而且BL会在自己的NAPT表中记载A和AL的映射IP和端口;
  6. 此刻A和B就能够直接互相发送音讯了,不再需求服务器了;

音视频大合集最终篇;学废了

整个进程便是序号1->2->3->4->5->6->7->8>9 进程一:1->2 此进程为用户B向服务器恳求向用户A打洞 进程二:3->4 此进程为服务器相使用户B的打洞恳求,告知用户A用户B想与你打洞(数据包中包括用户B的地址信息)。 进程三:5->6 用户A主动发一条信息给用户B,意图是为了使得路由器A中能够有一条关于路由B的IP的路由信息(留意不是用户B,用户B是私有IP),就如图所示,这条信息会被丢弃的,由于路由B的路由表中没有路由A的IP的信息。 进程四:7->8->9 用户B再发一条信息给用户A,由于此刻路由A的路由表中有关于路由B的IP的路由信息,此刻路由A就能路由给用户A了,至此,用户A就能直接纳到用户B发的信息了。留意,此刻用户A发给用户B不需求打洞,由于路由B中现已有关于路由A的IP的路由信息了。

Webrtc事务流程:

音视频1对1通话、多对多会议都是依据房间进行;

人物:信令服务器S、打洞服务器T、设备A(被恳求)、设备A的路由AL、设备B(主恳求)、设备B的路由BL;

榜首种状况:

设备A进入房间时,没有其他设备;

  1. 设备A进入房间,信令服务器S给设备A回来设备A的仅有标识符socketId;
  2. 设备A敞开本地预览:设置视频源、音频源、烘托到surface;
  3. 等候获取其他设备发送的恳求offer…
  4. 预备sdp交流
  5. 设备A收到信令服务器S发送来的设备B的socketId和sdp;
  6. 设备A恳求信令服务器,信令服务器回来设备A到打洞服务器的网络节点各个sdp
  7. 设备A设置本地sdp、设置收到的远端sdp;
  8. 设备A运用信令服务器S经过收到的socketId将自己的sdp发送给其他设备B;sdp交流完结
  9. 开端打洞:ICE交流
  10. 设备A经过异步音讯取得打洞服务器回来的自己的ICE信息;
  11. 设备A经过信令服务器S将ICE信息发送给设备B;
  12. 等候设备B衔接;
  13. ICE交流完结后
  14. 获取远端设备B的视频流、音频流,进行解码播映;

第二种状况:

设备B进入房间时,已有其他设备,如:设备A…;

此刻设备B需求主动去呼叫设备A;

  1. 设备B衔接信令服务器S;
  2. 设备B进入房间,信令服务器S给设备B回来设备B的仅有标识符socketId,和其他存在的设备的socketId列表;
  3. 设备B敞开本地预览:设置视频源、音频源、烘托到surface;
  4. 开端sdp交流
  5. 设备B恳求打洞服务器T,获取设备B到打洞服务器T的网络节点的各个sdp
  6. 设备B设置自己的sdp;
  7. 设备B运用信令服务器S经过socketId列表将自己的sdp发送给其他设备A;
  8. 设备A收到sdp后,设备A运用信令服务器S经过设备B的socketId,将自己的sdp发送给其他设备B;
  9. 设备B设置收到的远端sdp(或许有多个);sdp交流完结
  10. 开端打洞:ICE交流
  11. 设备A经过异步音讯取得打洞服务器回来的自己的ICE信息;
  12. 设备A经过信令服务器S将ICE信息发送给设备B;
  13. 设备B依据收到的ICE信息去发送一个恳求;此刻设备B链接的路由器BL里就有了设备A在路由AL的IP和端口映射信息;ICE交流完结
  14. 设备B链接其他设备的视频流、音频流,进行解码播映;

至此,关于音视频就根本介绍略微,还有其他的关于openGl ES使用篇,和根底篇的放在独自的openGL ES系列文档里,稍后再说

重视大众号:Android苦做舟 解锁 《Android十二大板块PDF》
音视频大合集,从初中高到面试包罗万象;让学习更靠近未来实战。已形成PDF版

十二个模块PDF内容如下

1.2022最新Android11位大厂面试专题,128道附答案
2.音视频大合集,从初中高到面试包罗万象
3.Android车载使用大合集,从零开端一同学
4.功能优化大合集,告别优化烦恼
5.Framework大合集,从里到外剖析的明明白白
6.Flutter大合集,进阶Flutter高档工程师
7.compose大合集,拥抱新技能
8.Jetpack大合集,全家桶一次吃个够
9.架构大合集,轻松应对作业需求
10.Android根底篇大合集,根基安定高楼平地起
11.Flutter番外篇:Flutter面试+项目实战+电子书
12.大厂高档Android组件化强化实战

整理不易,重视一下吧,ღ( ・ᴗ・` )