一闪而过:将视频迁移到无闪光灯的世界

你读这篇文章的时候, 谷歌将发布铬 55, 它需要用户交互才能在桌面浏览器中运行Flash内容. 铬 54已经停止加载Flash内容，直到用户干预. 这些变化导致了业界对Flash终结的猜测. 谷歌并不是唯一一家继续扼制Flash的浏览器厂商:今年8月, Mozilla还对火狐中的Flash内容设置了更多限制.

结束我们对Flash内容依赖的战役不会因浏览器供应商而停止. 流媒体的 丹·雷伯恩(Dan Rayburn)写了一篇博客文章，详细介绍了内容分发网络(cdn) 设置生命周期结束日期用于基于rtmp的媒体传递. RTMP, 或实时消息传递协议, 是flash专用的实时视频传输工具吗, audio, 和数据. 播放器供应商，如JW Player也是如此让客户做好准备在桌面浏览器中弃用Flash. 名人甚至也加入了这一行列, 比尔·马赫在HBO脱口秀《百家乐软件》的一个环节中批评了闪电侠. 讽刺的是，Maher自己的网站完全支持Flash. HBONow.com也依赖MLBAM的基于flash的视频播放器来播放DRM内容.

请放心:如果你还没有跟上“Flash已死”的潮流，那并不意味着你疯了. 尽管我是几本Flash书籍的作者, 我的底线是客户的技术要求. 对于某些功能，Flash仍然是最好的选择, 原因很简单，因为在本地支持的浏览器堆栈中(目前)还没有其他可负担得起的一致解决方案. 基于flash的视频播放在RTMP、自适应比特率VOD和低延迟实时视频方面具有优势. 尽管它很有用, 我不得不承认，我的大多数客户都不想在任何新的解决方案中使用Flash，因为它被视为一种接近生命尽头的过时技术.

如果你是仍然相信Flash力量的顽固分子之一，我推荐你. 但是如果你的网站还在使用flash视频播放器，那么是时候停止了. 我很惊讶有多少中小型企业(SMB)站点使用FLVPlayback SWF来运行从产品演示到客户推荐的所有内容. 如果您是中小企业所有者或利益相关者，并且您不确定您的网络团队是否构建了仅flash的视频播放器, 试着在手机上加载你的网站. 如果视频不显示或显示“下载Flash播放器”链接, 你可能拥有只支持flash的玩家——你可能因此失去用户.

谁还在使用Flash RTMP?

Facebook仍然使用Flash RTMP. 你知道Facebook Live吗在其移动应用程序中使用RTMP 推送一个直播流到它的CDN? 任何进行直播的人都很可能使用RTMP将视频提要推送到媒体服务器，然后由媒体服务器处理流, 或transmux, 转换成其他非rtmp格式，如Apple HLS, Adobe HDS, 或MPEG-破折号. 例如，大多数H.264硬件编码器有实时流的RTMP发布选项, 像Telestream Wirecast这样的软件广播应用程序也是如此. Akamai、Limelight和其他cdn仍然维护RTMP端点来摄取实时流. 在大多数直播场景中, 虽然, 在桌面浏览器中不一定要使用Flash插件. RTMP可以用作移动或桌面应用程序中的传输，而不需要Flash插件.

我所接触的那些依赖于Flash插件的桌面浏览器的客户主要是从事直播业务的. 他们需要RTMP传递的低延迟特性, 因为基于http的直播流对于播放列表和视频分割有更大的开销, 哪个可以延迟30秒的直播回放. 这种类型的延迟对于实时通信来说是不可接受的, 比如拍卖直播或者视频聊天. 理查德·布莱克, Influxis首席执行官, 关于他的客户群，他是这样说的:“Influxis网络提供的所有流量中，大约有一半仍然是RTMP, 另一半主要是HLS和一些RTSP, 破折号, RTP, 和HDS. 在大多数情况下，人们将RTMP协议用于低延迟的一对多和多对多流应用程序.所以Flash仍然存在, 在没有处理延迟空间的情况下，在行动的地方展示它的肌肉，保持数据的移动. 尽管它有很多缺点, 我们必须承认，在某些情况下，Flash可以比竞争对手做得更好.

将法律, Akamai媒体部门的首席设计师, 为RTMP提供了这样的前景:“Akamai运营着世界上最大的Flash媒体服务器网络. 我们有很多客户仍然使用RTMP交付, 特别是它的低延迟特性与直播流. 随着可用Flash客户端占用空间的减少, 我们预计RTMP交付将按比例下降，并最终被使用HLS或破折号的HTTP/S交付所取代.”

为什么RTMP仍然是必要的?

那些继续使用Flash的企业只是传统系统的忠实拥护者吗, 拒绝前进? 有些企业已经在Flash RTMP系统上进行了大量投资，希望在为可能因平台而异的分散技术堆栈再次挖掘资金之前，尽可能多地获得投资回报率.

主要的障碍是没有一种实时协议可以跨所有浏览器栈使用. 有WebRTC, 我们将在下一节中进一步探讨, 随着业界继续向无flash浏览器的未来推进，这是浏览器实时化努力的唯一亮点.

