M3U本质上说不是音频文件,它是音频文件的列表文件,是纯文本文件。你下载下来打开它,播放软件并不是播放它,而是根据它的记录找到网络地址进行在线播放。
M3U文件的大小很小,也就是因为它里面没有任何音频数据。把M3U文件直接转换为音频文件是不可能的,除非你把它指向的音频文件下载下来再作处理。m3u格式的文件只是存储多媒体播放列表,提供了一个指向其他位置的音频视频文件的索引,你播放的还是那些被指向的文件,用记事本打开m3u文件可以查看所指向文件的地址及文件的属性,以选用合适播放器播放。
M3U8也是一种M3U,只是它的编码格式是UTF-8格式。M3U用Latin-1字符集编码。
M3U文件的大小很小,也就是因为它里面没有任何音频数据。把M3U文件直接转换为音频文件是不可能的,除非你把它指向的音频文件下载下来再作处理。m3u格式的文件只是存储多媒体播放列表,提供了一个指向其他位置的音频视频文件的索引,你播放的还是那些被指向的文件,用记事本打开m3u文件可以查看所指向文件的地址及文件的属性,以选用合适播放器播放。
M3U8也是一种M3U,只是它的编码格式是UTF-8格式。M3U用Latin-1字符集编码。
M3U8有啥好处呢?主要是可以做多码率的适配,根据网络带宽,客户端会自动选择一个适合自己码率的文件进行播放,保证视频流的流畅。
为什么现在大部分视频客户端都用TS流播放视频而不直接播放文件呢?
这个是 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 文件会出现破音和画面间断,影响用户体验。
参考:
http://blog.csdn.net/langeldep/article/details/8603045
http://blog.csdn.net/blueboyhi/article/details/40107683
http://www.zhihu.com/question/19644648
---------------------
作者:YQXH_Wang
来源:CSDN
原文:https://blog.csdn.net/yqxh_wang/article/details/47834075
http://blog.csdn.net/langeldep/article/details/8603045
http://blog.csdn.net/blueboyhi/article/details/40107683
http://www.zhihu.com/question/19644648
---------------------
作者:YQXH_Wang
来源:CSDN
原文:https://blog.csdn.net/yqxh_wang/article/details/47834075