现在的位置: 首页 > 移动开发 > IOS > 正文

iOS_直播类app_HTTP Live Streaming

2016年05月29日 IOS ⁄ 共 4605字 ⁄ 字号 暂无评论

 HTTP Live Streaming



这个是 Apple 为了提高流播效率开发的技术,特点是将流媒体切分为若干 TS 片段(比如每10秒一段),然后通过一个扩展的 m3u 列表文件将这些TS 片段集中起来供客户端播放器接收。

这样做相比使用 RTSP 协议的好处在于,一旦切分完成,之后的分发过程完全不需要额外使用任何专门软件,普通的网络服务器即可,大大降低了 CDN 边缘服务器的配置要求,可以使用任何现成的 CDN。


分发使用的协议是最常见 HTTP,代理服务器对这个协议的缓存优化相当成熟,而很少有代理服务器对 RTSP 的进行缓存优化。这对播放(软)实时视频有相当大的优势,因为这样分发后,对源服务器的负载压力小得多。

对于非实时视频,同样的好处也是存在的:如果你要在一段长达一小时的视频中跳转,如果使用单个 MP4 格式的视频文件,并且也是用 HTTP 协议,那么需要代理服务器支持 HTTP range request 以获取大文件中的一部分。不是所有的代理服务器都对此有良好的支持。


而 HTTP Live Streaming 则只需要根据列表文件中的时间轴找出对应的 TS 片段下载即可,不需要 range request,对代理服务器的要求小很多。所有代理服务器都支持小文件的高效缓存。

此外,HTTP Live Streaming 还有一个巨大优势:自适应码率流播(adaptive streaming)。效果就是客户端会根据网络状况自动选择不同码率的视频流,条件允许的情况下使用高码率,网络繁忙的时候使用低码率,并且自动在二者间随意切换。


这对移动设备网络状况不稳定的情况下保障流畅播放非常有帮助。
实现方法是服务器端提供多码率视频流,并且在列表文件中注明,播放器根据播放进度和下载速度自动调整。

至于为什么要用 TS 而不是 MP4,这是因为两个 TS 片段可以无缝拼接,播放器能连续播放,而 MP4 文件由于编码方式的原因,两段 MP4 不能无缝拼接,播放器连续播放两个 MP4 文件会出现破音和画面间断,影响用户体验。

前两年我尝试过一个基于 HTML5 < audio > 标签 + CBR MP3 格式 + Icecast 流媒体服务器的网络广播台的网页应用(预想是给
http://apple4.us
做 Livecast 的,就是听众只需要访问一个网页就能够几乎实时听到访谈节目),采用的正是 HTTP Live Streaming 的思路。通过对 MP3 音频流进行帧切分,基本能做到连续播放。唯一问题是浏览器不支持
TS 格式, < audio > 标签在两段 MP3 之前切换时会破音。这样只能对谈话类内容适用,如果播放连续的音乐有时候会听出破绽。

iOS 设备上启用 HTTP Live Streaming 非常简单,也是苹果官方推荐的方式。


Adobe 的 Flash 流媒体服务器的新版本也要支持这个技术的 。这样普及开来是好事,用户体验更好、网络压力更低。


常用的流媒体协议主要有 HTTP 渐进下载和基于RTSP/RTP
的实时流媒体协议

这二种基本是完全不同的东西,目前比较方便又好用的我建议使用 HTTP 渐进下载的方法。


在这个中 apple 公司的 HTTP Live Streaming 是这个方面的代表。它最初是苹果公司针对iPhone、iPod、iTouch和iPad等移动设备而开发的流.现在见到在桌面也有很多应用了,
HTML5 是直接支持这个。


我们可以看看 HTTP Live Streaming 是怎么样工作的。平时的直播技术中,播放模式中必须等待整个文件下载完才行,在 HLS 技术中 Web 服务器向客户端提供接近实时的音视频流。但在使用的过程中是使用的标准的 HTTP 协议,所以这时,只要使用
HLS 的技术,就能在普通的 HTTP 的应用上直接提供点播和直播。


要详细了解原理,我们先看看这个所需要的步骤。

        视频采集 ->编码器 -> 流分割 -> 普通 web 服务(索引文件和视频文件) -> 客户端

        

内容准备的过程大约二种,一是视频采集,编码器首先将摄像机实时采集的音视频数据压缩编码为符合特定标准的音视频基本流,也可以拿编码完了的文件,有一点必须保证,就是一定要使用H.264视频和AAC音频,因为发明这个的是苹果公司,只支持这个。

然后给这些封装成成为符合MPEG-2(MPEG
2 TS、MPEG2 PS
之所以使用这个,主要是因为声音和视频会交织在一起,也会有关键帧来让视频可以直接播放).


        流分割部分在这个中,比起 RTSP 之类和普通点播的最大不同,就是他会给 MPEG-2 分割成很多个 ts 的文件。分割过程大多是按时间来切,根据国外的资料,建议切 10s 一个的文件,如果码流高可以 5 秒一次。


在分割还有一点不同,就是这时流分割器会生成一个含有指向这些小TS文件指针的索引文件,所以这个文件也必须在 web 服务器上,不能少。每多
10s 时,就会多一个 ts 文件,所以索引也会根着修改成最新的几段视频。


最后,这些切分了的小的一系列的 ts 文件,放到普通的 web 服务器中就行了。这时在 CDN 中也是一样,因为请求这些文件会使用标准的 HTTP 协议。


索引文件后缀是.m3u8 ,索引文件采用扩展的M3U播放列表格式,其实就一文本。

