视频技术详解:语音编解码技术演进和应用选型

    视频技术详解:语音编解码技术演进和应用选型 本文来自现网易云音乐音视频实验室负责人刘华平在LiveVideoStackCon 2017大会上的分享,并由LiveVideoStack整理而成。分享中刘华平以时间为主线,讲述了语音编解码技术的演进路线及实际应用中的技术选型。 文 / 刘华平 整理 / LiveVideoStack 大家好,我是刘华平,从毕业到现在我一直在从事音视频领域相关工作,也有一些自己的创业项目,曾为早期Google Android SDK多媒体架构的构建作出贡献。 就音频而言,无论是算法多样性,Codec种类还是音频编解码复杂程度都远远比视频要高。视频的Codec目前还主要是以宏块为处理单元,预测加变换的混合编码框架,例如H.264和H.265都是在这一框架下,另外在应用中,某一时间往往单的视频编码能主导,当前H.264就占据了90%以上的市场份额。,而音频则相当复杂,且不同的场景必须要选择不同的音频编解码器。以下就是本次为大家分享的主要内容,希望通过此次分享可以使大家对音频编解码有一个整体的认识,并在实际应用中有参考的依据。 语言/音频编码总表 上图展示的是语言/音频编码总表,可以看到其比视频编码要复杂得多,单纯的算法也远远比视频要更加复杂。 数字语言基本要素 数字声音具有三个要素:采样率、通道数、量化位数。 为什么要压缩 压缩音频,主要是为了在降低带宽负担的同时为视频腾出更多带宽空间。 编码器考虑因素 通过一些特定的压缩算法,可以压缩音频文件至原来的1/10,同时人耳也无法分辨压缩前后的声音质量差异,需要满足多种条件才能实现这种效果;而对于编码器,无论是设计阶段还是使用阶段,我们都需要考虑最佳压缩效果、算法的复杂度与算法的延时,结合特殊场景进行特定的设计;而兼容性也是我们不能不考虑的重点。 4.1 语音经典编码模型——发音模型 我们的很多编解码器都是基于综合人的发音模型与一些和听觉相关的理论支持研究提出的特定编解码算法。初期我们通过研究人的发音原理来设计音频编解码的算法,包括端到端的滤波或轻浊音等,只有充分理解人的发声原理我们才能在编解码端做出有价值的优化。 1)LPC LPC作为经典语音编码模式,其本质是一个线性预测的过程。早期的G.7系列编码模型便是通过此模型对整个语音进行编码,上图展示的过程可与之前的人发声过程进行匹配,每个环节都有一个相应的模块用来支撑人发声的过程。其中使用了AR数学模型进行线性预测,此算法也是现在很多语音编码的重要组成模块。 2)G.729 G.729同样是经典的语音编码模型之一,也是我们学习语音编码的一个入门级Codec。G.729的文档十分完善,包括每个模块的源代码在内都可直接下载。G.729可以说是在早期发声模型基础上的改进,需要关注的性能指标是帧长与算法上的延时,包括语音质量的MOS分。G.729也有很多变种,由于语音需要考虑系统兼容性,不同的系统指定携带的Codec也不同,音频编码的复杂程度要远高于视频编码。 4.2 语音经典编码模型——听觉模型 除了研究人发声的原理,我们还需要研究人听声的原理,从而更好实现声音的收集与处理。一个声音信号是否能被人耳听见主要取决于声音信号的频率、强度与其他音的干扰。心理声学模型便是用来找出音频信号中存在的冗余信息从而实现在压缩声音信号的同时不影响听觉的目的。心理声学理论的成熟为感知编码系统奠定了理论基础,这里的感知编码主要是ISO编码模型,主要覆盖的声学原理有临界频带、绝对听觉阈值、频域掩蔽、时域掩蔽等。 无论是MP3还是AAC以至于到后面的杜比音效都是基于听觉模型进行的探索与创新。 1)临界频带 临界频带主要用于心理声学模型。由于声音频率与掩蔽曲线并非线性关系,为从感知上来统一度量声音频率,我们引入了“临界频带”的概念。人耳对每段的某个频率的灵敏度不同,二者关系是非线性的。通常我们会将人可以听到的整个频率也就是从20Hz到16KHz分为24个频带,可在其中进行时域或频域类的掩蔽,将一些冗余信息从编码中去除从而有效提升压缩率。 2)绝对听觉阈值 绝对听觉阈值也可有效提升压缩率,基于心理声学模型,可去除编码中的冗余部分。 4.3 经典音频编码:ISO 我们可将最早的MP3 Layer1理解为第一代的ISO感知编码,随后的一些纯量化内容更多的是在压缩上进行改进而核心一直未改变。从MP3 Layer1到Layer2与Layer3,主要的改变是心理声学模型的迭代。   上图展示的是Encode与Decode的回路。输入的PCM首先会经过多子带分析与频域中的心理声学模型冗余处理,而后进行量化编码;Layer III中的是我们现在常说的MP3的Codec:Encode与Decode之间的整体回路,相比于Layer1多了几个处理环节以及霍夫曼编码。 4.4 AAC协议族 AAC与G.719一样包括很多系列,但AAC的巧妙之处在于向下兼容的特性。开始时我们就强调,所有Codec在设计时都需要考虑兼容性,瑞典的Coding Technology公司曾提出在兼容性上特别优化的方案。AAC Plus V1包括AAC与SBR,AAC Plus V2包括AAC+SBR+PS,现在常见的很多音乐类或直播音频编码都是基于AAC Plus协议族进行的。 德国的霍朗浦学院曾在AAC低延时协议扩展方面做出一些探索并得到了AAC LD协议族,其原理仍基于传统的AAC模块,但在后端会对处理长度进行调整,例如之前是以1024bit为一个处理单位,那改进后则以960bit为一个处理单位。除此之外AAC LD加入了LD-SBR与LD-MPS等,从而形成一个规模较大的AAC-ELD V2模块,可以说是十分巧妙。 1)AACPlus核心模块——SBR(Spectral Band Replication) 我们可以看到,AAC可以说充分利用了频域扩展,用很小的代价实现诸多功能优化。AAC的核心之一是SBR,这是一种使用极少位数就可描述高频部分并在解码时进行特殊优化从而实现频域扩展的模块。上图展示的是不同压缩率模块所覆盖的频率取值范围,而使用AAC时需要注意一个被称为“甜点码率”的指标。无论是采样率还是码率都是变化的,在应用时选择何种码率十分关键。例如直播时采用64Kbps即可在覆盖整个频段的同时保持良好音质。 2)AACPlus核心模块——PS(Parametric Stereo)     PS模块也是AAC的核心模块之一,主要用于分析左右声道属性并使用非常少的位数表示左右声道相关性,而后在解码端将左右声道分离。这里比较巧妙的是PS的向下兼容特性,整体数据打包是分开进行的。如果获取到AAC、SBR、PS三者的基本数据包后,在解码阶段我们就只需AAC—LC。上图展示的就是AAC的解码框架,如果大家读过3GPP的代码就可发现其每一个模块都相当清楚。我们可根据文档读取代码并对应到每一个环节。 3)甜点码率 甜点码率是一项很关键的指标。例如在手机直播应用场景中,一般的视频分辨率为640×360,音频码率大约在800K左右。如果音频码率过大则会直接影响视频质量,因而我们需要控制音频码率在一个较为合适的范围内从而实现最佳的音画效果。在很多应用场景中可能需要系统根据不同的网络环境下载不同音质的文件,例如在2G环境中下载较小的文件,这样做主要是为了节省带宽并提高音频文件的播放流畅程度。 4.5 AAC-ELD家族 AAC-ELD家族带来的主要改进是低延迟。如果Codec的延迟太长便无法在一些特定场景中被使用。例如早期AAC Plus V2的整体延迟可达100ms,如此高的延迟肯定无法被应用于语音通话等对实时性要求极高的应用场景。霍朗普学院推出的AAC-ELD可在保持音质的前提下将延迟降低至15ms,相对于MP3最高长达200ms的延迟而言提升巨大。 4.6 应用中端到端的延迟 编解码过程也存在延时问题,这也是我们选择编解码器时需要考虑的最主要因素之一,编解码的延时主要由处理延时与算法延时组成,例如G.729的算法延时为15ms,而AAC-LC可达到一百毫秒以上。另外,播放端或采集端的长帧数量太多,播放时缓存太多等也会直接影响延时,我们在选择编解码器时需要考虑延时带来的影响。 编解码器已经历了两个发展方向:一个是以G.7(G.729)为例,根据发声模型设计的一套主要集中于语音方面的编解码算法,另一个是以ISO的MP3和AAC为例,根据心理声学模型设计的一套感知编码。最近的趋势是编码的统一,原来在语音场景下我们使用8K或16K进行采样,音乐场景下则需使用覆盖到全频带的44.1K进行采样,每个Codec都有一个频域覆盖的范围。在之前的开发中,如果应用场景仅针对压缩语音那么需要选择语音编码方案,如果应用场景针对压缩音乐则需要选择音乐编码方案,而现在的发展方向是通过一套编码从容应对语音与音乐两个应用场景,这就是接下来将要被提到的USAC。 这里介绍两个比较典型的Codec:一个是Opus,通过其中集成的模块可实现根据传入音频文件的采样率等属性自动选择语音编码或音乐编码;另一个是EVS这也是霍朗普等组织推行的方案,已经尝试用于4G或5G之中。 由框图我们可以了解到USAC向下兼容的特性。编解码器可总结为经历了三个时代:发声模型、听觉感知、融合方案。接下来我将展示目前所有的Codec情况并整理为表格以方便大家检索查阅。 Codec总结 5.1 IETF系列 IETF作为标准协议联盟组织之一推出了以上Codec:Opus包括采样率为8kHz、甜点码率为11kbps的窄带单声语音(SILK),采样率为16kHz、甜点码率为20kbps的宽带单声语音与采样率为48kHz、甜点码率为32kbps的全带单声语音(CELT),采用甜点码率意味着将压缩率和音质保持在一个良好的平衡状态。在一些窄带单声语音应用场景例如常见的微信语音聊天,其压缩率可达到原来的8.5%。Opus没有技术专利和源代码的门槛,使得其受到现在很多流媒体厂商的欢迎,Opus支持更广的码率范围,具备丰富采样率选择,可实现极低延迟与可变帧大小,也具备以往一些Codec的许多特性如CBR、VBR、动态调整等,支持的通道数量也更多。除此之外,Opus同样具备许多从SILK移植而来的特性或功能。如在VUIB传输上集成了扛丢包模式等。 iLBC早在SILK未出现时就被提出同样具备抗丢包。的特性,高达15.2kbps的甜点码率与4.14的Mos使其音质较为良好,超过G.729的相关指标;GSM就是最早手机网络仍停留在2G时代时流行的编码形式,主要用于蜂窝电话的编码任务。 5.2 AMR系列 AMR早在3G时期就被广泛应用,AMR-NB是最流行的语音编码器,具有压缩效果好,支持多种码率形式的特点;与此同时,这也是GSM与3G时期Android平台最早支持的窄带语音编码方案。AMR-WB作为AMR-NB向宽带的扩展版,主要用于3G和4G通话标准协议中,其甜点码率为12.65kbps。在实践中我们将码率参数调整为此值即可实现压缩率与质量的平衡。AMR-WB+则是上述两者的融合,三者共同构成AMR系列。 5.3 ITU-T G系列 ITU-T G系列包括最早的波形编码G711到现在大家熟悉的G.729这里我想强调的是G722.1 Siren7、G722.1c Siren14与G719 Siren22,例如G.719可覆盖整个前频带且支持立体声。即使都属于老协议,但由于其优秀的兼容性,不应被我们忽略。 将Opus与其他一些Codec进行对比我们可以看到,无论是质量还是延时控制,Opus的优势十分明显;加之Opus作为开源的免费方案,不存在专利限制,受到业界追捧也不足为奇。 5.4 ISO系列 ISO里我想强调的是MP3与AAC,二者同样支持很多码率。MP3的甜点码率为128kbps,MP3 Pro的码率可达到MP3的一半;AAC支持8~96khz的采样率,AAC-LC的甜点码率为96kbps,HE-AAC的甜点码率为32kbps,AAC-LD与ELD做到了AAC的低延时,实现了延时与压缩比的最佳平衡。 5.5 3GPP系列:EVRC 高通公司主推的3GPP是CDMA中使用的语音编解码器,在未来选择编解码器类型时我们需要特别考虑延时与帧长。由于语音编码种类很多,帧长也是复杂多变的,其背后的算法复杂程度,RAM、ROM占用等都是在实践当中需要着重考虑的。 5.6 极低码率 极低码率主要的应用场景是对讲机、卫星通讯、军工等。图表中的MELP最早由美国军方开发,现在绝大多数的对讲机都基于此模型进行扩展开发,压缩后的码率可达到2.4kbps而目前最极端的极低码率可实现300bps,相当于压缩为原数据的0.2%,此时的音频文件仅能被用于传达语音内容而丢失了很多声色。 5.7 全频带 全频带中的组合也是多种多样。 编解码使用注意 6.1 License 国内大部分企业在开发时容易忽视包括专利安全性在内的与License相关的内容。如果企业计划得比较长远,需要长期使用某项技术或企业规模不断扩大时则不能不考虑专利问题。专利费用包括Open Source与算法专利,二者完全独立互不干涉,如果我们从某家专利公司购买了AAC的专利算法,并不能获得此AAC专利的源代码,仅能获得与此技术相关的专利使用授权。专利公司会给予需要下载的文件列表,通过这种方式实现技术的授权使用。 上面的二叉树图比较清晰地展示了代码授权的具体流程,随着企业的规模化发展日趋成熟,企业应当规范自身的技术使用行为,尽可能避免专利纠纷带来的不利影响。 6.2 专利 主流语音编解码技术拥有两个专利池:MPEG-LA与Via Licensing。很多非常复杂的Codec涉及高达上千个专利,与之相关的企业或组织多达几十个,为专利授权而与每一个企业或组织进行洽谈显然是不现实的,因而专利池的出现使得技术授权更加规范清晰,方便企业统一处理技术授权问题。 6.3 常见Codec Patent License     想要阅读更多技术干货文章,欢迎关注网易云信博客。 了解网易云信,来自网易核心架构的通信与视频云服务。 网易云信(NeteaseYunXin)是集网易18年IM以及音视频技术打造的PaaS服务产品,来自网易核心技术架构的通信与视频云服务,稳定易用且功能全面,致力于提供全球领先的技术能力和场景化解决方案。开发者通过集成客户端SDK和云端OPEN API,即可快速实现包含IM、音视频通话、直播、点播、互动白板、短信等功能。  

