音视频知识2

视频在我们生活中应用越来越广了,不可避免的,我们在使用视频时,会遇到一些最常见的专业术语:视频编码格式、视频码率、视频帧率、视频分辨率,这些专业术语在一个视频文件中,到底是指的什么呢?听阿酷来说说吧。

编码格式:一个视频文件本身,通常由音频和视频两部分组成。例如上图的视频文件,就是由avc视频编码+AAC音频编码组成的,常见的视频编码格式有Xvid,AVC/H.264,MPEG1,MPEG2等,常见的音频编码有MP3、AAC等。

视频码率:是指视频文件在单位时间内使用的数据流量,也叫码流率。码率越大,说明单位时间内取样率越大,数据流精度就越高,这样表现出来的的效果就是:视频画面更清晰画质更高。

视频帧率:通常说一个视频的25帧,指的就是这个视频帧率,即1秒中会显示25帧;视频帧率影响的是画面流畅感,也就是说视频帧率超高,表现出来的效果就是:画面越显得流畅。你也可以这样理解,假设1秒只显1帧,那么一段视频看起来,就是有很明显的卡顿感,不流畅不连惯。当然视频帧率越高,意味着画面越多,也就相应的,这个视频文件的大小也会随之增加,占用存储空间也就增大了。

视频分辨率:分辨率就是我们常说的600x400分辨率、1920x1080分辨率,分辨率影响视频图像的大小,与视频图像大小成正比:视频分辨率越高,图像越大,对应的视频文件本身大小也会越大。

GOP(Group of picture)

关键帧的周期,也就是两个IDR帧之间的距离,一个帧组的最大帧数,一般而言,每一秒视频至少需要使用 1个关键帧。增加关键帧个数可改善质量,但是同时增加带宽和网络负载。

需要说明的是,通过提高GOP值来提高图像质量是有限度的,在遇到场景切换的情况时,H.264编码器会自动强制插入一个I帧,此时实际的GOP值被缩短了。另一方面,在一个GOP中,P、B帧是由I帧预测得到的,当I帧的图像质量比较差时,会影响到一个GOP中后续P、B帧的图像质量,直到下一个GOP开始才有可能得以恢复,所以GOP值也不宜设置过大。

同时,由于P、B帧的复杂度大于I帧,所以过多的P、B帧会影响编码效率,使编码效率降低。另外,过长的GOP还会影响Seek操作的响应速度,由于P、B帧是由前面的I或P帧预测得到的,所以Seek操作需要直接定位,解码某一个P或B帧时,需要先解码得到本GOP内的I帧及之前的N个预测帧才可以,GOP值越长,需要解码的预测帧就越多,seek响应的时间也越长。

上述这些延迟无法避免,而直播协议的选择对直播迟延影响比较大。目前国内比较常见的三种直播协议

RTMP、HLS、HTTP-FLV,下面来简单介绍下。RTMP 是专为流媒体开发的协议,对底层的优化比其它协议更加优秀,同时它 Adobe Flash支持好,基本上所有的编码器(摄像头之类)都支持 RTMP 输出。现在 PC 市场巨大,PC 主要是 Windows,Windows 的浏览器基本上都支持Flash。另外 RTMP 适合长时间播放,曾经有过测试,连续 100 万秒,即 10 天多连续播放没有出现问题。最后 RTMP 的延迟相对较低,一般延时在1-3s 之间,一般的视频会议,互动式直播,完全是够用的。当然 RTMP并没有尽善尽美,它也有不足的地方。一方面是它是基于 TCP 传输,非公共端口,可能会被防火墙阻拦;另一方面,也是比较坑的一方面是 RTMP 为 Adobe私有协议,很多设备无法播放,特别是在 iOS 端,需要使用第三方解码器才能播放。

