图片 5

H5直播起航,浏览器大战能消停吗

H5直播起航

2016/10/31 · HTML5 ·
开发

原文出处:
凹凸实验室   

图片 1

HTML5标准制定完成,浏览器大战能消停吗?

2014/10/30 · HTML5 ·
HTML5

原文出处: 虎嗅网   

昨天,万维网联盟(W3C)宣布,经过将近8年的艰辛努力,HTML5标准规范终于最终制定完成并已公开发布。

狭义上,HTML5是HTML的第五个版本。HTML的全称是超文本标记语言(HyperText
Markup
Language),由万维网的发明者蒂姆·伯纳斯·李设计,是为创建网页而设计的一种标记语言。HTML利用标签来描述内容的语义,使计算机能够通过识别标签来正确处理内容。

图片 2

广义上,HTML5是HTML5、CSS3、Javascript
2.0的统称,因为对于现在的互联网开发而言,这三者是密不可分的。HTML用于描述内容,CSS用于定义样式,Javascript用于实现功能。

HTML是互联网的基石,目前互联网上所有的网页都是用HTML写成的。但是HTML标准的演化速度却远远跟不上互联网的发展。事实上,上一个HTML标准HTML
4.01发布于1999年12月24日,已经严重阻碍了互联网的发展。

2004年,由Firefox、Opera、Apple、Google四大浏览器厂商组成的网页超文本技术工作小组(Web
Hypertext Application Technology Working
Group),即WHATWG,宣布制定下一代HTML标准,即HTML5。而当时的万维网联盟(W3C)正在发展在XML和HTML基础上设计的XHTML。

于是,W3C和浏览器厂商的第一次大战开始。互联网的未来究竟是由标准组织W3C决定还是由浏览器厂商决定?这场大战的决定性因素在于开发者们站在哪一边。结果很明显,开发者们当然会站在浏览器那边,毕竟浏览器是普通用户接触互联网的唯一途径。W3C于2007年接纳了WHATWG的HTML5草案,并成立了新的HTML工作团队。

然而,在2012年,W3C和WHATWG再度分道扬镳。而两者的分歧在于WHATWG
集中于演进“living”标准,而 W3C
坚持使用传统的数字编号系统定义静态的“snapshots”。
WHATWG希望构建互联网的最后一个标准,即一个随着互联网发展不断更新的HTML5标准。他们认为W3C的HTML5标准一旦制定完成,即便出现错误也无法修正。而且他们认为W3C的标准制定模式太过复杂,每一代标准的制定时间过长,不符合互联网的发展速度。

所以,HTML5现在有两个标准,一个由W3C制定,一个由WHATWG制定。这会导致W3C和浏览器厂商的第二次大战吗?

当然不会,对于浏览器厂商来说,赢得浏览器之战比HTML5标准更重要。自从Google的Chrome重新掀起浏览器间的大战之后,每一家浏览器都在根据自己的情况支持HTML5标准,每一家浏览器的广告都在吹嘘自己对HTML5标准的支持。

所以,HTML5的标准已经成为了既成事实,W3C的HTML5标准只是对这个既成事实的官方认证而已。

那么,既然有了HTML5的官方标准,浏览器大战总该消停了吧。事实上,这场大战依然在延续,而开发者们依然需要为各大浏览器适配网页。

举例来说,HTML5标准设计了<video>标签,使得浏览器可以不借助Flash直接播放视频文件。但是,HTML5标准却没有规定浏览器支持的视频文件格式。现在,Firefox主推Ogg,Chrome主推WebM,Safari主推H.264。也就是说,开发者如果要使用<video>标签,需要准备多种格式的视频文件。好消息是现在似乎H.264占据了上风。

一次编写,到处运行(Write once, Run
anywhere)是每一个程序员的梦想。当年的Java没有做到,原本程序员们指望Web标准能够做到。然而事实上是,只要浏览器大战没有消停,HTML5也做不到。

赞 收藏
评论

图片 3

使用 SVG 输出 Octicon

2016/03/18 · HTML5 ·
SVG

原文出处:
aaronshekey   译文出处:[百度EFE

  • Justineo]()   

