【重要】网易云信互动直播录制升级公告

尊敬的网易云信用户: 为了更好地提升互动直播录制体验,避免异常通话时长对整体录制体验的影响,网易云信对目前的互动直播录制功能进行了优化——即日起,云信将上线互动直播录制切片功能,切片时长为2小时。比如一通通话的时长为2小时40分钟,录制文件将会是1个2小时的录制文件和1个40分钟的录制文件。 如果单次通话时长小于2小时,则该功能上线后录制文件不会产生任何影响。如果单次通话时长超过2小时,可以通过录制文件的命名快速定位同一通通话的不同录制文件。 如果该功能对您目前的产品体验有任何影响,可联系云信技术顾问或拨打客服热线4009-000-123。

2019-04-19

【重要】网易云信预警服务升级通知

尊敬的网易云信用户:       为了便于您能够及时获取账号的可用额度信息,避免被欠费关停,网易云信将于2019年3月21日上线可用额度预警服务,同时取消余额预警服务。       您可以登录网易云信管理控制台,设置可用额度预警阈值。当可用额度低于此阈值时,将会触发系统通知(邮件或短信通知)。      若当前账号已设置余额预警阈值,系统默认将余额预警阈值设置为可用额度预警阈值。如需修改,请登录网易云信管理控制台,重新设置可用额度预警阈值。      说明:      可用额度=账户余额-未结清金额。账户余额指最近一次扣费后账户的剩余金额,未结清金额为最近一次扣费后,使用云信功能但还未付费的部分。 感谢您对网易云信的信赖与支持,如果您有任何疑问,请联系客户经理或拨打客服热线4009-000-123。

2019-03-19

【2019新年快乐】网易云信春节期间服务公告

尊敬的网易云信用户: 新年在即,网易云信提前祝大家:新年快乐! 网易云信春节假期为:2019年2月2日-2月11日 暖心提醒: 为确保您的业务不受节假日影响,建议提前核实账户可用余额,如果可用额度较低,建议在春节前完成充值,以防服务欠费关停。 若您19年1月份有消费,为便于您核对账单,1月扣款将于2月14日完成 上班虽停,服务不打烊: 2月2日、2月3日、2月11日 的9:30-18:00,为正式客户的服务QQ群提供技术支持服务 2月1日-2月11日, 可提交工单,将在2月12日开始按照工单提交顺序为您处理 2月2日-2月11日,如遇到紧急故障,可拨打电话:0571-8985-2634,为您处理紧急故障 2月2日-2月11日,可拨打VIP客服专线:4009-000-123,咨询服务 恭祝大家新年快乐!

2019-01-30

“答题有奖”活动—中奖名单公布!!!

2019-01-23

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

    视频技术详解:语音编解码技术演进和应用选型 本文来自现网易云音乐音视频实验室负责人刘华平在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