HLS 是由苹果公司提出的基于HTTP 的流媒体网络传输协议。是苹果公司 QuickTime X 和 iPhone 软件系统的一部分。主要应用于 iOS 设备,包含(iPhone,iPad, iPod touch) 以及 Mac OSX 提供音视频直播服务和录制内容(点播)等服务。它的工作原理是把整个流分成一个个小的基于 HTTP的文件来下载,每次只下载一些。当媒体流正在播放时,客户端可以选择从许多不同的备用源中以不同的速率下载同样的资源,允许流媒体会话适应不同的数据速率。可以通过CDN 进行网络分发。而 HLS的劣势也非常明显,首先 HLS 实时性差,延迟高,HLS 的延迟基本在 10s+ 以上。另外由于 HLS 请求的并不是完整的数据流,导致它产生文件碎片多。ts切片较小,会造成海量小文件,对存储和缓存都有一定的挑战。

FLV是一种在网络上传输的流媒体数据存储容器格式。而我们所说的HTTP-FLV 即将流媒体数据封装成 FLV 格式,然后通过 HTTP 协议传输给客户端。HTTP-FLV 能够好的穿透防火墙,它是基于 HTTP/80传输,有效避免被防火墙拦截。另外,它可以通过 HTTP 302 跳转灵活调度/负载均衡,支持使用 HTTPS 加密传输,也能够兼容支持 Android,iOS的移动端。FLV 也有一个缺点,由于它的传输特性,会让流媒体资源缓存在本地客户端,在保密性方面不够好。

RTMP:其原理是将大块的视频帧和音频帧“剁碎”,然后以小数据包的形式进行传输,且支持加密,因此隐私性相对比较理想,但由于拆包组包的过程较复杂,所以在海量并发时也容易出现一些不可预期的稳定性问题。

HLS:苹果推出的流媒体协议,将视频分成5-10秒的视频小分片,然后用m3u8索引表进行管理,由于客户端下载到的视频都是5-10秒的完整数据,故视频的流畅性很好。但一般播放器会在缓存3-4个分片后才启动播放,因此也引入了10-30s左右的延时。

HTTP-FLV:由Adobe公司主推,格式极其简单,只是在大块的视频帧和音视频头部加入一些标记头信息,在延迟表现和大规模并发方面都很成熟。但需要注意的是HTTP-FLV在手机浏览器上的支持非常有限。

因此,在降低延时方面,选择HTTP-FLV作为播放协议能有效地降低时延。但HLS对浏览器兼容比较友好,且支持跨终端,所以HLS也是很多用户的首选。




直播推流问题

1.检查域名状态

若域名处于“配置中”或“停用”状态都会导致推流失败,您可以通过以下步骤检查域名状态是否正常。

登录视频直播控制台,在左侧导航树中选择“域名管理”。

在域名列表中,检查域名状态是否为“正常”。

若状态为“停用”,请在“操作”列单击“启用”。

若状态为“配置中”,可能是由于域名还未生效、域名过期、账号涉黄涉赌等原因导致,请提交工单联系华为云技术客服协助处理。

2.检查CNAME是否生效

视频直播服务默认开启直播上行加速服务,即推流加速。若您的推流域名未配置CNAME解析,则将由于无法解析推流域名,从而导致推流失败。请您参照如下步骤,验证推流域名的CNAME是否配置成功。

3.检查推流地址是否正确

您需要根据是否配置了Key防盗链的情况来拼接对应的原始推流地址或鉴权推流地址。若开启了Key防盗链加密鉴权,则需要使用鉴权后的推流地址,否则,请使用原始推流地址进行推流。

请您对照推流地址拼接规则,确认当前的推流地址是否正确,若不正确,请使用正确的地址进行推流。

原始推流地址拼接规则如下:

rtmp://推流域名/AppName/StreamName

请您按照实际使用的AppName和StreamName拼接推流地址。

鉴权推流地址请参见推流鉴权进行拼接。

4.检查推流地址是否被占用

由于推流地址被占用导致推流失败的,建议您参照如下步骤进行确认并处理。

登录视频直播控制台,在左侧导航树中选择“直播管理 > 直播流管理”。