2018-12-03

网易云信融合CDN方案及实践

日前,网易云信视频云架构师席智勇在第七届GFIC全球家庭互联网大会进行了题为《网易云信融合CDN方案及实践》的分享,以下是演讲内容回顾。   想要阅读更多技术干货文章,欢迎关注网易云信博客。 了解网易云信,来自网易核心架构的通信与视频云服务。   图为 网易云信视频云架构师席智勇   CDN所面临的问题   传统的CDN网络在流媒体加速的场景下面临更大的挑战,视频加速尤其是直播场景,对于网络传输中的不稳定因素表现的更加敏感,对于网络接入环境、网络资源覆盖、链路选择、调度的敏捷和智能等方面都提出了更高的要求。   除了大家在做视频加速时面对的一些共同问题,比如怎么做到更高的视频秒开、卡顿率更低、更好的画质体验等,席智勇表示:“我们作为一个视频云平台,一方面关注于怎么在CDN网络下做到更好的网络分发,另一方面通过端到端,全链路的网络和媒体流控制,将最终端到端的体验做到最佳;除次之外,我们还要做到使用和接入的简单易用。”在直播画质提升、观看体验优化方面,席智勇介绍说:“在直播方面我们现在也在推广H265推流,同时借助服务端转码能力,提供实时的自适应码流方案,在这个过程中为客户提供更高的CDN加速的质量,保障端到端的效果。”关于融合CDN方案,还他介绍到:“有些问题当然是可以通过资源、通过钱来解决的,但是成本也是我们不可避免肯定要考虑得,所以怎么利用融合CDN,在效果和成本之间做好一定的平衡也是技术需要去解决的问题。”   NCDN+成熟厂商+端到端控制   网易云信聚焦做视频云领域PaaS平台, 面对点播、直播、互动直播场景下流媒体加速的需求以及上面提到的CDN方面的问题,网易云信一方面在CDN网络建设中针对流媒体场景做针对性的优化,另一方面利用成熟的CDN厂商网络资源作为资源覆盖和高可用方面的补充,通过云信视频云敏捷智能的CDN调度策略和算法,结合全链路、端到端的流媒体控制,来达到最终端侧优良的用户体验。云信作为一个视频云平台,对于用户在使用、接入上的方便易用也有较高的要求。云信视频云平台提供一站式的音视频解决方案,直播、录制、视频存储、点播、播放等形成闭环,一方面提供最佳的端到端体验,一方面最大程度方便用户的使用和接入。   上行与下行的智能调度   网易云信最终提供的是一个端到端的服务,通过平台的SDK来走一个类似HTTPDNS的调度,来做到真正根据用户IP做就近的接入。针对国内相对复杂的非主流运营商网络环境,云信在直播上行方面通过BGP网络以及与相关运营商的网络接入方面的合作,能够更加精准的控制网络链路的选择。 而对于下行,席智勇表示:“我们下行在播放端也是有SDK,下行也会优先通过端到端的一个调度走下行的一个链路择优,对于下行链路上的优化,一方面是能够解决好最后一公里的链路优化,另外保持对一些定制化的需求和一些后续扩展方案的兼容,如现在大家都在尝试的边缘下沉和P2P加速。” 席智勇表示:“调度的准确性以及最终效果,依赖及时准确的数据支撑,我们有一个全链路、立体的数据监控体系的,一方面利用CDN上的一些实时日志,另一方面结合端这一侧会收集一些链路上探测的数据,然后整个做一个实时的计算来支撑整个调度的策略。”关注最终的融合CDN方案,席智勇解释到:“虽然我们前面讲了很多调度、监控、高可用等等技术和手段来解决CDN网络方面的问题,但是对于我们平台上的用户,就和在使用一个传统的CDN网络一样没有大的差异,这些技术细节对用户完全透明没有感知的,用户通过简单易用的接入,就具备了高可用、全链路控制的流媒体分发服务。”       在演讲的最后席智勇表示:“CDN从最初的静态资源下载加速,到流媒体加速,到现在边缘下沉、P2P等方面的演进,但本质还是要做好内容的分发。对于传统CDN网络,可以利用既有的资源和网络优势,做到更加的透明和开放,而应用上可以借助端侧的能力,做到更好的端到端控制。”     想要阅读更多技术干货文章,欢迎关注网易云信博客。 了解网易云信,来自网易核心架构的通信与视频云服务。 网易云信(NeteaseYunXin)是集网易18年IM以及音视频技术打造的PaaS服务产品,来自网易核心技术架构的通信与视频云服务,稳定易用且功能全面,致力于提供全球领先的技术能力和场景化解决方案。开发者通过集成客户端SDK和云端OPEN API,即可快速实现包含IM、音视频通话、直播、点播、互动白板、短信等功能。

2018-12-03

C语言之父Dennis Ritchie告诉你:如何成为世界上最好的程序员?