GitHub.com 现在不再使用字体来输出图标了。我们把代码库中所有的 Octicon
替换成了 SVG 版本。虽然这些改动并不那么明显,但你马上就能体会到 SVG
图标的优点。

图片 4

Octicon 上的对比

切换到 SVG
以后,图标会作为图片渲染而非文字,这使其在任何分辨率下都能很好地在各种像素值下显示。可以比较一下左侧放大后的字体版本和右侧清晰的
SVG 版本。

前言

前不久抽空对目前比较火的视频直播,做了下研究与探索,了解其整体实现流程,以及探讨移动端HTML5直播可行性方案。

发现目前 WEB 上主流的视频直播方案有 HLS 和 RTMP,移动 WEB 端目前以 HLS
为主(HLS存在延迟性问题,也可以借助
video.js 采用RTMP),PC端则以
RTMP 为主实时性较好,接下来将围绕这两种视频流协议来展开H5直播主题分享。

为何使用 SVG?

一、视频流协议HLS与RTMP

图标字体渲染问题

图标字体从来只是一种 hack。我们之前使用一个自定义字体,并将图标作为
Unicode 符号。这样图标字体就可以通过打包后的 CSS
来引入。只要简单地在任意元素上添加一个
class,图标就可以显示出来。然后我们只使用 CSS
就能即时改变图标的尺寸和颜色了。

不幸的是,虽然这些图标是矢量图形,但在 1x
显示屏下的渲染效果并不理想。在基于 WebKit
的浏览器下,图标可能会在某些窗口宽度下变得模糊。因为此时图标是作为文本输出的,本来用于提高文本可读性的次像素渲染技术反而使图标看起来糟糕许多。

1. HTTP Live Streaming

HTTP Live Streaming(简称 HLS)是一个基于 HTTP 的视频流协议,由 Apple
公司实现,Mac OS 上的 QuickTime、Safari 以及 iOS 上的 Safari
都能很好的支持 HLS,高版本 Android 也增加了对 HLS
的支持。一些常见的客户端如:MPlayerX、VLC 也都支持 HLS 协议。

HLS 协议基于 HTTP,而一个提供 HLS 的服务器需要做两件事:

  • 编码:以 H.263 格式对图像进行编码,以 MP3 或者 HE-AAC
    对声音进行编码,最终打包到 MPEG-2 TS(Transport Stream)容器之中;
  • 分割:把编码好的 TS 文件等长切分成后缀为 ts 的小文件,并生成一个
    .m3u8 的纯文本索引文件;

浏览器使用的是 m3u8 文件。m3u8 跟音频列表格式 m3u 很像,可以简单的认为
m3u8 就是包含多个 ts
文件的播放列表。播放器按顺序逐个播放,全部放完再请求一下 m3u8
文件,获得包含最新 ts
文件的播放列表继续播,周而复始。整个直播过程就是依靠一个不断更新的 m3u8
和一堆小的 ts 文件组成,m3u8 必须动态更新,ts 可以走 CDN。一个典型的
m3u8 文件格式如下:

#EXTM3U

#EXT-X-STREAM-INF:PROGRAM-ID=1, BANDWIDTH=200000
gear1/prog_index.m3u8

#EXT-X-STREAM-INF:PROGRAM-ID=1, BANDWIDTH=311111
gear2/prog_index.m3u8

#EXT-X-STREAM-INF:PROGRAM-ID=1, BANDWIDTH=484444
gear3/prog_index.m3u8

#EXT-X-STREAM-INF:PROGRAM-ID=1, BANDWIDTH=737777
gear4/prog_index.m3u8

可以看到 HLS 协议本质还是一个个的 HTTP 请求 /
响应,所以适应性很好,不会受到防火墙影响。但它也有一个致命的弱点:延迟现象非常明显。如果每个
ts 按照 5 秒来切分,一个 m3u8 放 6 个 ts 索引,那么至少就会带来 30
秒的延迟。如果减少每个 ts 的长度,减少 m3u8
中的索引数,延时确实会减少,但会带来更频繁的缓冲,对服务端的请求压力也会成倍增加。所以只能根据实际情况找到一个折中的点。

对于支持 HLS 的浏览器来说,直接这样写就能播放了:

XHTML