在下拉框中选择您的播放域名,若“在线流”页签显示该域名下正在推流的直播流信息,检查您使用的直播流名是否已被占用。

若您的推流地址被非法占用,请在“操作”列单击“禁推”,禁用后,该推流地址将无法进行直播推流。建议您再更换新的直播流名(StreamName)进行直播推流。

5.检查直播流是否被禁推

若直播推流地址已被加入禁推名单,则会导致推流失败,请您参照以下步骤恢复直播流的推送。

登录视频直播控制台,在左侧导航树中选择“直播管理 > 直播流管理”。

在下拉框中选择需要恢复直播流推送的域名。选择“禁推流”页签。在对应直播流行,单击“操作”列中的“恢复”。

直播播放端

检查播放地址是否正确

您需要根据是否配置了Key防盗链的情况来拼接对应的原始播放地址和鉴权播放地址。若开启了Key防盗链加密鉴权,则需要使用鉴权后的播放地址,否则,请使用原始播放地址进行播放。

请您对照播放地址拼接规则,确认当前的播放地址是否正确,若不正确,请使用正确的地址进行播放。

原始播放地址支持FLV、M3U8、RTMP三种格式,对应的拼接规则如下所示:

RTMP格式:rtmp://播放域名/AppName/StreamName

FLV格式:http://播放域名/AppName/StreamName.flv

M3U8格式:http://播放域名/AppName/StreamName.m3u8

请您按照实际使用的AppName和StreamName拼接播放地址。

若您的播放域名部署在新版视频直播服务下,则鉴权播放地址请参见Key防盗链(新版)进行拼接,否则,请参见Key防盗链(旧版)进行拼接。

说明:

播放地址中的AppName和StreamName必须与推流地址中的一致。

检查播放域名是否已关联推流域名

推流域名和播放域名添加后,需要进行域名的关联才能进行直播推流和播放。您可以参照如下方法排查播放域名和推流域名是否已关联。

登录视频直播控制台,在左侧导航树中选择“域名管理”。

在目标播放域名行右侧单击“管理”。

在“推流信息”区域,若已有对应的推流信息,则表示播放域名已关联推流域名。否则,您需要单击“关联推流域名”,选择目标推流域名,完成关联。

检查CNAME是否生效

由于视频直播服务默认开启直播下行加速服务,即播放加速,若您未配置CNAME解析,将由于无法解析播放域名,导致播放失败。请您参照如下方法,验证播放CNAME是否配置成功。

登录视频直播控制台,在左侧导航树中选择“域名管理”。

在域名列表中,获取播放域名的CNAME。

打开Windows操作系统中的cmd程序,通过nslookup加速域名的方式进行查询。

若回显的是系统分配的CNAME域名,则表示已配置CNAME。否则,您需要参考CNAME配置完成配置。

检查播放端

在第三方播放器中输入播放地址进行播放,检查播放器是否存在问题,建议可以使用VLC播放器检测。

检查播放设备是否存在问题,建议可以换一个手机和PC进行检测。

检查播放器是否支持对应的格式。

以下为华为云视频直播播放器对直播流格式的支持情况:

Web端播放器:支持的格式有M3U8和FLV。

移动端播放器:支持的格式有RTMP、FLV和M3U8。

若检查是播放器不支持导致,建议切换播放器播放。

直播播放卡顿

问题描述

直播推流成功后,在播放端播放直播视频时出现卡顿现象。直播的整个主流程涉及推流端、播放端和直播源站(CDN),因此每个阶段都可能会有因素导致视频播放卡顿,如图1所示。建议您参照如下方法初步排查直播视频卡顿的原因。

图1 直播主流程图

检查推流端

视频播放时出现卡顿,有一部分原因是由于直播推流时出现了卡顿影响了片源质量。其中,设备的配置、视频采集参数的设置、网络环境等因素都可能导致推流端出现卡顿。当推流端出现卡顿时,您可以参照如下几方面逐一排查问题。