文/Ohans Emmanuel 译/网易云信   想要阅读更多技术干货文章,欢迎关注网易云信博客。 了解网易云信,来自网易核心架构的通信与视频云服务。   我不知道如何成为世界上最好的程序员。但是,我们可以向历史上最伟大的程序员学习。该系列文章将会向大家分享C语言的创造者、Unix操作系统的关键开发者Dennis Ritchie、。Linux内核的发明人Linus Torvalds的经历与建议。   UNIX基本上是一个简单的操作系统,但你必须是一个了解“简单”的天才--Dennis Ritchie 获得计算机编程学位的前几天,Dennis Ritchie获得了在麻省理工学院(麻省理工学院)工作的机会。 计算机实验室不像现在这样挑剔,并且几乎欢迎任何有耐心帮助他们在房间大小的计算机上工作的人。 对于最初是行业局外人的人来说,创建UNIX和C语言 - 计算机历史上最广泛使用的两种技术 - 是一件大事。非常重要的大事。   以下是Dennis Ritchie的一些成就: Dennis Ritchie创建了C语言,并与他的好友Ken Thompson共同创建了UNIX操作系统。 1983年,他获得了计算机协会(ACM)颁发的图灵奖。 1990年,Ritchie和Thompson都获得了电气和电子工程师协会(IEEE)颁发的IEEE Richard W. Hamming奖章。 1997年,他成为计算机历史博物馆的成员 他于1999年获得克林顿总统颁发的国家技术奖章   那么他是获得这些成就的呢?更重要的是,Dennis Ritchie是如何学会编写软件的?   丹尼斯·里奇(Dennis Ritchie) - 被称为“C编程语言之父” - 被认为是一个体贴,善良,谦逊的人 - 而且是一个完全极客! 但他并不是一个极客。 里奇出生于纽约,在新泽西州的花园城市长大。他有一个稳定的童年,并在学业上做得很好。 他在哈佛大学继续他的学业,在那里他学习科学并取得他的物理学学士学位。 那么计算机什么时候进入里奇的生活?   要点1:如果你想成为擅长编写出色软件的人,你需要时刻保持好奇心。 我既不聪明也不特别有天赋。我只是非常非常好奇 - 爱因斯坦 好奇心激发了人们对知识的渴求。知识,统治世界。 在里奇还是一个学生的时候,他不知怎么去听了一个关于UNIVAC的讲座。 该UNIVAC I(通用自动计算机I)是在美国生产的第一款商用计算机。 下面是它的样子: 说真的,什么样的好奇心让一个人坐下来并且真正享受关于UNIVAC如何运作的讲座? 显然,这是一个伟大的程序员。 在那次遭遇之后,Ritchie继续研究计算机是如何工作的。 好奇心杀死了猫。我们都知道,但你不是猫。   要点2:建立更多的项目,了解更多的业务。 我没有专注于特定项目,而是希望能成为拥有丰富经验和想法的人。所以我开始从事各种项目去了解我的职业生涯。“ - 丹尼斯里奇 让建立很多项目成为你好奇心的产物。将好奇心转化为构建不同的项目 - 和Ritchie一样,这将有助于您了解自己的职业。   要点3:和你认为更专业,更有经验的人待在一起。 你之所以应该这么做,最明显的原因是,你的学习速度会快得多,并且对你目前的知识不会太满意。 这是另外一件Dennis Ritchie据说做的很好的事情。 如果你不能亲近那些你认为更好,更有经验的人,那么互联网就是你的朋友。 在您感觉舒适的频道上关注他们。阅读他们的博文。观看他们的YouTube视频。收听他们的播客。 和“他们”待在一起。   第4点:解决问题。 “这不是真正有趣的编程。但这是你可以用最重要的结果来获得的东西。“ - Dennis Ritchie 丹尼斯·里奇(Dennis Ritchie)生活在一个电脑填满房间的时代。但是Ritchie知道小型计算机正在被开发中,并且他们没有易于使用的操作系统,所以他开始来构建一个。 这就是里奇对通用编程的看法,它与可实现的目标相关。操作系统的问题被解决了,并且对后代有深远的影响。 如果问题困扰你,请不要忽视它。如果您认为它被许多人忽视,请解决它。 感到好奇。研究概念。请求帮助。 在解决问题之前,你不应该回头看。   当事情足够重要的时候,即使希望不大,你也会这样做--Elon Musk。 这里有些例子 : Electron JS,让Javascript构建桌面应用程序的技术变得生动起来,因为Github团队想要使用Web技术构建一个可破解的编辑器。 Redux是Javascript应用程序的可预测状态容器,由Dan Abramov构建,因为他想创建一个具有最小API但完全可预测行为的状态管理库 - 这就是他所说的方式。 Quincy Larson和其他几个人构建了Freecodecamp平台,以解决在开源社区中教授Web技术的问题。 他们看到了一个问题,然后继续解决它。   C语言之父Dennis Ritchie的关键要点 保持好奇,并继续燃烧求知的火焰。我们永远不会无所不知。 了解基本原理。掌握基础知识,才是真正的技能大师。 解决问题。如果您认为某些事情可以采取不同的方式,并且应该被完成,那就去做吧。你将能够更快,更好地生活。 建立许多不同的项目。 和拥有更多专业知识,经验和想法的人待在一起。这是无价之宝,你无法与其他事情交换。     想要阅读更多技术干货文章,欢迎关注网易云信博客。 了解网易云信,来自网易核心架构的通信与视频云服务。 网易云信(NeteaseYunXin)是集网易18年IM以及音视频技术打造的PaaS服务产品,来自网易核心技术架构的通信与视频云服务,稳定易用且功能全面,致力于提供全球领先的技术能力和场景化解决方案。开发者通过集成客户端SDK和云端OPEN API,即可快速实现包含IM、音视频通话、直播、点播、互动白板、短信等功能。

2018-12-03

Facebook全面推出Watch Party,可多人线上同看直播视频

想要阅读更多技术干货文章,欢迎关注网易云信博客。 了解网易云信,来自网易核心架构的通信与视频云服务。 今天, Facebook全面推出Watch Party——多人共同观看直播功能,用户可以同时查看和评论同一视频。 Watch Party先前已在群组中推出,并且正在测试其他类型的帐户。但现在任何个人资料或企业都可以发布一个Watch Party邀请,与其他用户同步,同时观看他们在Facebook上发现的视频。 下面是它的工作原理(从Facebook的演示视频中借用的截图): 1)开始观看派对就像在群组墙上发布任何其他内容一样。给它一个标题以吸引人们的注意力,或者给它一个图像并发布。 ​ 2)添加几个视频开始填充队列 ​ 3)一旦有几个人加入,Straem将开始。视频将同步给所有观看者,主持人可以控制视频的进度。您可以随时添加更多视频。 ​ 对于那些在测试模式下早期访问Watch Party的用户,他们为该版本添加了一些新功能: 观众可以推荐视频,在主机的提要中弹出建议以供批准(或不批准) 每个观看派对现在可以拥有多个共同主持人,每个共同主持人可以将新视频添加到队列中 与YouTube,Netflix甚至Snapchat Discover相比,Watch的内容阵容仍然乏善可陈。CNBC报道称Facebook正在放弃那些已经放弃其应用程序的青少年,并将视频中心转向更老的受众。Facebook希望与用户共同评论剪辑的共享体验可以使Watch更具吸引力,但这种全新的行为可能很难被灌输。 Facebook还在测试一些其他功能,为Watch注入活力。页面和群组将能够安排观看派对来吸引更多观众,也许是设置一个夜间聚会。最有趣的是,Facebook将尝试允许观看派对的主持人现场直播,这样他们就可以实时评论了。这可能是名人的热门话题,因为这会让用户感觉他们坐在一起看电视。篮球明星Shaq明天将通过他的网页测试现场评论功能。 Watch Party的统计数据听起来令人印象深刻,迄今为止已有1200万群组使用,自7月推出以来每天观看群组每天增长7倍以上,比非现场/同步视频多8倍的评论。但是考虑到Facebook每月有22亿的用户,超过10亿的群组用户,并且当你从低数量开始衡量增长很容易,这个特性显然还没有达到时代潮流。 Facebook一直在竭尽全力试图将视频消费行为从被动的僵尸观看转变为与同伴进行互动和社交互动。但是只有在内容足够有吸引力的情况下,这种设想才能顺利进行。 参考链接: https://techcrunch.com/2018/11/27/watch-party-commentating/?__s=45jcvs64z466vprkqzve     想要阅读更多技术干货文章,欢迎关注网易云信博客。 了解网易云信,来自网易核心架构的通信与视频云服务。 网易云信(NeteaseYunXin)是集网易18年IM以及音视频技术打造的PaaS服务产品,来自网易核心技术架构的通信与视频云服务,稳定易用且功能全面,致力于提供全球领先的技术能力和场景化解决方案。开发者通过集成客户端SDK和云端OPEN API,即可快速实现包含IM、音视频通话、直播、点播、互动白板、短信等功能。

2018-12-03

