直播基本介绍

来源:

  1. 最近市面上很火爆的17、花椒、虎牙直播、periscope的直播功能,是自研还是第三方直播SDK服务?

  2. 如何快速的开发一个完整的iOS直播app】(原理篇)

  3. 【iOS开发】关于视频直播技术,你想要知道的都在这里了(二)处理

如何快速搭建一个完整的手机直播系统

搭建一个完整的手机直播都包含哪些必须的环节:推流端(采集、前处理、编码、推流),服务端处理(转码、录制、截图、鉴黄),播放器(拉流、解码、渲染)、互动系统(聊天室、礼物系统、赞)。

304825-5481594e6e2a9d56.png
304825-54974199408c0cc1.png

手机直播推流端需要做哪些工作?

直播推流端即主播端,主要通过手机摄像头采集视频数据和麦克风采集音频数据,经过一系列前处理、编码、封装,然后推流到CDN进行分发。

采集

手机直播SDK通过手机摄像头和麦克风直接采集视频数据和音频数据。其中,视频采样数据一般采用RGB或YUV格式、音频采样数据一般采用PCM格式。对于采集到的原始音视频的体积是非常大的,因此需要经过压缩技术来处理,降低视频的大小来提示传输效率。 在手机视频采集方面,iOS系统在硬件的兼容性方面做得比较好,系统本身提供了比较完整的视频采集的接口,使用起来也比较简单。但是,Android系统就比较麻烦了,千奇百怪的机型都有,适配起来非常难。我们在初期做了一项调研,发现Android的适配率还不到50%。

前处理

在这个环节主要处理美颜、水印、模糊等效果。特别是美颜功能几乎是直播的标配功能,没有美颜的直播主播们根本提不起兴趣。我们见过太多case是因为没有美颜功能被抛弃使用的。另外国家明确提出了,所有直播都必须打有水印并回放留存15天以上。所以,在选择直播SDK时,没有美颜和水印功能基本就可以选择放弃了。美颜实际上是通过算法去识别图像中的皮肤部分,再对皮肤区域进行色值调整。通常情况下人的肤色与周边环境色调存在较大差异,通过颜色对比,找到皮肤的基本轮廓,进一步进行肤色检查还可以确定人脸范围。找到了皮肤的区域,可以进行色值调整、添加白色图层或调整透明度等来等来达到美白效果。美颜除了美白效果还需要磨皮功能,磨皮实际上就是用模糊滤镜实现的。滤镜有很多种,如高斯滤波,双边滤波,导向滤波,到底选择什么样的模糊滤镜各家也有自己的喜好。在美颜处理方面,最著名的GPUImage提供了丰富的效果,同时可以支持IOS和Android,还支持自己写算法实现自己最理性的效果。GPUImage本事内置了120多种常见滤镜效果,添加滤镜只需要简单调用几行代码就可以了,比如大家可以试试使用GPUImageBilateralFiter的双边滤波滤镜来处理基本的磨皮效果,想要实现更理想的效果还是要通过自定义算法去实现的,各家也都有自己一套算法。

编码

为了便于手机视频的推流、拉流以及存储,通常采用视频编码压缩技术来减少视频的体积。现在比较常用的视频编码是H.264,但具有更高性能的H.265编码技术正在飞速发展,并可能很快成为主流;在音频方面,通比较常用的是用AAC编码格式进行压缩,其它如MP3、WMA也是可选方案。视频经过编码压缩大大提高了视频的存储和传输效率,当然,经过压缩后的视频在播放时必须进行解码。通俗点讲就是编码器将多张图像进行编码后产生一段段GOP(Group of Pictures),播放时解码器读取一段段GOP进行解码后读取图像并进行渲染显示。 在编码方面的核心是在分辨率、码率、帧率等参数中找到最佳平衡点,达到体积最小画面最优的效果,这些参数各家也都有自己的一套核心参数。2012年8月,爱立信公司推出了首款H.265编解码器,六个月后,国际电联(ITU)就正式批准通过了HEVC/H.265标准,称之为高效视频编码(High Efficiency Video Coding),相较于之前的H.264标准有了相当大的改善,做到了仅需要原来一半带宽即可播放相同质量的视频,低于1.5Mbps的网络也能传输1080p的高清视频。国内,如阿里云、金山云都在推自己的H.265编解码技术,随着直播的快速发展和对带宽的依赖,H.265编解码技术已有全面取代H.264的趋势。当然,全面推开应用还需要些时间。另外,硬件编码已经成为手机直播的首选方案,软编码处理在720p以上的视频颓势非常明显。在IOS平台上硬件编码的兼容性比较好,可以直接采用,但在 Android 平台上,Android的MediaCodec 编码器,针对不同的芯片平台表现差异还是非常大的,要完全实现全平台兼容的成本还是非常高的。