设备配置

推流过程中会占用一定比例的CPU,硬件配置较差的低端设备,在推流过程中若整体CPU使用率超过80%以上,画面会出现不同程度的卡顿,花屏等现象,会影响到视频的采集,导致片源质量下降影响用户端的观看。您可以通过更换设备配置、系统版本等较高的设备,以保障推流端设备的稳定性尽量避免可能导致卡顿的因素产生。

例如,使用

视频云App推流时,可以在推流界面,单击页面右下角的

查看CPU使用率及总CPU使用率情况。


 查看CPU使用率

推流开发工具配置

由于编码端设置的码率、帧率以及编码档位过高,且受硬件条件限制,会导致编码速度变慢,无法达到流畅播放的帧率要求。因此对于推流设备的使用,iOS版的移动端建议您使用硬编码,因为iOS系统和硬件设备统一性高,而且省电。而Android版的移动端因为机型复杂,CPU类型众多,支持程度不一,推荐4.3及以上版本使用硬编码。若使用的华为云推流SDK是iOS版的,默认为硬编码,不需要设置;若使用的是Android版的,请参见

设置软硬编码进行配置。

视频采集参数配置

一般情况下,为保障视频的流畅度帧率会设置在每秒15帧以上,如果帧率低于每秒10帧,画面就会出现较明显的卡顿,如无特殊情况,尽量将视频帧率设置在每秒15-30帧之间。帧率超过每秒30帧后,人眼就无法识别出画面的效果,且帧率增加后视频传输的带宽成本也会上升,建议您合理设置视频的采集参数。

网络带宽大小

使用

在线带宽测试检查推流端的上行网络带宽情况 ,一般建议上行带宽最好稳定在10M以上。

系统资源占用

检查后台是否运行了大量的程序,建议删除和停止正在运行的程序,空出资源。

检查播放端

大部分播放器都有接收缓存的,缓存收满后,才进行解码显示,这部分接收缓存的大小也会影响播放的卡顿情况,建议通过调整接收缓存的大小,减少卡顿影响。

如果播放设备使用的是硬编码,在网络环境较差的情况下,为减少卡顿影响,可以实时改变硬编码率,即降低码率,进行丢帧处理,在丢帧的同时也可降低音频的码率。具体详情请参见直播播放器SDK

使用在线带宽测试检查播放端下行网络带宽情况,若播放端的带宽不够或发生抖动,会导致播放画面出现卡顿。同时,检查是否有下载数据占用网络带宽,建议在同一网络环境下,不要有大量的带宽占用行为出现,比如下载等。

检查直播源站(CDN)

若推流端和播放端排查结果均正常,请提交工单联系技术客服排查直播源站(CDN)是否存在问题,提交工单时,请附上配置的推流域名和播放域名。

OBS推流延时过长


使用推流工具进行推流操作时,需手动调节直播流延时时间,HLS的播放延时在10~35秒之间为正常范围。如您的延时已超过正常范围,请您参照以下步骤设置参数。

选择“输出 > 高级”。

将“关键帧间隔(秒,0=自动)”设置为“2”。


 OBS推流延时设置


域名配置后,针对不同的播放协议,对应的播放地址格式如下所示:

RTMP格式:rtmp://播放域名/AppName/StreamName

FLV格式:http://播放域名/AppName/StreamName.flv

M3U8格式:http://播放域名/AppName/StreamName.m3u8

若配置了转码模板,需要播放直播转码流,则在“StreamName”后加上“_转码模板ID”即可。

若配置了Key防盗链,则需要使用鉴权地址进行播放,在如上的原始播放地址后加上鉴权串即可。

鉴权播放地址:原始播放地址?auth_info=加密串.EncodedIV

具体播放地址的拼接方法请参见拼接播放地址

播放地址中StreamName表示直播流名称,每个AppName可以创建多个直播流,您可以根据实际情况进行自定义

,不支持中文字符。具体可以参见

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