《周四橄榄球之夜》流媒体视频拆解:Twitch VS Amazon Prime

  文 / Phil Cluff 译 / 王月美 原文链接:https://mux.com/blog/thursday-night-football-streaming-technology-showdown-amazon-prime-vs-twitch/?from=groupmessage 文章转载自LiveVideoStack公众号 想要阅读更多技术干货文章,欢迎关注网易云信博客。 了解网易云信,来自网易核心架构的通信与视频云服务。   在英格兰长大的我会公开承认美式橄榄球并非我的第一运动项目选择,但无论以任何人的标准,美式橄榄球都是非常流行的。去年亚马逊在其Prime Video平台上开始直播流媒体《周四橄榄球之夜》。几个月前,他们宣布将此协议延长了两年。 最近,亚马逊开始通过在亚马逊Prime Video和Twitch上举办《周四橄榄球之夜》来进行自我竞争(提醒:亚马逊在2016年以约9.7亿美元收购了Twitch)。据我所知,这是第一次在Twitch上直播大型(非电子竞技)体育赛事。 我在旧金山办公室的同事们都对梦幻橄榄球赛很是着迷,所以当我发现自己和团队一起观看《周四橄榄球之夜》时,我想,“嘿,这背后的堆栈是什么?”和“Twitch 流媒体与在Twitch播放器中播放的亚马逊Prime 流媒体是同一个吗?” 好吧,接下来让我们深入了解一些体育盛会流媒体架构吧! Twitch (左图) vs Amazon Prime Video (右图) 怎样理解流媒体架构? 研究流媒体服务背后的技术堆栈实际上并不那么难,尤其是在业内多年从事调试各种奇怪的客户设置并帮助他们过渡到新系统之后。我在这里所做的一切你都可以自己进行尝试,而你需要的只是一个浏览器,curl,bento工具包,以及良好的网络视频工作知识。 亚马逊Prime—流媒体堆栈拆解 我们将主要关注桌面浏览器的策略,因为它是最容易调试的平台。因此,让我们全身心投入,并在Chrome中加载Amazon Prime播放器,然后启动网络检查器。 我们需要找什么呢?首先,让我们假设Amazon和Twitch正在使用完善的流媒体技术,如HLS或MPEG DASH。而这两种技术都依赖于称为“清单”的文本文件来描述视频呈现并让浏览器知道从哪里获取视频片段以进行回放。 对于HLS,我们通常是在网络检查器中查找.m3u8文件;而对于DASH,我们要查找.mpd请求,或者有时只查找.xml请求。幸运的是,该这种情况下, Amazon Prime似乎正在为它们的流使用MPEG DASH和更传统的.mpd文件扩展名。 如果我们将请求过滤到.mpd并观察视频流一段时间,我们会注意到每隔几秒就会重新请求清单。这样播放器就可以知道最新的内容块何时可用以及从何处获取内容。通过查看清单,我们可以了解很多有关Amazon Prime视频传输环境的信息。我们来看看下面的(稍微缩短的)清单。 <?xml version="1.0" encoding="UTF-8"?> <MPD xmlns="urn:mpeg:dash:schema:mpd:2011" xmlns:scte35="urn:scte:scte35:2013:xml" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" availabilityStartTime="2018-10-24T06:01:19.831000+00:00" id="201" minBufferTime="PT30S" minimumUpdatePeriod="PT5S" profiles="urn:mpeg:dash:profile:isoff-live:2011" publishTime="2018-10-26T03:17:16" suggestedPresentationDelay="PT2.000S" timeShiftBufferDepth="PT299.000S" type="dynamic" xsi:schemaLocation="urn:mpeg:dash:schema:mpd:2011 http://standards.iso.org/ittf/PubliclyAvailableStandards/MPEG-DASH_schema_files/DASH-MPD.xsd"> <BaseURL>../../../../../../../../../../../SFO/clients/dash/enc/9tojxgpp-1/out/v1/8130a6b1cfb24c2aa27b73b90de12d82/</BaseURL> 包装:MPEG DASH,H.264以2秒fMP4片段编码 如果我们看一下清单中的一些表示(即处理),会发现亚马逊正在使用的编解码器和媒体包装技术。我们可以检查“编解码器”字符串以了解正在使用的编解码器,以及通过“mimeType”来检查打包方式。编解码器字符串实际上包含了许多编码为RFC 6381字符串的信息,包括正在使用的H.264的profile。在清单中传输此信息非常有用,因为它允许您使用API来确保该特定版本的编解码器可在设备上解码。 亚马逊使用的是用于视频的H.264和用于音频的AAC的通用组合方式。 亚马逊为其台式机播放器使用了9个视频再现,范围从288p到720p30p @ 8 Mbit。他们还以4种不同语言展示了1个解复用的音频再现。 检查清单中的SegmentTemplate,我们可以看到片段正以.mp4文件扩展名提供(一般情况下,但有些人选择为其片段扩展提供.m4f)。如果我们在观看内容时更改我们的过滤器以查找“.mp4”,我们会看到每隔几秒钟发生一次段请求。另外,亚马逊是分别提供音频和视频片段(分解复用)。   我们还可以使用SegmentTemplate来计算视频片段的长度。从查看视频录像开始,我们看到frameRate设置为“30/1”。 接下来我们可以看到录像的时间刻度是“30”。 当我们将它与SegmentTimeline中每个段的声明持续时间(d =“60”)结合起来时,我们可以计算出每个段包含60帧@ 30 FPS,因此为2秒的内容。当以流式传输实时视频时,段长度是很重要的,因为它会严重影响端到端传送的延迟。实际上,两秒是可行的最低段持续时间,该情况下不会对编码器性能和终端用户缓冲体验产生负面影响。 广告的插入:多个DASH周期 我们在DASH清单中看到的顶级元素是Periods。 向下滚动清单,我们看到有几个顶级周期实体。多周期MPEG DASH是一种在直播视频流中实现广告插入的方式。在这种情况下,我们会看到长时间的内容,然后是包含广告的多个较短的时段。 我们可以从之前查看的HTTP请求中学到更多信息,特别是让我们看一下Segment响应中的X-header。 有趣的是X-MediaPackage标题,它们是无意中暴露亚马逊使用AWS的Elemental MediaPackage产品的确凿证据。我们可以在清单请求上再次查看标题,以确认清单是否是由AWS的Elemental MediaTailor产品所提供。 MediaTailor是一种基于清单操作的服务器端广告插入(SSAI)解决方案,因此现在我们知道亚马逊是如何为《周四橄榄球之夜》进行广告替换的了(可能还有广告定位)。 DRM:CENC加密 从清单中我们还可以看到亚马逊是如何保护其内容¬的——我们可以看到两个不同的ContentProtection块嵌套在Representations中。 ContentProtection块定义了客户端可用的对内容进行解密的不同方法。 <ContentProtection schemeIdUri="urn:uuid:edef8ba9-79d6-4ace-a3c8-27dcd51d21ed"/> <ContentProtection schemeIdUri="urn:uuid:9a04f079-9840-4286-ab92-e65be0885f95"/> 上面的两个UUID在业内是众所周知的——它们告诉我们亚马逊正在使用Widevine(edef8ba9)和Playready(9a04f079)的通用组合。这将在普通桌面、移动平台以及最流行的OTT设备上实现相当全面的覆盖。 CDN交付:Akamai和CloudFront 查看亚马逊的清单,我们可以看到媒体段的BaseURL在其开头没有URL方案。这意味着视频片段通过与清单相同的CDN基础设施提供服务。回到我们原来的过滤器找到清单文件,我们看到清单的主机名(以及段)是https://aivottevtad-a.akamaihd.net。http://akamaihd.net是Akamai拥有的边缘主机名,它让我们知道,对于此次视图,亚马逊使用Akamai向最终用户交付其视频片段。 现在开始就很有趣了,因为我希望将AWS CloudFront视为主要媒体CDN。业界里众所周知,AWS正在媒体领域大力推动CloudFront,尤其是在与全球产品相比网络连接最佳的美国。我确实和几个其他观看相同流的人核实过,并确实也发现了至少一个CloudFront而非Akamai提供的流。混合中可能还有更多我们还没有发现的CDN。在美国公开赛期间,我也发现Amazon Prime在英国使用Limelight来交付视频片段。 鉴于Amazon Prime Video的规模和成熟度,他们将使用多个CDN来提供某种程度的冗余是有道理的。但是,值得注意的是,鉴于他们当前的策略是在其清单中使用相对主机名,而不是在其边缘主机名之上使用任何形式的DNS间接,那么在当前架构中的中级流CDN切换将无法维持QOS(或至少需要相当复杂的播放器修改)。密切关注他们的方法,看看他们是否选择采用中流CDN切换,如果是这样,那么他们是购买现成的还是建立自己的解决方案呢?这将会很有意思。 视频编码器:AWS Elemental Media Live 到目前为止,我们已经验证了亚马逊正在使用他们自己的AWS Elemental软件解决方案。我们检查了他们的包装和广告插入技术,但对编码器一无所知(让我们正视它,如果它不是Elemental,我会感到非常震惊)。这有点难以鉴定,但我们可以做一件简单的事情来获得一些提示。 对于MPEG-DASH流,初始化段用于每个视频或音频再现以在客户端侧设置解码器。 我们可以在SegmentTemplate初始化属性下的DASH清单中看到这些mp4段的URL。可以下载其中一个初始化段并使用Bento的mp4dump工具转储内容。 我不想详细介绍MP4结构(尽管几年前我曾在Demuxed上就这个主题发表了演讲),但我们可以在moov/trak/hdlr框中看到以下有趣的层次结构: mp4dump --verbosity 3 amazon-init.mp4   // Trimmed for space saving [moov] size=8+1693 [trak] size=8+595 ... [mdia] size=8+495 ... [hdlr] size=12+48 handler_type = vide handler_name = ETI ISO Video Media Handler 通常来说,hdlr框由编码器设置为可识别的东西。在这种情况下,“ETI”是Elemental编码器设置的识别标识。我不知道它究竟代表什么,但我猜测是“Elemental转码一些东西”。 实际上,我认为亚马逊将再次使用AWS Elemental MediaLive进行实时编码。 亚马逊—推测架构 警告:一些预先推测。 当我们将上面学到的所有内容放在一起时,我们可以为亚马逊如何为《周四橄榄球之夜》构建他们的视频传输栈提供一个非常全面的图片——让我们来看一个架构图。我们假设亚马逊至少使用了我们所知道的CDN,当然可能还有更多。 实际上,对于这种高profile的东西,我预计架构中也会有一定程度的冗余,可能是在不同AWS区域运行的多个独立支路。我们已经知道有一些形式的流启动CDN切换正在进行,但我确信亚马逊不止于此。 老实说,这是一个非常可靠的实时流媒体架构,真正反映了亚马逊对自己的AWS和Elemental产品目录的承诺。对于我来说的一大惊喜是Akamai在他们的交付堆栈中处于前沿和中心位置。即使它看起来似乎与CloudFront进行负载平衡,但是肯定有很多数据流经Akamai —CloudFront最大的竞争对手之一。 Twitch -流媒体堆栈拆解 那么Twitch到底是什么?它是存在于他们的播放器中但仅仅是相同的内容? 嗯,这将更有意思......但同时也包含了更多的猜想。从Twitch工程师的谈话中我们知道,Twitch在内部构建了大部分视频基础设施,这使得我们更难以比较业界已知平台的响应,但让我们看看我们可以弄清楚一些什么。 我们将采用与上次在Twitch上启动Chrome游戏并寻找清单请求相同的策略。 Twitch是用Apple HLS格式提供内容的忠实拥护者,所以让我们从寻找.m3u8文件的请求开始。 First try! 如此迅速Twitch似乎不太可能只是输入亚马逊Prime视频流并对其进行重新包装。让我们检查Twitch的主要清单,看看我们可以学到什么。 #EXTM3U #EXT-X-TWITCH-INFO:SUPPRESS="true",MANIFEST-NODE="video-weaver.sjc02",BROADCAST-ID="30929838144",MANIFEST-CLUSTER="sjc02",NODE="video-edge-a242e4.sjc02",MANIFEST-NODE-TYPE="weaver_cluster",CLUSTER="sjc02",SERVER-TIME="1540523190.00",TRANSCODESTACK="2017TranscodeEvent_V2",USER-IP="98.210.167.151",SERVING-ID="54fa5e185b94450ab67e1edd3b68cec0",ABS="false",STREAM-TIME="15636.023155"   #EXT-X-MEDIA:TYPE=VIDEO,GROUP-ID="chunked",NAME="720p60 (source)",AUTOSELECT=YES,DEFAULT=YES #EXT-X-STREAM-INF:FRAME-RATE=60.000,BANDWIDTH=6622552,RESOLUTION=1280x720,CODECS="avc1.4D4020,mp4a.40.2",VIDEO="chunked" https://video-weaver.sjc02.hls.ttvnw.net/v1/playlist/Ct0Ds6pAbATHFHWuAFVkXteyoZK9Z2PHT-yJpD6-Y3meL9myH6K1DfiSXEGFacqiv-_hmdut19Gn5ye6XZWblmWS1zAKTy8eJONaMYv5Jxz7E0a7hEWxHFnmTUD4IWjEgk57m6IBHHxynZJp5Rp7mIigS6ycHqiTNgWcISWQ9jPpeNtOA9XKISN7GvvI0shGQS7QJZ-DlMPDF39R5o2fbAoHNUekFUcqorg7pOAkfm5SxNO5ikadvXi3g9v1-alJ-Im_LY9ZkQ1BT44uYWsxpqFj15tcgsmY5cSJkCk1AbV9KxXOapla1QQ_Xu1kUpeCdnFzjSk1pTPY0axz3DE_X7ibAMZcsZmNUFDgrN7ofYxdNEAO-fU1C7wWQ697PojkWsd7drfZA478us8lRdSTxeRSOJtnxHArqAeCYBFnxGxzM_TtzOe5k3sHlwoIsY0UmJ6e5drbh7Sm2hZQ46GNRaca4llhzRDg_dkgAZX0WQgHThyga6NxvYM4JJmXeerNjyNxqVSgqOH1LOWwuGZgX22g238GS-b0E39R8rbjTyG6reCUgqMp5A6DGtvvHWQCTliNMjpsu8PSqddYOti2x2Bj3gzI2e3H0w_1OMEmgz8FH491Ye_I5VhCjtUb8yIsEhAuBp5oVXr0Hq_cZ2g8E7B6Ggxg7Pw9W3aEEMZ8Ubk.m3u8   # 5 other renditions removed to save space. 这是一个非常标准的HLS主清单,其中包含一些Twitch元数据—根据HLS规范,播放器应该忽略他们不理解的语句。让我们看一下在Twitch方面为亚马逊所看到的相同区域。 包装:HLS,H.264以2秒fMP4片段编码 仅从主清单中我们就可以知道Twitch正在使用哪些编解码器进行交付——在#EXT-X-STREAM-INF CODECS 字段中,我们可以看到从Amazon Prime上看到的相同编解码器组合—H.264和AAC。 Twitch提供6个再现,从160p到720p 60fps。 这与我们之前在亚马逊上看到的非常接近。但是,在Twitch的情况下,最高比特率为6.6Mbps,但帧率更高。这可能是高运动内容的最佳选择。同样值得注意的是Twitch比特率和分辨率比亚马逊更低,这意味着Twitch正在更加积极地为用户提供蜂窝或低性能互联网连接服务。 由于Twitch正在使用HLS,我们需要执行额外的步骤来获取精密封装所使用的任何信息。正如我们在HLS博客文章中所解释的那样,HLS使用多个清单——一个清单列出了所有可用的处理,然后另一个清单,用于每个处理中的细分。因此,让我们看看其中一个处理清单——我们可以从主清单中提取URL并将其下拉。 这是有意思的地方。由Twitch提供的处理清单包含HLS声明的版本6(#EXT-X-VERSION:6),这意味着Twitch正在使用HLS的一些现代和有趣的功能——也确实如此。我们发现,Twitch使用#EXT-X-MAP:URI指向fMP4初始化段——该方法仅包含在最新版本的HLS规范中。我们也可以下拉清单查看所有的段URL均指向.mp4片段。 这与Twitch通常的策略有很大不同—长期以来,Twitch一直是使用更传统的传输流段包装格式(.ts)。但是这种新方法是否表明Twitch的战略发生了根本性的变化,还是有一些更明显的原因可以促成这种变化? 事实证明,答案实际非常简单—Twitch似乎是对《周四橄榄球之夜》流进行DRM。据我所知,这是Twitch第一次在他们的平台上对内容进行DRM。自从我开始研究这个主题以来,我一直在关注TwitchPresents频道,并且我没有看到DRM被用于任何Pokemon或Bob Ross剧集中。我猜想《周四橄榄球之夜》的合同规定了DRM的要求。 值得庆幸的是,在HLS中,我们无需进行任何数学计算来获得媒体片段的持续时间——这些信息整齐地包含在清单中每个媒体片段的正上方。在这种情况下,我们可以看到每个段前面都有 #EXTINF:2.002,表示段长度超过2秒: #EXT-X-PROGRAM-DATE-TIME:2018-10-26T03:06:27.559Z #EXTINF:2.002,live https://video-edge-a242e4.sjc02.abs.hls.ttvnw.net/v1/segment/LONGTEXT.mp4 DRM:CENC加密 那么我们如何判断Twitch是否在其fMP4 HLS流上使用DRM?当然,我们需要再次将Bento MP4倾销工具拿出来。我们可以获取在演示清单中声明的初始化URL并下载它以查看其中包含的数据。 这次我们要转储文件并查找pssh框,这些框声明了可用于解密文件的可用DRM技术。在HLS中,关于内容加密的数据必须嵌入在媒体中,因为在清单文件中仅提供用于传递FairPlay DRM信息的规范。 mp4dump --verbosity 3 twitch-init.mp4   // Trimmed for space saving [pssh] size=12+75 system_id = [ed ef 8b a9 79 d6 4a ce a3 c8 27 dc d5 1d 21 ed] data_size = 55 data = [...] [pssh] size=12+966 system_id = [9a 04 f0 79 98 40 42 86 ab 92 e6 5b e0 88 5f 95] data_size = 946 data = [...] 如果我们仔细观察这些 system_id ,会注意到它们与我们在Amazon Prime流的DASH清单中的ContentProtection块中看到的UUID相同。这使得我们可以推断出Twitch也在使用Playready和Widevine来保护他们的桌面流。 广告的插入:Twitch Weaver Twitch的视频流也有广告,但不是电视节目上的广告。通过查看主清单,我们可以看到正在使用的再现清单URL指向称为“Weaver”的内容https://video-weaver.sjc02.hls.ttvnw.net。 正如我们几周前在Demuxed上了解到的那样,Weaver是Twitch的HLS广告插入服务,它通过声明播放列表中的不连续性并插入广告内容的片段来将广告拼接到视频流中。这种方法在业界是相当标准的,并且比使用多周期DASH要简单得多。 CDN:Twitch (可能)的CDN 现在这里的事情开始变得更加朦胧了。如果我们尝试重现我们最后一种方法来得出Twitch正在使用什么CDN,我们就会毫无头绪。查看片段来源的Twitch的URL,我们得到主机名http://video-edge-a242e4.sjc02.abs.hls.ttvnw.net—但这对我们没有任何帮助。 然而,业界众所周知,Twitch运行自己的CDN——我检查了其他来自Twitch的视频流,它们似乎来自于与我在观看《周四橄榄球之夜》时记录的相同IP范围内的类似主机名。 反向DNS查找和IP WHOIS查找没有显示任何特别有用的内容,仅仅是IP范围归Amazon / Twitch所有。 视频编码器:Twitch的(可能)编码器 试图弄清楚Twitch正在使用的编码器也是具有挑战性的。首先,我们可以尝试使用我们之前使用的相同方法来转储hdlr框的内容,但遗憾的是它给了我们一个非常笼统的答案: mp4dump --verbosity 3 twitch-init.mp4   [hdlr] size=12+33 handler_type = vide handler_name = VideoHandler 然而,我们可以根据Twitch员工公开发表的谈话进行假设。去年在Streaming Media East盛会上,Yueshi Shen和Ivan Marcin就Twitch的上一代和下一代转码架构进行了精彩的讲解。在这次演讲中,Yueshi谈到了他们的新架构是如何围绕英特尔的Quick Sync且基于成本,稳定性和视觉质量的组合上构建的。我认为最佳的假设就是Twitch正在使用他们常用的Quick Sync编码器链进行视频编码。 Twitch — 推测架构 警告:一些预先推测。 在这个阶段,我们已经尽可能的学习,但没有获得有关Twitch如何构建的内部知识。我再次提出了一个理论架构图,我认为这就是Twitch如何在内部布局的。 我提供的评论是,在这种情况下,一切都是Twitch专有软件,这并不是非常令人震惊的,但是可以肯定地说Twitch的方法在延迟方面独有优势,我将会在下一节中进行讨论。 用户体验 如果我没有提到最终用户体验,我认为很失败。从最终用户的角度来看,这两种服务之间的体验是不矛盾的且具有可比性。对于我来说—至少在相当稳定的互联网连接上—视频流畅,在任何平台上都没有缓冲或视觉质量问题。 但是,我想强调的是:两个平台之间有一些显著不同的终端用户体验。 延迟 在观看游戏时,显然Twitch流明显领先于Amazon Prime Video流。不幸的是,在我们的实验中,我们无法访问有线电视流以验证传统广播的差异,因此我无法准确估计我们正在讨论的挂机有多远,但我可以给出一些比较数据。 为测试相对延迟,我刷新了两次流,让流时间稳定下来,然后在Twitch流上采用可视标记,启动我的秒表,并等待Amazon Prime流追赶相同的视觉标记。 流之间的差异相当惊人。平均而言,Twitch流比亚马逊Prime流提前12秒。在一些尝试中,差异仅为10秒,而在其他尝试上则为16秒。 这非常值得深究。在10月的LiveVideoStackCon 2018上,Twitch Principal Research Engineer沈悦时介绍了通过HLS实现的低延迟直播。 如果我们从今年早些时候Akamai的Will Law对Demuxed的“低延迟流”的定义中,我们可以看到Twitch和亚马逊现在大致落在哪个规模上。 现在让我们说亚马逊的挂机延迟时间约为10-15秒,Twitch约为5秒。Will将把亚马逊描述为坚定在“遗产延迟范围”,而Twitch则处于“低延迟范围”的前沿。 在这个特殊的情况下,Twitter有很长的路要走,亚马逊需要有一些追赶。 平台覆盖 我还想提一下在研究这篇文章时我注意到的另一件事。Twitch为《周四橄榄球之夜》添加DRM似乎对该流可用的平台产生了影响。 正如Twitch在自己的博客上指出的那样,流媒体“可在网络和移动应用上使用” ——这意味着Twitch传统上达到的一大堆平台(包括Chromecast,PS4和XBox One)目前并不支持他们的《周四橄榄球之夜》视频流。这与Amazon Prime Video的平台形成鲜明对比,在这个平台上,在亚马逊有Prime Video应用程序的任何地方直播似乎都可以使用。 总结 哇,很长的文章,祝贺你学习这么久!鉴于我们已经完成的工作,我总结了以下每个实现的关键技术细节: 作者注:此数据仅适用于提供给桌面浏览器的视频。其他技术可能会用于某些本机设备,特别是iOS应用程序。 现在进行一些评论。在构建块级别,该架构实际上看起来非常不同,但这里使用的是相同的基本方法,即使技术堆栈的细节有所不同。 两种方法都使用H.264和AAC,两者都使用受Widevine和Playready保护的2秒fMP4片段,两者都使用基于清单操作的SSAI插入策略。但是,Twitch的内部编码,CDN和封装架构使他们能够以更高的帧速率提供更低延迟的流。而亚马逊具有显着更高的顶级比特率和更全面的设备占用空间的优势。 虽然亚马逊的方法非常依赖AWS Elemental的产品,但它也是一个很好的参考架构——他们可以使用AWS Elemental产品套件进入市场并说“嘿,它应用于《周四橄榄球之夜》”,那在高端直播流媒体市场中是非常有价值的。 最后一个想法。在Twitch上花费近10亿美元之后,在观众延迟显着降低的情况下,如果Twitch的方法似乎提供了相同的体验质量(这对于直播体育是至关重要的),那为什么亚马逊不将其用于它们的Prime Video流呢?     想要阅读更多技术干货文章,欢迎关注网易云信博客。 了解网易云信,来自网易核心架构的通信与视频云服务。 网易云信(NeteaseYunXin)是集网易18年IM以及音视频技术打造的PaaS服务产品,来自网易核心技术架构的通信与视频云服务,稳定易用且功能全面,致力于提供全球领先的技术能力和场景化解决方案。开发者通过集成客户端SDK和云端OPEN API,即可快速实现包含IM、音视频通话、直播、点播、互动白板、短信等功能。