<video
src=””
height=”300″ width=”400″ preload=”auto” autoplay=”autoplay” loop=”loop”
webkit-playsinline=”true”></video>

1
2
<video src="http://devimages.apple.com/iphone/samples/bipbop/bipbopall.m3u8"
height="300" width="400" preload="auto" autoplay="autoplay" loop="loop" webkit-playsinline="true"></video>

注意:HLS 在 PC
端仅支持safari浏览器,类似chrome浏览器使用HTML5 video标签无法播放 m3u8
格式,可直接采用网上一些比较成熟的方案,如:sewise-player、MediaElement、videojs-contrib-hls、jwplayer。

对页面渲染的改进

因为我们直接将 SVG 注入
HTML(这也是我们选择这种方式更大的原因),所以不再会出现图标字体下载、缓存、渲染过程中出现的样式闪动。

图片 5页面闪动

2. Real Time Messaging Protocol

Real Time Messaging Protocol(简称 RTMP)是 Macromedia
开发的一套视频直播协议,现在属于 Adobe。这套方案需要搭建专门的 RTMP
流媒体服务如 Adobe Media Server,并且在浏览器中只能使用 Flash
实现播放器。它的实时性非常好,延迟很小,但无法支持移动端 WEB
播放是它的硬伤。

虽然无法在iOS的H5页面播放,但是对于iOS原生应用是可以自己写解码去解析的,
RTMP 延迟低、实时性较好。

浏览器端,HTML5 video标签无法播放 RTMP 协议的视频,可以通过
video.js 来实现。

XHTML

<link href=””
rel=”stylesheet”>   <video id=”example_video_1″ class=”video-js
vjs-default-skin” controls preload=”auto” width=”640″ height=”264″
loop=”loop” webkit-playsinline> <source
src=”rtmp://10.14.221.17:1935/rtmplive/home” type=’rtmp/flv’>
</video>   <script
src=”;
<script> videojs.options.flash.swf = ‘video.swf’;
videojs(‘example_video_1’).ready(function() { this.play(); });
</script>

1
2
3
4
5
6
7
8
9
10
11
12
13
<link href="http://vjs.zencdn.net/5.8.8/video-js.css" rel="stylesheet">
 
<video id="example_video_1" class="video-js vjs-default-skin" controls preload="auto" width="640" height="264" loop="loop" webkit-playsinline>
<source src="rtmp://10.14.221.17:1935/rtmplive/home" type=’rtmp/flv’>
</video>
 
<script src="http://vjs.zencdn.net/5.8.8/video.js"></script>
<script>
videojs.options.flash.swf = ‘video.swf’;
videojs(‘example_video_1’).ready(function() {
this.play();
});
</script>

可访问性

就像在《图标字体已死》一文中所述,有些用户会覆盖掉
GitHub
的字体。对于患有读写障碍的用户,某些特定字体是更加容易阅读的。对于修改字体的用户来说,我们基于字体的图标就被渲染成了空白方框。这搞乱了
GitHub 页面布局,而且也不提供任何信息。而不管字体覆盖与否,SVG
都可以正常显示。对于读屏器用户来说,SVG
能让我们选择是读出 alt 属性还是直接完全跳过。

3. 视频流协议HLS与RTMP对比

协议 原理 延时 优点 使用场景
HLS 短链接Http 集合一段时间数据生成ts切片文件更新m3u8文件 10s – 30s 跨平台 移动端为主
RTMP 长链接Tcp 每个时刻的数据收到后立即发送 2s 延时低、实时性好 PC+直播+实时性要求高+互动性强

图形尺寸更合适

我们目前对每个图标在所有尺寸下提供单一的图形。因为站点的加载依赖了图标字体的下载,我们曾被迫把图标集限制在最重要的
16px 尺寸下。这让每个符号在视觉上做出一些让步,因为我们是针对 16px
方格进行优化的。当在新页面或营销页上缩放这些图标时,显示的还是 16px
的版本。而 SVG 可以方便地 fork
全部的图标集,在我们指定的每个尺寸提供更合适的图形。当然对图标字体也可以这么做,但这样用户需要下载两倍的数据量,可能更多。

发表评论

电子邮件地址不会被公开。 必填项已用*标注

标签:,
网站地图xml地图