与此同时，企业继续依赖RTMP来满足他们的视频需求. 克里斯·诺尔顿饰演, Wowza Media Systems的副总裁兼流媒体行业传道者, 说, “Wowza的客户历来都是RTMP的大用户. 在过去的12个月里，Wowza已经有超过1000个新客户部署使用RTMP交付. 虽然大多数新部署使用HLS和其他自适应比特率流格式进行交付, 我们仍然看到很多客户依赖RTMP, 这主要是由需要低延迟视频和双向数据流的流用例驱动的.”

迎接(浏览器)替代品

如果您的视频客户没有Flash插件会发生什么, 或者它不允许在桌面浏览器中运行? 根据您的视频内容，这将是两个因素的问题:编解码器和格式.

首先，让我们谈谈编解码器. 目前几乎所有使用的HTML5桌面和移动浏览器都有原生AVC/H.264 video and AAC audio decoders. 仅这一点就值得庆祝，因为您的内容很可能已经用这种格式编码了. 然而，当我们走向超高清和4K的未来时，尚不清楚H将采用哪种编解码器.今天的264. 我们要感谢Flash，它将H凝聚在一起.264，在浏览器无法播放时支持播放. 目前，VP9是HEVC/H的有力竞争者.265，后者的采用似乎陷入了多个专利池的法律问题. 值得庆幸的是, UHD and 4K is still very bleeding edge; when it comes to the use cases for RTMP and live streaming, 大多数广播公司受到现场可用带宽的限制, 因此，720p是“高端”画质.

关于编解码器的一个更大的问题是，使用VP8扩展部署是否会影响您的底线. VP8(和VP9)的好处是，目前大多数非苹果浏览器都有内置的解码功能. VP8和VP9是免版税的，通常可以比典型的H更好地压缩内容.264/H.265编码预设. 在没有原生H.264解码，你可能会接触到更多没有安装Flash的观众. 但, 旧的浏览器也不太可能有flash禁用功能，而现在越来越多的浏览器都有.

浏览器替代品中比较棘手的部分是视频内容的格式(或容器). 以下格式包含了当今大部分的在线内容:

MP4: MPEG-4文件格式是H的典型容器.264(和H).265)流. 如果你有简短的内容(少于5分钟), 你可以编码你的视频内容，并通过HTTP从一个标准的web服务器. 像这样, 你可以相对便宜地从Amazon Web services S3和/或CloudFront等云服务中传输内容.
WebM: 此文件格式用于VP8/VP9和Vorbis编解码器, 目前包括Edge在内的浏览器对它的支持越来越广泛, 火狐, 铬, 歌剧, 和Android浏览器. WebM文件可以像MP4文件一样在标准HTTP服务器上使用.
HLS: 苹果为H创建了HTTP 在线直播 (HLS)容器.264/AAC可以轻松扩展自适应比特率VOD或直播流的大规模部署. 所有苹果浏览器, 包括Safari桌面、移动和原生iOS应用程序, 支持HLS播放. (苹果要求视频流iOS应用使用HLS来播放较长的视频内容，这有所帮助.) MP4文件可以转换为MPEG-2 TS文件段并存储在标准HTTP服务器上(参见MP4项目符号). HLS的主要回放好处是许多供应商已经在他们的浏览器技术中构建了HLS兼容性, 从谷歌Android到微软Edge.
MPEG-破折号: 而苹果创造了HLS, 这个行业的其他人, 包括苹果, 围绕着一个新的规范, MPEG-破折号(基于HTTP的动态自适应流), 在2011年被批准为国际标准. 这种碎片视频传输的新兴标准今天终于成为现实. 该规范与编解码器和容器无关. MPEG-破折号要解决的最大问题是播放，而移动浏览器本身支持HLS播放, 破折号清单需要JavaScript代码库来加载清单和解析视频片段. 简而言之, 显然，大多数浏览器都不能将MPEG-破折号 URL识别为MP4或HLS等本地格式. 破折号是Adobe的OSMF(开源媒体框架)的近亲，因为它依赖于本地HTML5媒体源扩展(MSE)和加密媒体扩展(EME)来在浏览器中工作, 就像OSMF需要Flash插件才能工作一样. 与以前相比，开发人员可以更好地控制视频加载和MPEG-破折号的比特率切换. 然而, 最近来自MPEG-LA关于MPEG-破折号实施许可成本的消息可能会阻碍其在行业中的接受, 参见Jan Ozer的文章).
WebRTC: 这个新标准解决了之前由Flash的RTMP实现的视频传输的“实时”方面的问题. 实时HLS和破折号流都容易出现高延迟，因为视频片段需要在服务器上排队，然后才能传送到客户端进行播放. 您可以减少需要在服务器端排队的片段数量, 但是潜伏期会, 至少, 等于你的一组图片的大小(GoP), 或者关键帧间隔. 进入WebRTC. 这种基于TCP或UDP的新传输方法在客户端之间保持开放的套接字连接. 更重要的是, WebRTC可以从桌面或移动浏览器访问本地摄像头和麦克风设备. 无需任何插件，您可以直接从支持webrtc的浏览器的范围内进行直播. 正如本文前面所暗示的那样，WebRTC缺乏关键的供应商:苹果和微软. 虽然谷歌和Mozilla支持WebRTC已经好几年了, 苹果还没有将WebRTC添加到Safari桌面或移动端. 微软在Edge中提供了一个名为Object RTC(或ORTC)的变体, WebRTC的许多方面都可以在ORTC中使用.