2018-12-03

技术玩法大升级,网易MCtalk揭秘社交产品背后的秘密

随着互联网和科学技术的发展,自媒体、数据、和机器算法重构了内容分发,改变了娱乐产品、社交产品的格局。在新技术业态下,社交风口不断涌现,除了微信、QQ等行业巨头外,各类细分场景的APP也逐渐开始呈现崛起之势。11月24日,网易 MCtalk技术沙龙——“娱乐社交APP的AI探索、架构与性能优化实践”,邀请到网易云信、小红书、Bilibili、网易云音乐研发负责人,共同分享爆款娱乐社交APP的技术玩法,探讨如何用技术推动社交产品的创新和迭代。   现如今,音视频技术玩法不断升级、应用场景也在不断增加,音视频应用已经融入到每一个人的日常生活中。从独立应用到嵌入式应用,智能硬件、APP,甚至Web程序中的许多模块,也都越来越依赖于音视频技术,音视频技术的重要性可见一斑。 网易云信音视频架构负责人Volvet在技术沙龙上针对实时系统中视频质量的相关知识进行了全面分享,从音视频编解码领域谈论到深度学习。谈及为什么需要在音视频领域应用深度学习,他和我们分享了四个原因:首先,传统的算法难以解决目前音视频领域遇到的挑战;其次,深度学习可以通过学习来得到像素特征;第三,神经网络具有逼近任何函数的能力,理论上可以拟合出我们所期望的函数;最后,也是最重要的一点,硬件运算能力的提升: GPU, TPU, A11 Bionic等,这种硬件处理能力的成熟为深度学习在云端上的使用铺平道路。 ​ 对于社区和电商来说,借助大数据和机器学习实现的个性化分析和推荐是平台存活和发展的命脉。而对于小红书——一个信息发现和分享的平台来说,基于大数据的个性化推荐更为重要。从用户购物行为分析,到社区信息分析、笔记分析,小红书如何从0到1搭建机器学习系统? 在MCtalk技术沙龙上,小红书研发负责人姚旭从数据流特征谈起,为大家进行了详细的介绍。沙龙中,姚旭用理论结合实践,分析了具体的排序模型与数据工具。此外,他对于“技术到底有没有价值观”发表了自己的看法。姚旭认为,技术产品本没有界限,是优化的目标决定了给用户带来什么样的价值。产品上需要想办法引导用户留下利己利他的环境,UGC社区需要考量作者和读者的双边价值,这就是个性化推荐场景下的价值观。 ​ 作为中国覆盖范围最广、知名度最高的视频弹幕动漫平台,Bilibili早在2017年用户量已经过亿。如今,拥有数亿用户体量的B站如何保持高稳定性、高可用性以及低延迟?在100倍系统容量扩增的情况下,B站进行了哪些视频业务实践,又得到了什么经验? Bilibili研发负责人周全在沙龙现场和我们分享了如何从0搭建B站视频云,从B站的点播解决方案到视频上传、转码处理及播放器的解决方案,周全详细介绍了B站在点播视频上的迭代实践。现场,周全分享了自己关于视频云技术的四个观点:第一,业务第一,够用就好,对业务的理解决定了你能走多远;第二,持续迭代,以用户为本,你看到的数据不一定是用户体验,用户投诉才是赤裸裸的需求;第三,QA管控,线上与线下同样重要;第四,是研发、运维,也是运营,服务渠道全链路监控非常重要。 ​ 2018年6月,短视频用户规模达到5.95亿的最高峰,经历了2017年短视频行业的持续火热,2018年,短视频市场仍然保持着高速增长的状态。从技术角度分析,短视频的流行是移动处理器技术,编解码和流媒体传输技术,移动网络技术共同发展由量变到质变的结果,而视频技术的发展又为其质量评价提出了新的课题。 MCtalk技术沙龙中,网易云音乐眭世晨从短视频发展趋势说起,详细介绍了网易云音乐如何基于多特征融合+机器学习的视频质量评估方法,客观准确地评估视频质量以及自动化的视频内容分析。他提到,短视频质量的评估方法主要分为主观质量评价和客观质量评价,但是因为视频最终是给人看的,所以我们要跳出分辨率、帧率、码率这些客观标准,最终转化为主观评价。谈到质量评估的目标,他表示,一方面在于动态地在不同板块间调整质量和成本;另一方面在于不片面地追求分辨率,而是以实际感受画质为准;另外,调整规则不是人为基于经验指定的,而是基于一套完整的算法和机制动态计算出的最优解。 产品迭代更新的背后,是技术玩法的不断升级。在技术的推动下,娱乐社交产品迎来新的增长风口,场景愈加丰富,模式更加多元化。我们期待技术能够为用户不断创造新的产品体验,而网易云信,作为底层技术服务商,也会为娱乐社交产品提供强有力的技术支持,提供最稳定可靠的技术保障。   想要阅读更多技术干货文章,欢迎关注网易云信博客。 了解网易云信,来自网易核心架构的通信与视频云服务。 网易云信(NeteaseYunXin)是集网易18年IM以及音视频技术打造的PaaS服务产品,来自网易核心技术架构的通信与视频云服务,稳定易用且功能全面,致力于提供全球领先的技术能力和场景化解决方案。开发者通过集成客户端SDK和云端OPEN API,即可快速实现包含IM、音视频通话、直播、点播、互动白板、短信等功能。