内部的视频的地址会是如下

http://media.example.com/s_96ksegment1.ts
http://media.example.com/s_96ksegment2.ts
http://media.example.com/s_96ksegment3.ts


所以这时可以直接做 Cache 和直接放到 Web 服务器中,简单方便。
如果 MIME 的信息输出不对的话,记的要修改这加入 ts 和 m3u8 的后缀支持

.m3u8 application/x-mpegURL
.ts video/MP2T


最后就是客户端,如果是 HTML 直接在 HTML5 中直接支持这种视频可以使用如下标签

<video tabindex="0" height="480" width="640"> 
<source src="/content1/content1.m3u8"> 
</video>

        

如果是应用客户端(Safari QuickTime之类),就得装软件来支持,客户端会根据选择的流的索引来下载文件,当下载了最少二段后开始播放。直接 m3u8 的索引结束。


另外,HTTP可以设计成的自适应比特率流,在不同网络环境,选择下载不同码流的视频。

        所以整个 HTTP Live Streaming 无论是直播还是点播,都能做到近似实时的方式来进行流播放。理论的最小时延是每个切片的长.




HTTP Live Streaming直播(iOS直播)技术分析与实现

   

  HTTP Live StreamingHLS)技术,并实现了一个HLS编码器HLSLiveEncoder,C++写的。

其功能是采集摄像头与麦克风,实时进行H.264视频编码和AAC音频编码,并按照HLS的协议规范,生成分段的标准TS文件以及m3u8索引文件


通过HLSLiveEncoder和第三方Http服务器(例如:Nginx),成功实现了HTTP Live Streaming直播,并在iphone上测试通过。

HLS技术要点分析

  HTTP Live StreamingHLS)是苹果公司(Apple Inc.)实现的基于HTTP的流媒体传输协议,可实现流媒体的直播和点播,主要应用在iOS系统,为iOS设备(如iPhone、iPad)提供音视频直播和点播方案。

HLS点播,基本上就是常见的分段HTTP点播,不同在于,它的分段非常小。要实现HLS点播,重点在于对媒体文件分段,目前有不少开源工具可以使用,只谈HLS直播技术。


  相对于常见的流媒体直播协议,例如RTMP协议、RTSP协议、MMS协议等,HLS直播最大的不同在于,直播客户端获取到的,并不是一个完整的数据流。

HLS协议在服务器端将直播数据流存储为连续的、很短时长的媒体文件(MPEG-TS格式),而客户端则不断的下载并播放这些小文件,因为服务器端总是会将最新的直播数据生成新的小文件,这样客户端只要不停的按顺序播放从服务器获取到的文件,就实现了直播。


由此可见,基本上可以认为,HLS是以点播的技术方式来实现直播。由于数据通过HTTP协议传输,所以完全不用考虑防火墙或者代理的问题,而且分段文件的时长很短,客户端可以很快的选择和切换码率,以适应不同带宽条件下的播放。

不过HLS的这种技术特点,决定了它的延迟一般总是会高于普通的流媒体直播协议。

  根据以上的了解要实现HTTP Live Streaming直播,需要研究并实现以下技术关键点

  1. 采集视频源和音频源的数据
  2. 对原始数据进行H264编码和AAC编码
  3. 视频和音频数据封装为MPEG-TS包
  4. HLS分段生成策略及m3u8索引文件
  5. HTTP传输协议

  其中第1点和第2点,我之前的文章中已经提到过了,而最后一点,我们可以借助现有的HTTP服务器,所以,实现第3点和第4点是关键所在。

原文:http://www.cnblogs.com/haibindev/archive/2013/01/30/2880764.html

程序框架与实现          

  通过以上分析,实现HLS LiveEncoder直播编码器,其逻辑和流程基本上很清楚了:分别开启音频与视频编码线程,通过DirectShow(或其他)技术来实现音视频采集,随后分别调用libx264和libfaac进行视频和音频编码。两个编码线程实时编码音视频数据后,根据自定义的分片策略,存储在某个MPEG-TS格式分段文件中,当完成一个分段文件的存储后,更新m3u8索引文件。如下图所示:

  

  上图中HLSLiveEncoder当收到视频和音频数据后,需要首先判断,当前分片是否应该结束,并创建新分片,以延续TS分片的不断生成。

需要注意的是,新的分片,应当从关键帧开始,防止播放器解码失败。核心代码如下所示:

  

  TsMuxer的接口也是比较简单的。

    

HLS分段生成策略和m3u8   

1. 分段策略

  • HLS的分段策略,基本上推荐是10秒一个分片,当然,具体时间还要根据分好后的分片的实际时长做标注
  • 通常来说,为了缓存等方面的原因,在索引文件中会保留最新的三个分片地址,以类似“滑动窗口”的形式,进行更新。

2. m3u8文件简介

  m3u8,是HTTP Live Streaming直播的索引文件。

m3u8基本上可以认为就是.m3u格式文件,

区别在于,m3u8文件使用UTF-8字符编码。

#EXTM3U                     m3u文件头,必须放在第一行
#EXT-X-MEDIA-SEQUENCE       第一个TS分片的序列号
#EXT-X-TARGETDURATION       每个分片TS的最大的时长
#EXT-X-ALLOW-CACHE          是否允许cache
#EXT-X-ENDLIST              m3u8文件结束符
#EXTINF                     extra info,分片TS的信息,如时长,带宽等

  一个简单的m3u8索引文件

    

运行效果          

  在Nginx工作目录下启动HLSLiveEncoder,并用VLC播放器连接播放

     

  通过iPhone播放的效果