推流

要想用于推流还必须把音视频数据使用传输协议进行封装,变成流数据。常用的流传输协议有RTSP、RTMP、HLS等,使用RTMP传输的延时通常在1–3秒,对于手机直播这种实时性要求非常高的场景,RTMP也成为手机直播中最常用的流传输协议。最后通过一定的Qos算法将音视频流数据推送到网络断,通过CDN进行分发。 在直播场景中,网络不稳定是非常常见的,这时就需要Qos来保证网络不稳情况下的用户观看直播的体验,通常是通过主播端和播放端设置缓存,让码率均匀。另外,针对实时变化的网络状况,动态码率和帧率也是最常用的策略。当然,在网络传输方面全部自己来做基本不现实,找提供推流服务的CDN服务商提供解决方案是最好的选择,可参考文章开头介绍的云视频服务商。据了解,阿里云是国内唯一能自研CDN缓存服务器的厂商,性能还是非常有保障的。通常,大多数直播平台都会同时接入多个视频云服务提供商,这样可以做拉流线路互备,对推流后视频集群再进行优化也可提高直播的流畅性和稳定性。

服务端处理需要做哪些工作?

要想适配各终端和平台,服务端还需要对流进行转码,如支持RTMP、HLS、FLV等格式拉流,支持一路转多路适配不同网络和分辨率的终端设备。另外,像现在必备的鉴黄功能也需要服务端完成。

截图、录制、水印

像阿里云、金山云、UCloud等云服务商都提供了实时转码技术将用户推流码率较高(比如720P)实时转化成较低清晰度(比如360P)的流以适应播放端的需求。如果要自己搭建实时转码系统,这个成本是极高的。一台8核设备只能实时转10 路流,如果一个正常的直播平台有1000路流,那至少就需要100台设备,加上后期的运维成本,一般公司就吃不消了。实时截图功能和实时转码类似,只是一般单机可以处理100路流。市面上云服务提供商基本上都提供了服务端转码、截图、录制功能,建议选择好的云服务提供商即可,可以节约大量成本。

鉴黄

2016年,4月14日上午10时,文化部公布了一则消息,斗鱼、虎牙、YY、熊猫TV、战旗TV、龙珠直播、六间房、9158等网络直播平台因涉嫌提供含宣扬淫秽、暴力、教唆犯罪等内容的互联网文化产品,被列入查处名单。文化部已部署相关执法机构查处涉案企业,将及时公布处罚结果。在前期的野蛮生长后,国家介入管制一定程度上遏制了直播的发展速度,但更有利于直播行业打造健康的生态,进入良性发展。这也意味着直播行业鉴黄成了必须环节,使用技术手段去鉴黄是手机直播平台必然采用的方案。市面上提供鉴黄服务的方案主要有两种,第一种是对视频进行截图,然后对图片进行鉴黄,返回鉴黄结果和分值。典型的企业有阿里(绿网)、图谱科技,他们目前都支持直接传入视频,经过服务端分析返回结果,鉴黄的结果分为色情、疑似色情、正常或性感,并对每种结果进行打分。通常由业务系统接入鉴黄服务,根据鉴黄结果对直播流进行控制,如切断直播流、禁用用户的账号等。第二种是和CDN结合,直接对直播流进行分析,识别结果也分为色情、疑似色情、性感和正常,业务系统根据识别结果直接控制直播流。典型的企业是Viscovery,这套方案的优点是实时性保证比较好,缺点是必须部署到CDN或自己的机房,使用成本相对高一些。趣拍微视频云服务作为一站式直播解决方案提供商,我们的主旨是让用户以最短时间、最小成本接入直播服务。因此,用户只需在控制台对鉴黄服务进行配置就可以针对每个应用,每一路直播流进行实时审核,审核内容包括色情、暴恐、时政敏感等。在控制台中,趣拍微视频服务实时将鉴黄结果返回,用户可以直接查看色情直播和违规界面的截图,同时可以对直播流进行控制,切断问题直播流。我们提供了短信、邮件和站内信提供功能,避免漏洞一个非法视频,给平台造成损失。数据统计功能让用户可以把握平台最新的动态信息,为进一步采取必要的措施提供可靠的依据。同时,为了满足用户定制化需求,我们还提供了丰富的接口,可以很方便的将鉴黄服务接入到自己的业务系统。