2018-12-03

教育场景下的实时音频解决方案

本文来自网易云信 资深音频算法工程师 李备在LiveVideoStackCon 2018讲师热身分享,并由LiveVideoStack整理而成。在分享中李备详细分析了在线教育的音频需求,以及一般软件音频框架,和行业的挑战。 大家好,我是来自网易云信的李备,今天我将与大家一起探究教育场景下的实时音频解决方案。 本次分享将围绕以下几部分进行: ​ 1. 实时音视频的市场需求 1.1 市场观察 随着我国互联网行业的蓬勃发展与宽带水平的提升,消费者早已不满足于通过简单的文字图片浏览新闻,而是期待通过更佳生动精彩的音视频获取知识了解世界。根据网易云信平台观测的数据,音视频社交应用时长在近两年呈现飞速增长,随之增长的同样还有中国在线教育市场交易规模,从2010年至2017年增长近10倍,并预计在2018~2019年保持增长。 可以说,实时音视频技术助力众多产业转型升级,并使得视频会议等经典应用场景重获新生。众多的新兴场景与行业借助实时音视频技术实现了更佳丰富炫目高效准确的场景表达与业务落地,同时也进一步促进了实时音视频的技术演进与行业探索。实时音视频正在各个千亿、百亿市场快速发展并逐渐成为基础设施型重要技术。 1.2 应用场景 ​ 我们的音视频行业主要存在以下应用场景:以网易公开课为代表的点播,以Finger为代表的直播,以网易云课堂为代表的互动直播与以各种P2P、小班教学、大型培训为代表的实时音视频。 ​ 1.3 直播/点播框架 下图展示的是直播与点播的技术框架。 ​ 而与上述直播/点播框架不同的是,互动直播框架更加强调音视频的实时性与强互动性。 来自Web 端连麦观众的音频数据会通过WebRTC网关传输至实时音视频中转服务器,并在此与来自手机连麦观众和PC端主播的音视频数据一起由实时音视频中转服务器转发至互动直播服务器。 互动直播服务器会对这些数据做合成/推流处理,传输至融合CDN流媒体服务器,由流媒体服务器推送数据给观看互动直播的普通观众。 与此同时,实时音视频中转服务器同样负责手机连麦观众与PC端主播的直播互动数据交换,从而实现互动直播的效果。 ​ 2. 软件层实时音频解决方案 2.1 实时音框架的线程模型与数据驱动方式 ​ 上图展示的是实时音频的简单框架线程模型,这里需要提醒的是,其中的解码主要由客户端完成,实时音的服务端不参加解码而是把来自各端的数据包筛选之后传递给其他端。 我们以音乐教学场景为例,学生与老师正在上课,此时来自学生的音频信号被其移动终端采集模块采集,经过混音消除、降噪、自动增益控制等音频的前处理过程,由音频编码器进行编码。 这里的编码器主要分为专属语音编码器与音乐编码器。音频数据经过编码器的编码处理后会被发送至网络,此时接收端会收到一个缓冲抵抗网络抖动的Jitter Buffer。解码后的音频数据经过快慢速调制与TSM后进行后处理,最后播放。播放时产生的回声会被捕捉并重复上述流程。 在硬件层面,终端制造商对音频处理流程中所需要的硬件都有一套同一切完善的参数调整经验,例如麦克风的采集帧率、拾音距离、回声延迟等都有统一规范;而考虑软件层面的实时音频则需面临设备数量庞大的难题,我们需要统一海量设备与不同平台的复杂数据输入并且考虑到软件层面的不可预知性,也就是我们需要一个完善的音频处理系统,优化各模块之间的协同工作并保证算法的稳定性。因此在这里我向大家展示一下WebRTC线程模型的设计和数据驱动方式:不同的颜色代表不同的线程。 首先,音频数据被采集模块采集后进行音频前处理,之后经由交付Buffer被交至音频Codec进行编码。(这里强调的是,我们不把音频Buffer和Codec放在一个线程的原因是音频Codec的实时性计算量要求较高,需要单独的一个线程运行。而经过网络发送时一般网络线程是直接将数据传输至Audio Jitter Buff-er,Audio Jitter Buffer获取数据后会在网络线程上接收数据包,并更新网络统计和策略,而playback的callback请求往上回调至Audio Jitter Buffer请求数据过程是运行在Playback的Callback线程上。 经过解码后音频数据会进行TSM、MIX等(如果是处理多路MIX,有些厂家可能会使音频解码单独在一个线程上运行,这一点视应用场景而定,如果是处理一路MIX则可以简单地运行在播放线程上。)关于其中的驱动方式,一些开发者喜欢使用Timer机制驱动数据,但这在实时音频框架中并不推荐。以Audio三维算法处理为例,音频每一帧处理需要大约10毫秒的时间,对时间的精度要求很高;而简单的Timer驱动无法满足这种高精度,尤其是在复杂的系统中很容易出现延迟,这为整个音频处理系统带来的影响无疑是毁灭性的。因此我们一般采取将驱动运行在系统(回调)中的解决方案,因为系统(回调)的高优先级可确保整个系统的稳定运行。Google就曾经在I/O大会上面推荐把audio process放到系统的采集播放线程里 ;右侧展示的主要有两个系统:收包网络系统与底层的用来驱动音频解码、后处理、MIX的Playback。一个音频引擎框架的稳定性直接决定了其输出声音的质量与实时性。 2.2 音频前处理框架 ​ 捕捉到的音频数据会进入Audio 3A处理。其中Audio 3A由AEC、ANS、AGC组成。不同的应用场景三者的处理顺序也不同,如在WebRTC中音频数据回依次经过AEC和NS 或者 NS 与AECM(AECM 是WebRTC专门为移动端打造的算法,计算量低,而AEC 是为PC打造的)。 而在AEC(回声消除算法),为什么需要这个算法呢?当一个设备在播放声音经过空间中的多次反射会被麦克风再次捕捉并采集到系统当中,这时音频的输入既有空间反射的回声也有本端说话声,如果缺少此模块就意味着通话中说话人一直可以听到自己的声音回来,这是非常差的一种体验,这当然是需要我们避免的。 这里AEC的作用就是通过播放的参考信号跟踪出回声并从采集信号中把回声消除掉,随后再经过降噪处理去除噪声。而其中的AECM是在NS模块之后通过获取clean与noise数据进行分析,AEC则是NS模块之前直接获取noise数据进行分析。音频数据完成AEC与NS的处理后会进行AGC处理,其包括AAGC(模拟域的自动增益控制)与DAGC(数字域的自动增益控制)。 其中AAGC的主要作用是通过系统的采集音量设置接口调整输入信号(大多用于PC端,移动端一般没有输入音量的系统接口),如借助Windows上的的API调整采集音量等参数。AAGC可为输入的音频数据带来明显的质量优化,如提高信噪比,避免输入信号溢出等。但由于我们服务的跨平台要求,我们需要构建一个面向多平台设备的框架,在不同的输入平台和设备都会有不同的输入音量,DAGC可以根据对输入信号的跟踪,尽量的调整信号到达期望大小(幅值或能量),从而避免不同设备采集带来的音量差异过大。完成AGC处理的音频数据,即可进入Audio Encode进行编码操作。 ​ 这里我想特别介绍一下Audio Jitter Buffer,由于视频的发送码率较高容易对网络造成较大冲击比较大,而音频在窄带与中等码率的情景下的发送码率在50KBPS上下,不会为网络带来较大压力,很多厂家在做音频QOS的时候并不会控制发送带宽(因为宽带的音频带宽不高,对于网络拥塞贡献不大),而把重点工作都放在接收端的jitter buffer策略上。但我们的人耳对连续性非常敏感,一旦有包没能及时传递出现丢包,那么观众就可体验到瞬间的卡顿,这种频繁的卡顿会让用户体验大打折扣。 因此我们需要一个抵抗抖动的Buffer来抵抗网络抖动的冲击,从对Delay要求高、平滑稳定过渡的角度考虑我们希望选择较长的Buffer,而从实时性出发我们又希望尽可能缩短buffer。 为了平衡网络抖动与实时性,我们引入Audio Jitter Buffer进行处理。一般用来在接收端控制网络抖动,而在不同模式下采取的抗抖动方案也不尽相同。Jitter Buffer框架与其包含的模块展示在这张图中,其中黄色代表网络线程。Audio Play Callback的数据首先传输至Manager,同时上传一些必要信息,此时音频数据会经过Jitter Policy处理传输至Audio Decode并在播放端触发callback,再由Callback驱动整个抓包流程。JitterBuffer请求包时会根据Jitter Policy进行音频解码或PLC/CNG、Slience等。最后经过后处理与MIX的反复处理,数据被传输至Audio Play Callback。 不同厂商的Jitter Policy处理方案也不一样,如较为出名的WebRTC NeTEQ算法,其中集成了自适应抖动控制算法以及语音包丢失隐藏算法。除此之外, JitterBuffer在跟踪预测准每一个包的jitter的时候,也需要考虑实际的缓存播放策略,比如三个包的jitter 分别是100ms,50ms和150ms,如果每次都紧跟预测的jitter,当第一个包来的时候需要缓存100ms,然后第二个包来的时候发现只需要缓存50ms,实际缓存多了需要TSM 调整,直到第三个包来,发现要缓存的又要变化了,又需要需要TSM 调整,那么这样最后的效果将是非常糟糕的。JitterBuffer的目标就是缓存适合的数据可以抵抗网络jitter的抖动,自适应既要兼顾考虑时延,又不能变化过于频繁破坏声音体验,也不能不跟不上网络变化造成缓存不足造成丢包。 3. 行业痛点 ​ 音频行业之痛主要是复杂的网络对音频的冲击与碎片化的终端设备背后差距悬殊的硬件。尤其是对Android平台而言,软件层面不同厂家定制系统的处理流程、硬件层面手机的工业设计、处理器、传感器等都不相同,难以用统一的平台解决方案处理这些设备的音视频问题,主要体现在算法的挑战难度上;与此同时,我们希望算法鲁棒性更强,这就意味着需要考虑更多的案例,而算法不可能考虑到所有的案例,我们必须根据实际情况进行相应取舍……这些都是在未来亟待解决的行业痛点。   想要阅读更多技术干货文章,欢迎关注网易云信博客。 了解网易云信,来自网易核心架构的通信与视频云服务。 网易云信(NeteaseYunXin)是集网易18年IM以及音视频技术打造的PaaS服务产品,来自网易核心技术架构的通信与视频云服务,稳定易用且功能全面,致力于提供全球领先的技术能力和场景化解决方案。开发者通过集成客户端SDK和云端OPEN API,即可快速实现包含IM、音视频通话、直播、点播、互动白板、短信等功能。

2018-12-03

数据科学真的是一份有前途的工作吗?

本篇文章翻译整理自Sethuraman Janardhanan博士的演讲。 Sethuraman Janardhanan博士,Happiest Minds Technologies的大数据分析实践主管和客户负责人,负责管理北美大数据分析领域的战略客户。 由于无处不在的计算设备和新时代的颠覆性技术的革命,大数据已成为业务中不可或缺的一部分。数据的指数级增长为企业提供了商业智能的巨大机会。然而,大数据的挑战在于收集,隔离,分析和推导可操作的商业智能和来自大量结构化和非结构化数据的见解。具有强大技术背景,在计算机编程,数学和统计方面具有强大技能的专业人士,可以处理大量数据,清理,组织和获得有意义的见解并在业务中实施它们。组织逐渐意识到数据在商业中的重要性,并且正在见证市场对数据科学专业人员的巨大需求。毫无疑问,数据科学被“哈佛商业评论”评为21世纪最热门的领域之一。 麦肯锡的一项研究报告称,“到2018年,美国将缺少190,000名技术熟练的数据科学家,150万经理和分析师能够从大数据洪流中获取可行的见解”。从印度来看,我们可以看到组织内部对大数据和数据科学的极大兴奋。印度公司已开始寻找能够为其业务增值的合格数据科学专业人士。然而,目前在大数据和数据科学领域存在巨大的需求 - 供应不匹配。由于每个业务部门和行业都确定了大数据分析的相关性并希望在竞争中保持领先地位,因此对数据科学专业人员的需求将呈上升趋势。 数据科学家作为价值加法器 数据科学家解决了企业可能面临的一些最棘手的问题,并且几乎涉及所有业务领域。下面简单为大家介绍数据科学家如何在各个行业领域增加价值。 营销 - 在营销业务中,数据科学家可以利用大量数据来优化营销支出并提高其广告系列的投资回报率,从而提高广告系列的响应率。 银行业 -在银行业的舞台上,风险职能部门的数据分析师可以利用大数据识别欺诈活动,并采取富有洞察力的措施全面覆盖风险。 零售 -数字和电子商务运营是应用大数据分析进行业务优化的前沿。数据科学家可以在该领域中发挥重要作用,分析通过各种手段收集的消费者数据,从而识别客户行为。根据分析,零售商可以提供有针对性的个性化建议,以帮助增加客流量,从而提高销售转化率。 制造业 -数据科学也在制造业中发挥着重要作用。通过利用他们的技能,数据科学家可以预测产品需求并优化业务的库存供应链。 数据科学职业前景和技能 虽然编程技能和统计专业知识被认为是任何数据科学家的基础,但强大的商业头脑有助于他们在正确的轨道上驾驭他们的职业生涯。然而,随着数据科学日益成熟,以及围绕大数据的业务需求的变化,对数据科学家的技能和能力的期望也在不断提高。随着机器学习,深度学习,高级分析和认知计算之间相关性越来越大,这一要求已从传统的商业数据科学家转变为先进的机器数据科学家。 业务数据科学家理解业务,并基于通过适当的工具或框架从不同源获得的数据构建数据模型。他们发现隐藏的洞察力来解决商业问题或提供竞争优势。然而,就机器数据科学家而言,除了弄清楚隐藏的见解之外,这些对系统的见解的实施也是他们的责任。 以前,工商管理和数学、统计技能主要适用于数据科学专业人员。然而,机器数据科学家的理想技能是深入的编程技能,深入的分析技能,机器学习技术和统计技能以及强大的商业敏锐性。分析问题解决,求知欲,行业知识,批判性思维,有效的沟通和数据科学与分析认证将是额外的优势。 SAS和SPSS是商业数据科学专业人员必须了解的主要技术。Java,Python,Scala是大数据应用程序中最常用的编程语言。对于机器数据科学家来说,所需的技能包括编程语言知识,Hadoop,Hive,Spark,用于构建自定义模型和算法。此外,数据科学专业人员应熟悉SQL知识,因为大多数企业数据都存储在数据仓库中 对有抱负的数据科学专业人士的建议 ●深入学习一种编程语言 ●培养您的SQL技能和数据准备技能 ●完成统计建模和算法技能 ●与实施它的工具和技术相媲美对于数据科学专业人员而言,在履行其工作的主要职责(包括数据准备,统计建模和算法开发,Insight生成)时,关注业务成果同样重要。以及在业务中部署见解。 数据科学的未来前景 随着数据科学成为业务增长和成功的关键推动因素,每个公司的CXO都无论需求量大,都需要拥有足够数量的数据科学专业人员。未来的CXO将在未来十年内将数据科学作为理解高级模式和趋势的关键要求。根据印度经济的实力以及庞大的人才储备,印度在未来几天可以在培养数据科学专业人员方面占据重要位置。然而,从组织方面以及印度大学方面采取更周到的步骤和及时的行动计划是时间的需要。 机会是无限的,数据科学将成为未来五年中最受追捧和最高薪的职业之一。每个行业和职能部门都将数据科学嵌入其运营中。总而言之,题为“2016年4月数据科学家工资”的Burtch Works研究报告“数据科学家的基本工资中位数随着个人贡献者和管理者的工作水平而增加。1级个人贡献者的基本工资是其他IT专业人员的1.5到2倍。对于经理而言,与IT经理相比,这些薪资水平可高达3倍。“ 原文地址:https://medium.com/@humancapitalmagazine10/career-in-data-science-the-prospects-4d6b8b3b1506 翻译:网易云信   想要阅读更多技术干货文章,欢迎关注网易云信博客。 了解网易云信,来自网易核心架构的通信与视频云服务。 网易云信(NeteaseYunXin)是集网易18年IM以及音视频技术打造的PaaS服务产品,来自网易核心技术架构的通信与视频云服务,稳定易用且功能全面,致力于提供全球领先的技术能力和场景化解决方案。开发者通过集成客户端SDK和云端OPEN API,即可快速实现包含IM、音视频通话、直播、点播、互动白板、短信等功能。  

2018-12-03

HTTP/3 来啦,你还在等什么?赶紧了解一下

互联网工程任务组(IETF)官员透露,HTTP-over-QUIC实验协议将重命名为HTTP / 3,并有望成为HTTP协议的第三个正式版本。这是由Mark Nottingham的这一原始建议引发的。 下一代HTTP底层协议将弃用TCP协议,改用QUIC技术。不过运营商网络丢UDP包这个问题可能一时半会儿比较难解决。我们玩QUIC路还很长。 IETF中的QUIC工作组致力于创建QUIC传输协议。QUIC是通过UDP完成的TCP替换。最初,QUIC起初是谷歌的努力,然后更多的是“HTTP / 2加密 - UDP”协议。 当IETF中的工作开始标准化协议时,它分为两层:传输和HTTP部分。这种传输协议也可以用于传输其他数据,而不只是显式地用于HTTP或类似HTTP的协议。但是这个名字仍然是QUIC。 社区中的人们已经使用非正式名称如iQUIC和gQUIC来指代这些不同版本的协议,以将QUIC协议与IETF和Google分开(因为它们在细节上差异很大)。通过“iQUIC”发送HTTP的协议长时间称为“hq”(HTTP-over-QUIC)。 那么Quic是什么? Quic(QuickUDP Internet Connections)是一种新的传输方式,与TCP相比,它减少了延迟。表面上,Quic非常类似于在UDP上实现的TCP+TLS+HTTP/2。由于TCP是在操作系统内核和中间件固件中实现的,因此对TCP进行重大更改几乎是不可能的。然而,由于Quic是构建在UDP之上的,所以它没有受到这样的限制。 Quic在现有TCP+TLS+HTTP 2上的关键特性包括 大大缩短连接建立时间 改进的拥塞控制 无线头阻塞的多路复用 前向纠错 连接迁移 谷歌想要Quic慢慢地取代tcp和udp作为在internet上移动二进制数据的新协议,并且有充分的理由,因为测试已经证明quic是更快和更安全的,因为它的默认加密实现(当前)。http-over-Quic协议草案使用新发布的TLS 1.3协议)。 ​ 对TCP与Quic的解释Reddit用户: TCP是在我们仍然在网络上传输数据包时开发的,网络的丢包量比现在大得多,计算机系统有更长的时间来回答TCP消息。例如,连接到主机的超时时间仍然是20秒,即使如果仅在5秒内无法完成TCP握手,也不太可能得到答案。这些长时间的延迟是网络应用有时陷入长期停滞的原因。尽管我们看到了可靠性和速度上的巨大改进,但自70年代发明该协议以来,我们还没有触及这些延迟。 协议开发人员没有最终减少这些不会改变数据包并与当前TCP实现基本兼容的缺省值,而是刚刚开始使用UDP,然后在其之上实现自己的TCP。向IPv 6的过渡也是将TCP更新到一个版本的理想时机,该版本修复了它所存在的大多数问题,主要是超时、窗口大小和TCP慢启动。有些值可以在您的操作系统中进行调整,但是超时,这是最烦人的一个不能。如果您关闭挂起5秒的TCP套接字,您的操作系统仍将保持打开状态,直到20秒过期,消耗系统资源。 参考链接: https://daniel.haxx.se/blog/2018/11/11/http-3/HTTP/3 https://medium.com/devgorilla/what-is-http-3-94335c57823f   想要阅读更多技术干货文章,欢迎关注网易云信博客。 了解网易云信,来自网易核心架构的通信与视频云服务。 网易云信(NeteaseYunXin)是集网易18年IM以及音视频技术打造的PaaS服务产品,来自网易核心技术架构的通信与视频云服务,稳定易用且功能全面,致力于提供全球领先的技术能力和场景化解决方案。开发者通过集成客户端SDK和云端OPEN API,即可快速实现包含IM、音视频通话、直播、点播、互动白板、短信等功能。

