Deploying HTTP Live Streaming
(原文地址)
https://developer.apple.com/library/ios/#documentation/networkinginternet/conceptual/streamingmediaguide/Introduction/Introduction.html
为了发布我们的 HTTP Live Streaming 服务,我们需要构建一个服务器,同时呢我们需要创建一个访问的客户端,可以是一个HTML文件,或者是一个APP的应用程序。
同时呢,我们服务器上保存的文件呢,必须要遵循一个原则,对于直播的数据,我们必须要编码成MPEG-2形式然后再进行一个切割。或者是H.264形式的视频文件和AAC形式的音频文件。这个具体的切割工具和方法,我们已经在上一个文档Using-HTTP-Live-Streaming中讲到。同理,我们也需要对切割后的文件进行校验,或者是进行一个机密的动作。
如下是我们的一个HTML请求模板。
<html> |
<head> |
<title>HTTP Live Streaming Example</title> |
</head> |
<body> |
<video |
src="http://devimages.apple.com/iphone/samples/bipbop/bipbopall.m3u8" |
height="300" width="400" |
> |
</video> |
</body> |
</html> |
HTTP Live Streaming可以部署在一个很普通的web服务器上面。没有特别配置要求。出了做一些MIME类型的配置之外。
如下是HTTP Live Streaming 的MIME类型配置。
File Extension |
MIME Type |
.M3U8 |
application/x-mpegURL or vnd.apple.mpegURL |
.ts |
video/MP2T |
如果你的服务器已经配置了MIME的类型的话,那么这个服务就能提供服务。
索引播放列表文件可能很长,并且需要不停的进行更新。但是由于这个文件其实就是文本文件,所以我们一般不需要考虑效率问题。你可以通过开启on-the-fly .gzip 模式对.M3U8文件进行压缩减少服务器的,一般的情况下HTTP Live Streaming 的客户端将会自动的进行解压并得到索引文件。
在直播的时候,由于我们的播放列表索引文件时在不停的更新的,所以我们就要考虑缓存的问题,我们需要设置Shortening time-to-live (TTL) 的值。保证每次下载到得都是最新的索引文件,由于在线点播是只有一个所以文件,所以我们不需要考虑这个问题。
当我们的实时视频流或者是静态的视屏文件在做切割完成之后我们都是需要进行一个校验的过程,已确保我们的切割过程正确。这个时候我们就需要使用到mediastreamvalidator 这个命令行的工具了。
通常我们进行一个校验之后,我们得到如下的一个反馈结果。
Validating http://devimages.apple.com/iphone/samples/bipbop/gear3/prog_index.m3u8 against iPhone OS 3.1.0 |
|
Average segment duration: 8.77 seconds |
Average segment bitrate: 510.05 kbit/s |
Average segment structural overhead: 96.37 kbit/s (18.89 %) |
|
Video codec: avc1 |
Video resolution: 480x360 pixels |
Video frame rate: 29.97 fps |
Average video bitrate: 407.76 kbit/s |
H.264 profile: Baseline |
H.264 level: 2.1 |
|
Audio codec: aac |
Audio sample rate: 22050 Hz |
Average audio bitrate: 5.93 kbit/s |
你可以对你的切割文件进行一个加密的动作,无论是文件切割器或者是文件流切割器都是有加密的选项的,你可以设置密钥能随着时间的变化而改变。
密钥文件需要一个初始的导线(IV)来进行解密。IV也是可以随着时间的变化而改变。就如同密钥一样。目前我们建议,我们的密钥要在3-4个小时进行一个改变,IV需要在每50M数据的流通后做一个改变。
虽然你的密钥做了一些权限的限制,但是在通过HTTP请求的时候很容易做一个密钥文件的备份,然后再解密。一个最好的解决方式就是通过HTTPS协议来进行请求。
在你打算准备提供HTTPS协议的密钥的时候,你应该通过一个内部的服务器做一个测试,这个测试一般是采用HTTP请求来实现的。这个可以让你能够更好的添加HTTPS,一旦你确定都是ok的,那么你就可以切换到HTTPS协议上。
如果你要采用HTTPS协议,那么你必须要遵循如下几个规则。
l 你需要安装一个被你的HTTPS服务器接受的SSL认证。
l 你认证的域名必须要跟你的密钥的认证域名是相同的。
l 你必须启动自己的对话框为用户进行身份认证,或者你可以存储认证信息在客户端上。你必须启动自己的对话框为用户进行身份认证,如果你是自己来写一个客户端,那么你就需要来存储这些认证信息,无论是一句Cookie或者是HTTP digest ,都可以通过didReceiveAuthenticationChallenge 这个回调函数来进行处理。see “Using NSURLConnection” and “Authentication Challenges” for details 。然后你的这个认证就能被缓存起来和重复的被播放器使用。
如果你没有一个由权威机构认证的SSL认证文件,你仍然可以来测试,你需要创建一个自己签名认证的SSL认证文件,然后通过邮件发送到客户端,然后再让客户端进行一个安装。