问题：
要获得将视频接收到应用商店的iOS应用，我们需要拥有HLS版本。
有什么问题？
Android不支持HLS，由于其他原因，我们需要存储相同内容的MP4和HLS文件。
MP4和HLS之间的区别是什么？为什么需要同时存储它们？
MP4是一个存储H.264视频和AAC音频的容器，以便在HTML 5浏览器中实现最佳兼容性 - 如果浏览器不支持HTML 5中使用相同MP4文件但播放的MP4视频，则jsvideo播放器通常会出现闪回后备通过闪光灯。
HLS是一种协议，其中文本文件（.m3u8）包含对播放列表的引用，播放列表本身引用.ts文件（或m2ts），它们是mpeg-2传输流，不要与mpeg-2视频混淆。 .ts文件是相同H.264视频和AAC音频的容器。
我为什么抱怨？
从MP4文件创建HLS文件和播放列表需要一段时间
（最重要的是）我们现在在S3上存储两倍的数据
我为什么要关心？如果您的S3账单每月10美元用于存储MP4和HLS，现在只需5千美元。换句话说，如果你要花10万美元在MP4中存储数据，那么在MP4和HLS中存储相同的内容将花费20万美元。
我想要什么？
我只想存储.ts文件，并为该单个文件同时为桌面用户，iOS用户和Android用户提供服务。
有可能吗？
HLS是否需要5-10秒的.ts段而不是一个大文件？
从IETF草案7和协议版本4开始，HLS支持标记EXT-X-BYTERANGE，它允许您将媒体段指定为较大URL的字节范围（子范围）。
.ts文件是否与HTML5视频兼容？
显然不是。它们是与MP4不同的容器，但包含相同的视频和音频内容。值得研究如何存储原始视频/音频数据一次，并在必要时使用正确的容器。如果浏览器不支持HTML 5 MP4，JS视频播放器可以动态地将HTML 5 MP4文件转换为Flash视频，那么为什么不能对M2TS数据做同样的事情呢？
我可能在某种程度上无知，但也许有人可以对这个问题有所了解，并可能提出解决方案。
答案 0 :(得分：6)
目前没有良好的解决方案。
一点背景。
视频流用于需要自定义协议，如RTP / RTMP / RTSP等。这些协议工作正常，但我们基本上构建了两个独立的网络。一个HTTP基于标准Web流量，另一个基于HTTP。这个想法是将视频分成小块并通过HTTP将它们提供给播放器。这样我们就不需要特殊的服务器/软件了，我们就可以利用正在构建的巨型HTTP CDN。此外。因为视频被分成块，我们可以将相同的视频编码成不同的质量/文件大小。然后，播放器可以为其当前带宽选择最佳质量的视频。由于网络条件不断变化，这是移动设备的完美解决方案。制定了几个竞争标准。移动网络是第一个上市[需要引证]。该设计由Microsoft（Smooth Streaming）和Apple（HTTP Live streaming aka HLS）复制。微软正在逐步淘汰流畅的流媒体，转而使用DASH。 DASH看起来将成为未来的默认流媒体解决方案。除了，因为它的设计 - 礼让方法，它已经基本上停留了几年的礼让。现在，在这几年里，Apple销售了数百万台IOS设备。因此，HLS不能仅仅停产。为什么不是每个人都只使用HLS呢？我可以想到三个原因：1）它的苹果标准，人们是仇恨。 2）传输流是一种复杂的文件格式。 3）运输流程受到专利保护。 MP4不受专利保护，但也没有适应能力。这使得用户在2G网络上体验不佳。 iPhone 1支持的唯一网络。当时AT＆amp; T也不希望在那里流传输完全比特率的视频。 HLS是妥协。所有这些都早于HTML5。因此，视频标签甚至没有在其设计中考虑过。
解决你的观点：
1）从MP4创建HLS文件和播放列表需要一些时间 文件
这是一个编程网站，Automate it。
2）我们现在在S3上存储两倍的数据 [原文如此]我只想存储.ts文件并为两个桌面用户提供服务， iOS用户和拥有该单个文件的Android用户。
你和我都是男人:)。
可能的解决方案。
1）Androids的实施有什么特别的错误？ （除了缺少旧设备）
2）JW播放器可以播放HLS（在Android上不确定）
3）服务器端transmux按需。
HLS是否需要5-10秒的.ts段而不是一个大文件？
您可以执行字节范围，但您需要确保您感兴趣的所有设备都支持它。
如果JS视频播放器可以将HTML 5 MP4文件转换为Flash视频 如果浏览器不支持HTML 5 MP4，那么为什么不是 能够对M2TS数据做同样的事情吗？
他们没有转换。 Flash原生支持mp4。可以在AS3 / JS中转换TS。我已经做了。 JW播放器可以在浏览器中转换TS。 video.js也许能够。