我创建了一个示例应用程序来演示 HTTP 实时流的工作。
我所做的是，我有一个库将输入作为视频文件（avi、mpeg、mov、.ts）并为给定的视频文件生成片段（.ts）和播放列表（.m3u8）文件。当我从库中获取播放列表数据时，我将播放列表（作为字符串）存储在链接列表中。
我已经编写了一个基本的 Web 服务器，它将为用户请求的片段和播放列表文件提供服务。我正在从 iPhone safari 浏览器请求 playlist.m3u8 文件，它正在启动 QuickTime 播放器，它正在请求收到的播放列表文件中列出的 segment.ts 文件。在播放每个片段（在当前播放列表中列出）后，它再次请求播放列表，我在其中响应下一个播放列表文件，其中包含其中列出的下一组 segment.ts 文件。
这就是我们所说的HTTP直播吗？
除了实现 HTTP 实时流媒体之外，我还需要做些什么吗？
谢谢。
您还可以使用 mac os x 的媒体流验证器命令行应用程序来验证 HTTP Web 服务器生成的流。
不多了。如果您正在获取媒体的输入流，对其进行编码，以适合交付的格式进行封装，并通过将封装的媒体以可以从 HTTP 服务器请求的方式放置来准备分发，那么您就完成了。直播背后的想法是，它利用了现有的互联网架构，该架构已经针对合理大小的资源的 HTTP 请求进行了优化。
HTTP 流使许多现有的 CDN 解决方案因其自定义流协议、自定义路由和自定义内容缓存而过时。
或多或少，但如果您希望服务器将文件推送到 iOS 设备，还需要处理自适应比特率流。这意味着您的范围从跟踪所有 TS 文件的单个“index.m3u8”文件扩展为主索引，然后主索引跟踪您希望在应用程序中支持的每个比特率的索引文件，然后单独跟踪 TS 文件以各自的比特率编码。
这是大量的工作，但一旦你掌握了基础知识，大部分都是例行的/重复的。
有关流媒体的更多信息，从 iOS 的角度来看，您的圣经应始终为TN2224。严格遵守 Technote 中的规范，是您通过 App Store 审批流程相对于流媒体的最佳机会。
有些人不打扰（在过去的几个月里构建了一个流媒体应用程序，并查看了一大堆似乎不太遵守规则的视频应用程序的 HTTP 日志）——有时 Apple 会注意到，有时他们不会't，有时玩家太大了，苹果无法干预。
因此，它与您的应用程序功能的所有其他方面都经过 Apple 的审查并没有太大的不同。只是有一些方法可以确保你走在正确的轨道上。
当然，从纯粹的技术角度来看，正如@psp1 所提到的，mediastreamvalidator 工具可以帮助您确定您的流是否 - 在它们的核心，即使不是就它们的整体能力而言 - 与 HLS 实现的预期兼容。
注意：您可以使用自己的编码解决方案（使用 ffmpeg，加号是您有更多的控制权，减号是需要时间来配置和正常工作。另外，一旦您开始谈论即使是最少量的规模，您遇到一大堆其他问题。一旦你完成了所有的技术工作，你会发现这很容易。现在你必须真正弄清楚你需要获得哪个许可证才能拥有幻想H.264 编码器和你一起跳过所有的法律/程序箍以获得一个）。
对于没有可以填满足球场的法律/会计团队的开发人员来说，这是一种更简单的解决方案，IMO，使用 Encoding.com、Zencoder 等提供编码服务的网站更容易成为第三方，或者使用月租费。好处是他们已经处理了所有的许可 BS，并且只是为您提供简单的“付费使用”服务，当您为客户构建项目时，这也可能非常有用。缺点是您现在依赖于 Zencoder/Encoding，另一方面，当您的编码作业因服务器关闭而失败一整天时，您会知道它的另一面，或者甚至在 API 不完全正常时按照您的预期行事或已记录在案！
但无论如何，这就是您在将 HLS 服务器投入生产之前获得 Grok 的所有因素！