播放器端需要做哪些工作?

在播放器端如何做到秒开,在直播过程中保证画面和声音清晰度的同时,稳定、流程、无卡顿的直播流量,这些工作都需要播放器端配合服务端来做优化,做到精确调度。

拉流

拉流实际是推流的逆过程。首先通过播放端获取码流,标准的拉流格式有RTMP、HLS、FLV等。RTMP是Adobe的专利协议,开源软件和开源库都支持的比较好,如开源的librtmp库,播放端只要支持flashPlayer的就能非常简单的播放RTMP直播,直播延迟一般在1–3秒。HLS是苹果提出的基于HTTP的流媒体传输协议,HTML5可以直接打开播放,通过微信、QQ等软件分享出去,用户也可以直接观看直播,可以说手机直播app,HLS拉流协议是必须支持的,缺点是延迟通常大于10秒。FLV(HTTP-FLV)协议是使用HTTP协议传输流媒体内容的一个协议,也不用担心被Adobe的专利绑架,直播延迟同样可以做到1–3秒。趣拍微视频云服务的直播拉流提供了RTMP、HLS、FLV三种格式,满足不同业务场景的需求,如对即时性要求较高或有互动需求的可以采用RTMP或FLV格式进行直播拉流播放;对于有回放或跨平台需求的,推荐使用HLS。当然,三种协议是可以同时使用的,分别用到自己的场景就可以了。

解码和渲染

拉流获取封装的视频数据后,必须通过解码器解码、渲染后才能在播放器上播放。它是编码的逆过程,是指从音视频的数据中提取原始数据。前面介绍的H.264和H.265编码格式都是有损压缩,所以在提取后的原始数据,并非原始采样数据,存在一定的信息丢失。因此,在视频体积最小的情况下通过各种编码参数保留最好的原始画面,成为了各视频公司的核心机密。考虑对高清的支持,解码肯定还是要选择硬解码的。前面介绍过,IOS系统由于硬件比较单一、比较封闭,支持的比较好,Android系统由于平台差异非常大,编解码要完全兼容各平台还需要很多工作要做。渲染最大的难点不在与画面绘制,而在于画音同步,业内大部分直播平台在这块做的都还是不够的。我们在这方面积累了一些经验和大家分享。

手机直播中的交互系统

手机直播中最常见的交互有聊天室(弹幕)、点赞、打赏和礼物等,有些比较有特色的手机直播平台也加入了和主播互动的游戏功能。交互系统涉及消息的实时性和互动性,在技术实现上大多是使用IM的功能来实现的,对服务器的压力也是比较大。 对于在线人数比较多的房间,弹幕消息量是非常大,主播与用户其实都看不过来,为了缓解服务器压力,在产品策略可以做一些必要的优化,比如对于发送消息的频率进行限制或对每条消息发送对象的上限进行限制等。

礼物系统

礼物系统已是绝大多数手机直播平台的标配了,它是这些平台主要的收入来源。在手机直播平台上我们常常可以见到土豪秒榜、土豪对刷的情景,据报道,明星直播一场礼物收入几十万也是常有的事,一年千万收入的网红也不少,可见国内有礼物消费习惯的土豪还不少。另一方面,送礼物的形式增强了用户和主播之间的互动交流,也是主播依赖平台的最主要原因。礼物的收发在技术实现上也是用聊天室接口做的,通常采用IM中的自定义消息实现,当用户收到或发送礼物时将自定义消息对应的礼物图形渲染出来。另外,面对大量用户刷礼物时,礼物系统对一致性要求就比较高了,所以在实现上存一份数据建多条索引是一种很好的选择,也可以降低对事务的依赖。

连麦

311249-169fadb22723043a.gif

连麦是互动直播中常见的需求,其流程如上图所示。主播和部分观众之间可以进行实时互动,然后将互动结果实时播放给其他观众观看。

基于以上业务需求,我们很容易想到基于单向直播原理,在主播端和连麦观众端进行双向推流和双向播流的方式互动,然后在服务端将两路推流合成一路推送给其他观众。但 RTMP 带来的延迟决定了这种方式无法做到用户可接受的互动直播。

实际上,互动直播的主要技术难点在于:
1)低延迟互动:保证主播和互动观众之间能够实时互动,两者之间就像电话沟通,因此必须保证两者能在秒级以内听到对方的声音,看到对方的视频;