2018-12-03

【最全资料汇总】如何12个月内成为数据科学家?

RoyalMail数据科学家Freddie Odukomaiya曾经用12个月的时间让自己成功的成为数据科学家,以下是他的经验分享和他所使用的学习资源。 以下内容译自:https://blog.usejournal.com/how-to-become-a-data-scientist-in-12-months-71aa9ee822d9 想成为数据科学家,以下8点非常重要 选择一种编程语言,坚持下去。 不要不断改变你选择的语言。如果这样做,你的进度将大大减慢。 明确你的动机。 这很重要,因为学习数据科学很难,所以在过程中很容易失去动力。如果你的动力清晰而强大,那么就更容易忍受和坚持。 不要迷失在课程中。 如果你只是不断的在学习教程,你很容易陷入一种自我欺骗“我知道自己在干什么”。最好的方法是在项目中学习。找一个你感兴趣的项目,把数据科学应用其中,比如,我的项目是预测英超联赛的冠军。 精准选择小部分资源。 现在有太多学习数据科学基础知识的资源。一个普遍的现象是,大家很难坚持使用一个资源学习,很多人使用一个资源开始学习,看到了一个更好的资源后立即就更换了学习资源,这样成本是非常高的,要尽量避免这种情况。相反,我们应该选择一组涵盖不同主题的资源(例如,construct a curriculum),坚持下去,知道你完成他们 让自己沉浸在社区中。 你需要让数据科学包围自己。可以通过以下几种方式:订阅DS简报,阅读数据科学文章和书籍,收听数据科学播客,在youtube上观看数据科学讲座,通过参加所有和任何数据科学活动,利用Meetup和Eventbrite等网站。查找在线DS社区并加入他们。 去黑客马拉松! 不要等到你“准备好”再去参加黑客马拉松,参加黑客马拉松的好处远远超过你认为你会经历的任何负面影响。黑客马拉松也可以在线参与,例如,Kaggle本质上就是一个永无止境的在线黑客马拉松。 寻找导师。 这对我来说是最困难的部分,因为我对导师的定义有些许误解。导师只是一位经验丰富且值得信赖的老师/辅导员。你可以拥有多个导师,甚至可能无法直接与他们互动。我最终的导师其实是哪些有影响力的数据科学家,我通过社交媒体关注他们,订阅他们的新闻通讯,阅读他们的书籍和听他们的谈话/播客。当我觉得我需要建议时,我通过电子邮件和社交媒体与他们联系,虽然不是每个人都回复了我,但那些确实帮助了我很多。 准备好牺牲你工作日的晚上和周末。 你必须投入大量的精修勤练,花费大量时间学习,你的社交生活会受到影响。努力工作很重要,但聪明地工作更有价值,请你准备一份时间表,关于你正在学习的课程,正在阅读的书籍以及正在开展的项目。 最全学习资源汇总 充分利用这些信息资源才能更好的学习数据科学哦。 【课程】 开源数据科学大师  - @clarecorthell制作了涵盖数据科学所有不同方面的课程,并附有相关课程,书籍等的链接。 Class Central  - 这是谷歌的在线课程。您可以通过简介和用户评分找到与任何主题相关的在线课程。 DataCamp  - 一家通过互动在线课程教授数据科学的EdTech公司。 【实践】 Kaggle  - Kaggle是预测建模和分析竞赛的平台。 #100DaysOfCode  - 这是一个挑战,初学者尝试每天至少编码一个小时,持续100天。 Codewars  - 通过与其他人一起训练真实代码的挑战来提高您的技能。 DrivenData  - DrivenData让众包成为世上最大的社会挑战和组织之一。 HackerRank  - 练习编码。参与竞争。找工作。 【书籍】 Machine Learning with Python Cookbook by Chris Albon An Introduction to Statistical Learning: with Applications in R Hands-On Machine Learning with Scikit-Learn and TensorFlow by Aurélien Géron Think Stats: Exploratory Data Analysis by by Allen B. Downey The Signal and the Noise: The Art and Science of Prediction by Nate Silver Prediction Machines: The Simple Economics of Artificial Intelligence How to Lie with Statistics by Darrell Huff Automate the Boring Stuff with Python by Al Sweigart 【通讯/博客】 Data Elixir — Data Elixir每周二会发送到您的收件箱,其中包含从网络上挑选的数据科学内容。 Data Science Roundup - 互联网上最有用的数据科学文章。由Tristan Handy策划。 FiveThirtyEight  - Nate Silver使用统计分析来解决政治和体育问题的热门博客。 Variance Explained  - David Robinson的数据科学博客,DataCamp的首席数据科学家,这是一家通过互动在线课程教授数据科学的EdTech公司。 Flowing Data  - FlowingData探索统计学家,设计师,数据科学家和其他人如何使用分析、可视化和探索去理解数据和我们自己。 The Pudding  -  The Pudding通过视觉论文解释了文化中争论的观点 Datacamp  - 帮助您成为数据科学家的数据科学博客。 Kaggle Blog  - Kaggle.com的官方博客 Machine Learning Mastery  - 即使你是从0开始,也可以在真实应用程序中使用它来掌握机器学习。 Chris Albon  - 流行的Machine Learning Flashcards背后的数据科学家和Machine Learning with Python Cookbook的作者。 KD Nuggets  - KDnuggets™是业务分析,大数据,数据挖掘,数据科学和机器学习的领先站点。 Analytics Vidhya  - 了解有关Data Analytics的所有信息。 【播客】 Linear Digressions  - 在每一集中,主持人通过有趣的应用程序探索机器学习和数据科学。 Partially Derivative  - 日常生活中每天的数据,由Data Science超级极客主持。 Data Skeptic  - 介绍与数据科学,机器学习,统计和人工智能相关的主题的访谈和教育讨论。 This Week In Machine Learning and Artificial Intelligence- 迎合热爱机器学习的观众和AI爱好者。 Software Engineering Daily  - 关于软件主题的技术访谈。 DataFramed  - 通过DataCamp,专注于探索数据科学可以解决的问题。 Talking Machines  - 机器学习正在改变我们可以提出的问题,我们探索如何提出最佳问题以及如何解决问题。 Becoming A Data Scientist Podcast  - 访问数据科学家,了解他们成功的方法。 AI in Industry- 每周Dan Faggella都会采访Top AI和ML高管,投资者和研究人员。 【Youtube频道】 3Blue1Brown  - 到目前为止最好的数学教程频道。以可视方式解释复杂概念。 Brandon Foltz  - 我第二喜欢的数学频道,主要侧重于从初级到高级教学统计。 Computerphile  - 关于计算机和计算机的视频。 PyData  - PyData为数据分析工具的用户和开发人员的国际社区提供了一个论坛,分享想法,相互学习。 Sentdex  - Youtuber和程序员会提供高质量的数据科学教程。 Siraj Raval  - 与Sentdex类似,可生成有趣且信息丰富的数据科学内容。 两分钟论文  - 在2分钟内解释最新的数据科学研究论文。 Enthought  - 从SciPy等流行的数据科学会议中寻找精彩的对话和讨论。 【大家要关注】 @BecomingDataSci  - HelioCampus的数据科学家Renee Teate和流行的Becoming A Data Scientist网站和播客的创建者。 @drob  - 大卫罗宾逊,DataCamp的首席数据科学家,Tidytext软件包和O'Reilly的书籍Text Mining with R的共同作者。 @chrisalbon  - Chris Albon,流行的Machine Learning Flashcards背后的数据科学家和Machine Learning with Python Cookbook的作者。 @frankchn  - Frank Chen,Google Brain的软件工程师,负责TensorFlow。 @fchollet  - Francois Chollet,Google的深度学习。神经网络库Keras的创造者。“Deep Learning with Python”的作者。 @goodfellow_ian  -Ian Goodfellow,Google脑研究科学家,领导一个研究人工智能对抗技术的团队。Deep Learning Book的主要作者。 @jakevdp  - Jake VanderPlas,华盛顿大学电子科学研究所数据科学家。访问Google的研究员; Python Data Science Handbook的作者。 @dataandme  - 来自Rstudio的Tidyverse Dev Advocate的Mera Averick。 @math_rachel  - Rachel Thomas,Fast.ai的联合创始人和旧金山大学教授。 【在线社区】 Python for Data Science FreeCodeCamp Data Science Room Reddit's Data Science Subreddit Kaggle’s online forum #100DaysOfCode  - #100DaysOfCode Challenge参与者的Slack频道。 Stack Overflow  - 全球最大的开发者社区。   数据科学的学习是一个永无止境的过程,有了方法和学习资源最重要的一定还是坚持。 享受学习,享受知识,享受进步,大家加油鸭!!     想要阅读更多技术干货文章,欢迎关注网易云信博客。 了解网易云信,来自网易核心架构的通信与视频云服务。 网易云信(NeteaseYunXin)是集网易18年IM以及音视频技术打造的PaaS服务产品,来自网易核心技术架构的通信与视频云服务,稳定易用且功能全面,致力于提供全球领先的技术能力和场景化解决方案。开发者通过集成客户端SDK和云端OPEN API,即可快速实现包含IM、音视频通话、直播、点播、互动白板、短信等功能。

2018-12-03