2)音画同步:互动直播中对音画同步的需求和单向直播中类似,只不过互动直播中的延迟要求更高,必须保证在音视频秒级传输情况下的秒级同步。

3)音视频实时合成:其他观众需要实时观看到对话结果,因此需要在客户端或者服务端将画面和声音实时合成,然后以低成本高品质的方式传输观众端。

在视频和电话会议领域,目前比较成熟的方案是使用思科或者 WebEx 的方案,但这些商用的方案一不开源,二比较封闭,三成本比较高。对于互动人数比较少的互动直播,目前市场上比较成熟的方案是使用基于 WebRTC 的实时通讯方案。

311249-9ec992a91adab59d.png

上图是一个基于 WebRTC 协议实现多方实时通讯的示意图,本地用户(主播)和远程用户(连麦观众)之间的连接通过 RTCPeerConnection API 管理,这个 API 包装了底层流管理和信令控制相关的细节。基于该方案可以轻松实现多人(14 人以下)的多方实时通信,如下图所示:

311249-5d539479272c6111.png

当然,在通信人数少的情况下,其复杂度相对简单,如 2 人情况下。但人数增多至 4 人之后,其可选的网络结构就增多了,如上图所示,可以每个点之间形成自组织网络的方式通信,也可以以 1 人为中心形成星型通信网络,还可以让大家都通过一个集中式的服务端进行通信。

几个概念

GOP:(Group of Pictures)画面组,一个GOP就是一组连续的画面,每个画面都是一帧,一个GOP就是很多帧的集合

  • 直播的数据,其实是一组图片,包括I帧、P帧、B帧,当用户第一次观看的时候,会寻找I帧,而播放器会到服务器寻找到最近的I帧反馈给用户。因此,GOP Cache增加了端到端延迟,因为它必须要拿到最近的I帧
  • GOP Cache的长度越长,画面质量越好

码率:图片进行压缩后每秒显示的数据量。

帧率:每秒显示的图片数。影响画面流畅度,与画面流畅度成正比:帧率越大,画面越流畅;帧率越小,画面越有跳动感。

  • 由于人类眼睛的特殊生理结构,如果所看画面之帧率高于16的时候,就会认为是连贯的,此现象称之为视觉暂留。并且当帧速达到一定数值后,再增长的话,人眼也不容易察觉到有明显的流畅度提升了。

分辨率:(矩形)图片的长度和宽度,即图片的尺寸

压缩前的每秒数据量:帧率X分辨率(单位应该是若干个字节)

`压缩比':压缩前的每秒数据量/码率 (对于同一个视频源并采用同一种视频编码算法,则:压缩比越高,画面质量越差。)

视频处理框架

GPUImage:GPUImage是一个基于OpenGL ES的一个强大的图像/视频处理框架,封装好了各种滤镜同时也可以编写自定义的滤镜,其本身内置了多达120多种常见的滤镜效果。

OpenGL:OpenGL(全写Open Graphics Library)是个定义了一个跨编程语言、跨平台的编程接口的规格,它用于三维图象(二维的亦可)。OpenGL是个专业的图形程序接口,是一个功能强大,调用方便的底层图形库。
OpenGL ES:OpenGL ES (OpenGL for Embedded Systems) 是 OpenGL三维图形 API 的子集,针对手机、PDA和游戏主机等嵌入式设备而设计。

视频编码框架

FFmpeg:是一个跨平台的开源视频框架,能实现如视频编码,解码,转码,串流,播放等丰富的功能。其支持的视频格式以及播放协议非常丰富,几乎包含了所有音视频编解码、封装格式以及播放协议。
X264:把视频原数据YUV编码压缩成H.264格式
VideoToolbox:苹果自带的视频硬解码和硬编码API,但是在iOS8之后才开放。
AudioToolbox:苹果自带的音频硬解码和硬编码API

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 151,829评论 1 331
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 64,603评论 1 273
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 101,846评论 0 226
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 42,600评论 0 191
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 50,780评论 3 272
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 39,695评论 1 192
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,136评论 2 293
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 29,862评论 0 182
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 33,453评论 0 229
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 29,942评论 2 233
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 31,347评论 1 242
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 27,790评论 2 236
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 32,293评论 3 221
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 25,839评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,448评论 0 181
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 34,564评论 2 249
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 34,623评论 2 249

推荐阅读更多精彩内容